What happens
The simple-completion path (utility model: progress narration, titles) can pair an api_key auth profile with the ChatGPT-backend Codex transport for OpenAI models — a combination that can never authenticate. On a gateway whose primary rides Codex OAuth (openai/gpt-5.6-sol), the derived utility model from #103769 (openai/gpt-5.6-luna) resolves the openai:api-key profile but the prepared model targets https://chatgpt.com/backend-api/codex (api: openai-chatgpt-responses). The backend rejects API keys, so every narration/title call fails and (before #104770) did so silently.
Evidence (2026-07-11, live gateway)
Reproduced via prepareSimpleCompletionModelForAgent({ agentId: "main", useUtilityModel: true, ... }) with the plugin metadata snapshot installed:
selection: {"provider":"openai","modelId":"gpt-5.6-luna","runtimeProvider":"openai", ...}
auth.mode: api-key profileId: openai:api-key <- valid key (verified 200 against api.openai.com/v1/responses with gpt-5.6-luna)
model.baseUrl: https://chatgpt.com/backend-api/codex model.api: openai-chatgpt-responses
Gateway log for the Discord session agent:main:discord:... at 23:54:57+01:00:
progress-narrator: completion failed: 401 Unauthorized - Invalid access token
The same key completes gpt-5.6-luna directly against https://api.openai.com/v1/responses (HTTP 200), so the credential is fine — the transport pairing is wrong. Note the pre-restart gateway process on the same code paired the same call with plain api.openai.com instead (its 401s named Incorrect API key provided), so the pairing appears state-dependent; whichever way it lands, one auth mode is always broken.
Expected
Transport must follow auth mode for OpenAI simple completions: api_key -> plain https://api.openai.com/v1/responses; ChatGPT-backend Codex transport only with (refreshed) Codex OAuth. Relevant code: resolveSimpleCompletionRuntimeProvider in src/agents/simple-completion-runtime.ts, openAIProviderUsesCodexRuntimeByDefault in src/agents/openai-routing.ts.
Consequence today: #103769's derived default utility model is dead on arrival for ChatGPT-OAuth-primary setups — the exact setups it was meant to serve.
Notes
What happens
The simple-completion path (utility model: progress narration, titles) can pair an
api_keyauth profile with the ChatGPT-backend Codex transport for OpenAI models — a combination that can never authenticate. On a gateway whose primary rides Codex OAuth (openai/gpt-5.6-sol), the derived utility model from #103769 (openai/gpt-5.6-luna) resolves theopenai:api-keyprofile but the prepared model targetshttps://chatgpt.com/backend-api/codex(api: openai-chatgpt-responses). The backend rejects API keys, so every narration/title call fails and (before #104770) did so silently.Evidence (2026-07-11, live gateway)
Reproduced via
prepareSimpleCompletionModelForAgent({ agentId: "main", useUtilityModel: true, ... })with the plugin metadata snapshot installed:Gateway log for the Discord session
agent:main:discord:...at 23:54:57+01:00:The same key completes
gpt-5.6-lunadirectly againsthttps://api.openai.com/v1/responses(HTTP 200), so the credential is fine — the transport pairing is wrong. Note the pre-restart gateway process on the same code paired the same call with plainapi.openai.cominstead (its 401s namedIncorrect API key provided), so the pairing appears state-dependent; whichever way it lands, one auth mode is always broken.Expected
Transport must follow auth mode for OpenAI simple completions:
api_key-> plainhttps://api.openai.com/v1/responses; ChatGPT-backend Codex transport only with (refreshed) Codex OAuth. Relevant code:resolveSimpleCompletionRuntimeProviderinsrc/agents/simple-completion-runtime.ts,openAIProviderUsesCodexRuntimeByDefaultinsrc/agents/openai-routing.ts.Consequence today: #103769's derived default utility model is dead on arrival for ChatGPT-OAuth-primary setups — the exact setups it was meant to serve.
Notes
../codexfor the app-server/responses protocol) per repo policy.models status --proberouting api_key profiles through the codex app-server is also tracked in Utility-model narration fails silently on dead API-key profiles; models status hides the utility model #104764.agents.defaults.utilityModel: "anthropic/claude-haiku-4-5".