Summary
Raven has two hard-coded OpenAI Codex defaults, and both are rejected by the current ChatGPT Codex API:
OpenAICodexProvider: openai-codex/gpt-5.1-codexProviderSpec for openai_codex: openai-codex/gpt-5-codex
This affects direct provider construction and onboarding paths that fall back to the registry default.
Reproduction on current main
Tested at c89460fa9f285e55942510b71722681e08645e83 after completing Raven's normal provider login openai-codex flow.
Calling OpenAICodexProvider.chat_with_retry() with either built-in default returns HTTP 400:
The 'gpt-5.1-codex' model is not supported when using Codex with a ChatGPT account.
The 'gpt-5-codex' model is not supported when using Codex with a ChatGPT account.
The same OAuth credentials successfully call an account-advertised model through Raven's real streaming provider path:
finish_reason=stop
content=RAVEN_E2E_OK
Model catalog evidence
The account-scoped Codex endpoint is:
GET https://chatgpt.com/backend-api/codex/models?client_version=<compatible Codex client version>
Authorization: Bearer <OAuth access token>
chatgpt-account-id: <OAuth account id, when available>
It returns model entries with an identifier, visibility, and priority. The first visible model in the ordered response was accepted by the same Raven provider call. The official Codex client conditionally includes the account header when an account id is available.
Two protocol constraints matter:
- Omitting
model from the Responses request returns HTTP 400 with The 'None' model is not supported.
- The catalog requires a compatible Codex
client_version; using Raven's package version can return an empty catalog even with HTTP 200.
Root cause
Raven treats an account-scoped, changing Codex model catalog as two unrelated static defaults. There is no single catalog integration or runtime resolution path, so the defaults can diverge from each other and from the models available to a particular account.
Expected behavior
- Raven should have one Codex model-catalog implementation shared by credential probing and automatic default resolution.
- Automatic selection should use the first visible account-advertised model, respecting the server's ordering, rather than a dated model id.
- An explicitly configured model must remain unchanged.
- An empty or malformed catalog must fail clearly instead of sending
None, an empty value, or a stale fallback to the Responses API.
- Catalog requests and parsing should have deterministic tests, including hidden models, malformed payloads, and conditional account-specific headers.
Related issue
Related to #212. That issue reports the same missing Codex catalog integration through raven provider test openai_codex, which currently calls the generic /v1/models route and returns HTTP 403 despite valid OAuth credentials.
Privacy
The evidence above contains no OAuth tokens, account ids, usernames, private paths, prompts beyond the fixed test marker, or response content beyond the fixed expected marker.
Summary
Raven has two hard-coded OpenAI Codex defaults, and both are rejected by the current ChatGPT Codex API:
OpenAICodexProvider:openai-codex/gpt-5.1-codexProviderSpecforopenai_codex:openai-codex/gpt-5-codexThis affects direct provider construction and onboarding paths that fall back to the registry default.
Reproduction on current main
Tested at
c89460fa9f285e55942510b71722681e08645e83after completing Raven's normalprovider login openai-codexflow.Calling
OpenAICodexProvider.chat_with_retry()with either built-in default returns HTTP 400:The same OAuth credentials successfully call an account-advertised model through Raven's real streaming provider path:
Model catalog evidence
The account-scoped Codex endpoint is:
It returns model entries with an identifier,
visibility, andpriority. The first visible model in the ordered response was accepted by the same Raven provider call. The official Codex client conditionally includes the account header when an account id is available.Two protocol constraints matter:
modelfrom the Responses request returns HTTP 400 withThe 'None' model is not supported.client_version; using Raven's package version can return an empty catalog even with HTTP 200.Root cause
Raven treats an account-scoped, changing Codex model catalog as two unrelated static defaults. There is no single catalog integration or runtime resolution path, so the defaults can diverge from each other and from the models available to a particular account.
Expected behavior
None, an empty value, or a stale fallback to the Responses API.Related issue
Related to #212. That issue reports the same missing Codex catalog integration through
raven provider test openai_codex, which currently calls the generic/v1/modelsroute and returns HTTP 403 despite valid OAuth credentials.Privacy
The evidence above contains no OAuth tokens, account ids, usernames, private paths, prompts beyond the fixed test marker, or response content beyond the fixed expected marker.