Significant-Gravitas/AutoGPT · error · HTTPException
codex_credential_not_found
Error message
codex_credential_not_found
What it means
A 404 from _resolve_new_session_llm_route: the client explicitly requested the codex route with a specific credential, but no available transport in _get_chat_transports(user_id) matches that exact (auth_provider='codex', credential_id) pair with available=true. The credential was either deleted, belongs to another user, or its transport is currently unavailable.
Source
Thrown at autogpt_platform/backend/backend/api/features/chat/routes.py:609
)
if auth_provider == "codex" and credential_id is None:
raise HTTPException(
status_code=422,
detail="codex_credential_required",
)
selected_route = next(
(
transport
for transport in transports
if transport.auth_provider == auth_provider
and transport.credential_id == credential_id
and transport.available
),
None,
)
if selected_route is None:
if auth_provider == "codex":
raise HTTPException(
status_code=404,
detail="codex_credential_not_found",
)
raise HTTPException(
status_code=503,
detail="chat_transport_not_configured",
)
return auth_provider, credential_id
default_route = next(
(transport for transport in transports if transport.default),
None,
)
if default_route is not None:
return default_route.auth_provider, default_route.credential_id
if any(transport.available for transport in transports):
raise HTTPException(
status_code=409,View on GitHub (pinned to 9c8bb5550f)
Solutions
- Refetch the user's credential/transports list and retry with a currently available codex credential id.
- If the credential was deleted, have the user re-add it, then select the new id.
- If the credential exists but is unavailable, check the codex transport configuration/health on the backend (env vars, connectivity) — availability=false for all credentials points at backend config.
Example fix
// before
createSession({llm_auth_provider: 'codex', llm_credential_id: cachedCredId}) // stale id
// after
const creds = await listChatTransports(userId);
const cred = creds.find(t => t.auth_provider === 'codex' && t.available);
if (cred) createSession({llm_auth_provider: 'codex', llm_credential_id: cred.credential_id}); Defensive patterns
Strategy: validation
Validate before calling
const transports = await listChatTransports(userId);
const match = transports.find(t => t.auth_provider === 'codex' && t.credential_id === credId && t.available);
if (!match) { refreshCredentialPicker(); return; }
await createSession({llm_auth_provider: 'codex', llm_credential_id: credId}); Type guard
function isAvailableCredential(transports: Transport[], credId: string): boolean {
return transports.some(t => t.auth_provider === 'codex' && t.credential_id === credId && t.available);
} Try / catch
try {
await createSession({llm_auth_provider: 'codex', llm_credential_id: credId});
} catch (e) {
if (e.status === 404) { await refetchCredentials(); promptReselect(); return; }
throw e;
} Prevention
- Refetch transports before creating a codex session; never trust cached credential ids.
- Drop deleted credential ids from client storage immediately.
- If all codex transports show unavailable, suspect backend codex config, not the credential.
When it happens
Trigger: POST /chat/sessions with {"llm_auth_provider": "codex", "llm_credential_id": X} where credential X is missing, not owned by this user, revoked, or its transport reports available=false.
Common situations: Credential deleted or re-keyed after the client cached its id (stale dropdown); credential list fetched from a different environment; codex backend config missing/unhealthy so the transport is marked unavailable; user session restored from localStorage with an old credential id.
Related errors
- Session {session_id} not found.
- codex_builder_session_unsupported
- codex_credential_not_allowed
- codex_credential_required
- chat_transport_selection_required
AI-assisted analysis of Significant-Gravitas/AutoGPT@9c8bb5550f (2026-08-14).
Data as JSON: /api/errors/a86c02a499b23045.
Report an issue: GitHub.