Exact error
Match the message before using the fix
idle timeout waiting for SSEevent: response.failedresponse.failed: server_errorQuick answer
Start here
An `idle timeout waiting for SSE` message does not prove the server was silent. In the deterministic report, Codex had already parsed a terminal `response.failed` event but kept reading until EOF; an open socket then replaced the useful server error with the idle timeout. Update Codex and capture the raw SSE event before increasing retry or timeout values. A locally compiled patch in the issue is not an official signed release.
Diagnosis
Why it happens
- The affected client stores the terminal response error but continues consuming the stream until EOF.
- If the server leaves the connection open, the idle-timeout or a later transport error can overwrite the original failure.
- Separate backend failures can still occur; the client bug does not establish the provider's internal cause.
Safest first
Fixes, in order
Preserve the error that arrived before the timeout
Applies when: Logs show a terminal SSE event followed later by idle timeout
The earlier response.failed contains the actionable classification that the final message can hide.
- Record timestamps for headers, `response.failed`, EOF, and idle timeout.
- Save the response error code, message, request ID, and retry hint.
- Redact authorization headers, prompt content, images, and provider hostnames if private.
Expected: The server-side terminal error remains available for diagnosis instead of being reduced to a timeout.
Update before tuning transport settings
Applies when: The client is 0.153.4 or another build with the same behavior
Longer idle timeouts can only delay the misleading error; they do not repair terminal-event handling.
- Update Codex through an official channel.
- Fully restart Desktop/app-server so it uses the new executable.
- Reproduce once with unchanged provider, retry, and timeout settings.
Expected: A fixed build surfaces the terminal response error immediately, or the issue remains reproducible on a current version.
Validate the provider endpoint separately
Applies when: A custom Responses endpoint is configured
The source investigation also found real backend failures and one endpoint-path correction, but did not claim that the client patch repairs provider capacity.
- Confirm the provider base URL and wire API against the provider's current documentation.
- Use a minimal request outside Codex to see whether the provider emits `response.failed`.
- Escalate provider errors with their request IDs separately from the Codex stream-consumer bug.
Expected: Client error handling and the upstream provider failure are tracked as separate problems.
Verification
Prove the fix worked
- Trigger a controlled terminal SSE failure and confirm Codex exits without waiting for the full idle timeout.
- Confirm the original error code/message is preserved.
- Run a normal request afterward to verify the provider configuration remains functional.
Escalation
If it still fails
- Do not keep increasing `stream_idle_timeout_ms` for a stream that already declared failure.
- Do not install the issue author's unsigned local binary as though it were an official release.
- Do not claim the client bug caused every Azure or provider reconnect without matching event timing.
Scope
Environment and version notes
- The deterministic reproduction and local source patch target Codex CLI 0.153.4.
- The issue reports four regression tests passing after the local patch, but it remained unaccepted upstream at the review date.
- Source rechecked September 23, 2026.
Evidence
Sources
Source labels describe the evidence available on the checked date. A closed issue is not automatically a shipped fix.