Significant-Gravitas/AutoGPT · warning · HTTPException
codex_credential_not_allowed
Error message
codex_credential_not_allowed
What it means
A 422 from _resolve_new_session_llm_route: the client explicitly set llm_auth_provider='platform' (or omitted the provider but explicitly set llm_credential_id) in the create-session request. Credentials are a codex-route concept; the platform route is credential-less, so pairing a credential with it is rejected rather than silently ignored.
Source
Thrown at autogpt_platform/backend/backend/api/features/chat/routes.py:588
raise HTTPException(
status_code=422,
detail="codex_builder_session_unsupported",
)
if not _is_deployment_chat_available():
raise HTTPException(
status_code=503,
detail="chat_transport_not_configured",
)
return "platform", None
transports = await _get_chat_transports(user_id)
if request is not None:
route_was_explicit = bool(
{"llm_auth_provider", "llm_credential_id"} & request.model_fields_set
)
if route_was_explicit:
if auth_provider == "platform" and credential_id is not None:
raise HTTPException(
status_code=422,
detail="codex_credential_not_allowed",
)
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,
)View on GitHub (pinned to 9c8bb5550f)
Solutions
- Send llm_credential_id only when llm_auth_provider is 'codex'; omit it (do not send null) for platform sessions.
- Clear the credential field in the client's state whenever the provider selection changes to 'platform'.
- If using a shared request builder, make credential inclusion conditional rather than unconditional.
Example fix
// before
{llm_auth_provider: provider, llm_credential_id: credId ?? undefined} // credId sent even for 'platform'
// after
{llm_auth_provider: provider, ...(provider === 'codex' ? {llm_credential_id: credId} : {})} Defensive patterns
Strategy: validation
Validate before calling
const body = provider === 'codex'
? {llm_auth_provider: provider, llm_credential_id: credId}
: {llm_auth_provider: provider}; // no credential key at all
await createSession(body); Type guard
function isCoherentRoute(provider: string, credId?: string): boolean {
return provider === 'codex' ? credId != null : credId == null;
} Prevention
- Make credential inclusion conditional on provider, not always-serialized.
- Reset credential state when the provider dropdown changes.
- Prefer omitting optional keys over sending null — the backend checks model_fields_set.
When it happens
Trigger: POST /chat/sessions with {"llm_auth_provider": "platform", "llm_credential_id": "..."}, or a body that includes only llm_credential_id (provider defaults to 'platform'). The check fires only when either routing field was explicitly sent (model_fields_set), not when defaults apply.
Common situations: Client reuses one form/model for both routes and always serializes llm_credential_id (e.g. null-to-empty-string coercion); user switches provider dropdown back to 'platform' after picking a credential and the stale credential stays in the payload.
Related errors
- codex_builder_session_unsupported
- codex_credential_required
- builder_graph_id and expert_id are mutually exclusive
- Title must not be blank
- codex_credential_not_found
AI-assisted analysis of Significant-Gravitas/AutoGPT@9c8bb5550f (2026-08-14).
Data as JSON: /api/errors/ce28973300ee3eb9.
Report an issue: GitHub.