jlcodes99/cockpit-tools · error
PROVIDER_NOT_FOUND
PROVIDER_NOT_FOUND
Error message
PROVIDER_NOT_FOUND
What it means
updateCodexModelProvider looks up the provider by providerId in the loaded provider store and throws PROVIDER_NOT_FOUND when no record matches. This means the id passed in does not reference any persisted Codex model provider. It is a lookup failure on a stale or wrong identifier, thrown before any patch fields are applied.
Source
Thrown at src/services/codexModelProviderService.ts:654
sourceTag?: string | null;
modelCatalog?: string[] | null;
modelContextWindows?: Record<string, number> | null;
supportsVision?: boolean;
modelCapabilities?: Record<string, { supportsVision?: boolean }> | null;
visionRoutingModel?: string | null;
boundInstanceId?: string | null;
website?: string;
apiKeyUrl?: string;
wireApi?: CodexProviderWireApi | null;
supportsWebsockets?: boolean;
enableModePreference?: CodexProviderEnableModePreference | null;
integrationType?: 'sub2api' | 'new_api' | null;
boundOauthAccountId?: string | null;
},
): Promise<CodexModelProvider> {
const providers = await ensureProvidersLoaded();
const provider = providers.find((item) => item.id === providerId);
if (!provider) throw new Error('PROVIDER_NOT_FOUND');
const nextName = patch.name === undefined ? provider.name : sanitizeName(patch.name);
const nextBaseUrl =
patch.baseUrl === undefined
? provider.baseUrl
: normalizeBaseUrlForStore(patch.baseUrl);
const normalizedBaseUrl = normalizeCodexModelProviderBaseUrl(nextBaseUrl);
if (!nextName) throw new Error('PROVIDER_NAME_REQUIRED');
if (!normalizedBaseUrl) throw new Error('PROVIDER_BASE_URL_INVALID');
const duplicated = providers.find(
(item) =>
item.id !== providerId &&
normalizeCodexModelProviderBaseUrl(item.baseUrl) === normalizedBaseUrl,
);
if (duplicated) throw new Error('PROVIDER_BASE_URL_EXISTS');
provider.name = nextName;View on GitHub (pinned to 1ed8b77992)
Solutions
- Enumerate providers (e.g. listCodexModelProviders) and confirm the providerId exists before updating; use the fresh id from that list.
- Re-fetch the provider by name or baseUrl instead of relying on a cached id, then update using the returned id.
- If the provider was intentionally deleted, skip the update or recreate the provider first with createCodexModelProvider.
- Catch the error, check for 'PROVIDER_NOT_FOUND' in message, and refresh the UI provider list.
Example fix
// before: stale id
await updateCodexModelProvider(staleId, { name: 'new-name' });
// after: resolve a live id first
const providers = await listCodexModelProviders();
const target = providers.find((p) => p.id === staleId);
if (!target) throw new Error('Provider no longer exists; refresh the list');
await updateCodexModelProvider(target.id, { name: 'new-name' }); Defensive patterns
Strategy: validation
Validate before calling
const providers = await listCodexModelProviders();
const provider = providers.find((p) => p.id === providerId);
if (!provider) throw new Error(`Provider ${providerId} not found; refresh and retry`); Type guard
function providerExists(providers: { id: string }[], providerId: string): providers is [{ id: string }, ...{ id: string }[]] {
return providers.some((p) => p.id === providerId);
} Try / catch
try {
await updateCodexModelProvider(providerId, patch);
} catch (e) {
if ((e as Error).message === 'PROVIDER_NOT_FOUND') {
await refreshProviderList(); // resync UI state
} else throw e;
} Prevention
- Never cache provider ids across store resets or sessions; resolve by name/baseUrl when possible.
- Refresh the provider list after any delete, including deletes from other windows.
- Distinguish provider ids from apiKey ids / OAuth account ids in your types.
- Handle deletes gracefully so UI actions on removed providers become no-ops.
When it happens
Trigger: Calling updateCodexModelProvider(providerId, patch) with an id that is not in the store: a deleted provider, a fabricated/typo'd id, an id from a different store file, or a caller (e.g. saveCodexModelProviderDetectedIntegrationType, handleProviderOauthBindingChange) holding a reference captured before the provider was removed.
Common situations: UI kept a provider selected after it was deleted in another window; automated scripts caching provider ids across store resets; passing an apiKey id or OAuth account id where a provider id is expected; environment with a fresh/empty providers store after reinstall.
Understand the failure class
Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.
Related errors
AI-assisted analysis of jlcodes99/cockpit-tools@1ed8b77992 (2026-09-05).
Data as JSON: /api/errors/ea3e09792a5c3fa1.
Report an issue: GitHub.