Environment: ChatGPT desktop 26.810.41047 (macOS, Darwin 25.3.0), bundled codex-cli 0.148.0-alpha.9, model gpt-5.6-sol (high/max reasoning effort), service_tier priority, ChatGPT-plan auth.
Symptom: Sampling over wss://chatgpt.com/backend-api/codex/responses goes silent mid-turn. The client detects the dead stream only via a 300s idle timeout (codex_core::responses_retry: stream disconnected before completion: idle timeout waiting for websocket; sometimes IO error: Connection reset by peer (os error 54)). Each retry cycle is a ~5-minute user-visible stall with frozen token counts.
Evidence (2026-08-14, UTC):
- Thread
01a00079-2445-7f01-a7a1-2764c376afe9: 11 stalls of 301–310s between 13:33–14:35, including four consecutive (13:59 → 14:15).
- Turn
01a00191-22f6-79f1-a260-71201ed53982: exhausted retries 5/5 at 19:17.
- A prior incident produced 16 five-minute reconnects across three tasks in one day.
Aggravating factors:
responses_websockets / responses_websockets_v2 are stage removed in codex features list — users cannot opt out of the websocket transport.- Built-in provider override is rejected ("model_providers contains reserved built-in provider IDs"), so
supports_websockets / stream_idle_timeout_ms are unreachable.
- HTTPS fallback only engages after 5 failed retries (~25 minutes of stalling).
The network here has documented upstream packet loss under load, which is presumably the trigger — but SSE-based clients on the same link detect drops and recover in seconds. The websocket transport takes 300s per detection with no user recourse.
Request: websocket-level keepalive/liveness so a dead stream is detected in seconds rather than 300s; and/or restore the transport opt-out; and/or engage the HTTPS fallback on the first idle timeout instead of the fifth.
Related: #27625, #28579
Environment: ChatGPT desktop 26.810.41047 (macOS, Darwin 25.3.0), bundled codex-cli 0.148.0-alpha.9, model gpt-5.6-sol (high/max reasoning effort), service_tier priority, ChatGPT-plan auth.
Symptom: Sampling over
wss://chatgpt.com/backend-api/codex/responsesgoes silent mid-turn. The client detects the dead stream only via a 300s idle timeout (codex_core::responses_retry:stream disconnected before completion: idle timeout waiting for websocket; sometimesIO error: Connection reset by peer (os error 54)). Each retry cycle is a ~5-minute user-visible stall with frozen token counts.Evidence (2026-08-14, UTC):
01a00079-2445-7f01-a7a1-2764c376afe9: 11 stalls of 301–310s between 13:33–14:35, including four consecutive (13:59 → 14:15).01a00191-22f6-79f1-a260-71201ed53982: exhausted retries 5/5 at 19:17.Aggravating factors:
responses_websockets/responses_websockets_v2are stageremovedincodex features list— users cannot opt out of the websocket transport.supports_websockets/stream_idle_timeout_msare unreachable.The network here has documented upstream packet loss under load, which is presumably the trigger — but SSE-based clients on the same link detect drops and recover in seconds. The websocket transport takes 300s per detection with no user recourse.
Request: websocket-level keepalive/liveness so a dead stream is detected in seconds rather than 300s; and/or restore the transport opt-out; and/or engage the HTTPS fallback on the first idle timeout instead of the fifth.
Related: #27625, #28579