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

  1. Send llm_credential_id only when llm_auth_provider is 'codex'; omit it (do not send null) for platform sessions.
  2. Clear the credential field in the client's state whenever the provider selection changes to 'platform'.
  3. 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

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


AI-assisted analysis of Significant-Gravitas/AutoGPT@9c8bb5550f (2026-08-14). Data as JSON: /api/errors/ce28973300ee3eb9. Report an issue: GitHub.