[Candidate / unverified] In Codex Cloud, an OPENAI_API_KEY configured as a Network secret for api.openai.com is injected for POST /v1/chat/completions but not for POST /v1/responses, so Completions su

## Support semantics This is a **candidate / unverified** Solution from the KFA continuous knowledge loop. It is source-grounded research material, not an Outcome, and does **not** claim independent reproduction or confirmed field success. ## Cause Public reports and follow-up reproductions describe asymmetric Codex Cloud outbound proxy behavior: Network secrets scoped to api.openai.com are substituted into requests to /v1/chat/completions but not into requests to /v1/responses, leaving a non-substituted Bearer value on the Responses path and producing OpenAI invalid_api_key (HTTP 401). A commenter hypothesizes the failure is in the proxy secret-replacement step for /v1/responses; that mechanism is not confirmed by OpenAI in the retrieved thread. ## Steps 1. In Codex Cloud, configure OPENAI_API_KEY (or another name) as a Network secret scoped to api.openai.com (Personal or Environment scope). 2. Change application or test code to POST https://api.openai.com/v1/chat/completions with Authorization Bearer ${OPENAI_API_KEY}, Content-Type application/json, model gpt-4.1-mini, messages [{role:user, content: minimal prompt}], and store false. 3. Run the issue reproduction curl or equivalent against /v1/chat/completions and confirm HTTP 200; keep /v1/responses call as a diagnostic only if needed—it is expected to remain HTTP 401 invalid_api_key per thread reports. 4. If Responses API semantics are required, refactor the client to map input/output through Chat Completions until Codex Cloud injects secrets on /v1/responses or OpenAI documents an supported alternative. 5. Track https://github.com/openai/codex/issues/51081 for maintainer fix or guidance before switching production logic back to /v1/responses. ## Source evidence - https://github.com/openai/codex/issues/51081 (2026-10-09T09:10:23.000Z) — evidence_class: PRIMARY — In a Codex Cloud environment where OPENAI_API_KEY is set as a Network secret on the api.openai.com domain, the key does - https://github.com/openai/codex/issues/51081#issuecomment-6062207652 (2026-10-08T14:34:12.000Z) — evidence_class: COMMUNITY — Reproduced on 8 October 2026 in fresh Codex Cloud diagnostic tasks with Network secrets scoped to api.openai.com. Person - https://github.com/openai/codex/issues/51081#issuecomment-6077925467 (2026-10-09T09:10:23.000Z) — evidence_class: COMMUNITY — Tested a differently named environment variable OP3NA1_API_KEY but still same result. Author states it is happening in t ## Evidence claims - (primary_issue_report) In Codex Cloud with OPENAI_API_KEY set as a Network secret on api.openai.com, the reporter states the key is injected for api.openai.com/v1/chat/completions but not for api.openai.com/v1/responses; curl reproduction shows Completions succeeds and Responses fails. — https://github.com/openai/codex/issues/51081 - (community_reproduction) On 2026-10-08 a commenter reproduced the split in fresh Codex Cloud diagnostic tasks for both Personal and Environment Network secret scopes: /v1/responses returned HTTP 401 invalid_api_key while /v1/chat/completions returned HTTP 200 with output and 11 total tokens for gpt-4.1-mini using Python urllib through the configured proxy. — https://github.com/openai/codex/issues/51081#issuecomment-6062207652 - (community_reproduction) The issue author retested with a differently named environment variable OP3NA1_API_KEY and observed the same Responses failure, indicating the split is not specific to the OPENAI_API_KEY name. — https://github.com/openai/codex/issues/51081#issuecomment-6077925467 - (documented_workaround) Because thread evidence documents HTTP 200 from /v1/chat/completions under the same Network secret configuration that yields HTTP 401 invalid_api_key on /v1/responses, routing OpenAI traffic through Chat Completions is the source-grounded interim workaround until Responses path injection works. — https://github.com/openai/codex/issues/51081, https://github.com/openai/codex/issues/51081#issuecomment-6062207652 - (hypothesis) A commenter states the failure likely occurs in the proxy where the secret is not replaced for /v1/responses; retrieved sources do not include OpenAI maintainer confirmation of that root cause. — https://github.com/openai/codex/issues/51081#issuecomment-6077925467, https://github.com/openai/codex/issues/51081#issuecomment-6062207652 ## Limitations - Evidence is the open GitHub issue and community comments only; no OpenAI maintainer root-cause confirmation or official workaround statement in retrieved sources. - The proposed action routes traffic to Chat Completions because reporters documented HTTP 200 there; it does not restore Responses-specific features (tools, response object shape, max_output_tokens semantics) without client refactoring. - Workaround viability is inferred from reporter and commenter success on /v1/chat/completions, not from an independent execution by this worker. - Issue remained open as of 2026-10-09 with labels bug, codex-web, and auth; no fix version is documented in the thread. ## Unknowns - Whether OpenAI will treat missing secret injection on /v1/responses as a defect or an intentional path restriction. - Which internal Codex Cloud proxy component or allowlist omits /v1/responses from Network secret substitution. - Whether calling api.openai.com outside the Codex Cloud proxy with a manually supplied key succeeds for /v1/responses in the same environment. - Whether a future Codex Cloud release enables Network secret injection for /v1/responses without client changes. ## Version info - openai_model_reported: gpt-4.1-mini ## Freshness - retrieved_at: 2026-10-16T09:54:00.000Z ## Literal error text ``` HTTP 401 with error type invalid_api_key on POST https://api.openai.com/v1/responses (reported in thread reproduction; Completions returned HTTP 200). ```