Significant-Gravitas/AutoGPT · warning · HTTPException

codex_builder_session_unsupported

Error message

codex_builder_session_unsupported

What it means

A 422 from _resolve_new_session_llm_route: a new session carries a builder_graph_id (a deployment/builder chat) together with either llm_auth_provider='codex' or a non-null llm_credential_id. Builder sessions are hard-wired to the platform LLM route; custom credentials or the codex provider are simply not supported for them, so the request is rejected before any validation of the graph.

Source

Thrown at autogpt_platform/backend/backend/api/features/chat/routes.py:570

async def list_chat_transports(
    user_id: Annotated[str, Security(auth.get_user_id)],
) -> ChatTransportsResponse:
    return ChatTransportsResponse(transports=await _get_chat_transports(user_id))


async def _resolve_new_session_llm_route(
    user_id: str,
    request: CreateSessionRequest | None,
) -> tuple[CopilotLlmAuthProvider, str | None]:
    auth_provider = request.llm_auth_provider if request else "platform"
    credential_id = request.llm_credential_id if request else None

    if auth_provider == "codex":
        await enforce_codex_access_http(user_id)

    if request is not None and request.builder_graph_id is not None:
        if auth_provider == "codex" or credential_id is not None:
            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(

View on GitHub (pinned to 9c8bb5550f)

Solutions

  1. Omit llm_auth_provider and llm_credential_id entirely when creating a builder/deployment session — it always routes to 'platform'.
  2. Fix the client to build the request per session type: builder sessions send only builder_graph_id (+ dry_run), never routing fields.
  3. If you intended a codex/custom-credential chat, drop builder_graph_id and create a normal session instead.

Example fix

// before
createSession({builder_graph_id: graphId, llm_credential_id: credId})

// after
createSession({builder_graph_id: graphId})
Defensive patterns

Strategy: validation

Validate before calling

const body: CreateSession = {builder_graph_id: graphId};
// never add llm_* fields for builder sessions
if ('llm_credential_id' in body || 'llm_auth_provider' in body) throw new Error('invalid builder payload');

Type guard

function isPlainBuilderSessionRequest(b: Record<string, unknown>): boolean {
  return typeof b.builder_graph_id === 'string'
    && !('llm_auth_provider' in b) && !('llm_credential_id' in b);
}

Prevention

When it happens

Trigger: POST /chat/sessions with {"builder_graph_id": "...", "llm_auth_provider": "codex"} or {"builder_graph_id": "...", "llm_credential_id": "..."}.

Common situations: Frontend session-creation form keeps a previously selected credential/provider in state and merges it into the builder-chat payload; a shared createSession() client helper always includes credential fields; API consumers assuming all session types accept routing overrides.

Related errors


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