stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #37863
• #37467

Powered by Codex Action

I can reproduce the same exact error on macOS in Codex Desktop:

stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)

Environment

• Codex Desktop: 26.820.60940 (build 7119)
• macOS: 26.5.1
• Architecture: Apple Silicon (arm64)
• Observed: 2026-08-27 JST

Important context-size signal

The failures are concentrated in one unusually large, image-heavy thread:

• Local rollout size: approximately 115 MB (the next-largest local thread is approximately 59 MB)
• 27 turn contexts
• 70 image inputs
• 377 custom tool outputs totaling approximately 106.6 MB
• 7 automatic context compactions

The same thread failed on three consecutive follow-ups. The turns lasted approximately 43 minutes, 5 minutes 47 seconds, and 2 minutes 26 seconds before ending with the same stream-disconnected error. Some turns had already emitted commentary, reasoning, file changes, and tool results before the stream failed.

Other fresh Codex threads remained usable at the same time. A basic live connectivity check to chatgpt.com/backend-api/codex/responses also completed in about 0.13 seconds (HTTP 405 for an unauthenticated GET), so the endpoint was reachable when checked. This suggests that thread size / repeated compaction / long-lived streaming may be a contributing factor rather than a complete local network outage.

Reproduction pattern

1. Open an existing Codex Desktop thread containing many image inputs and large tool outputs.
2. Continue working through multiple document/PDF generation and validation turns.
3. Allow automatic context compaction to occur several times.
4. Send a short follow-up such as “continue”.
5. Codex attempts to reconnect up to 5 times, then the turn fails with the error above.

Expected behavior

• Compaction should keep a large thread resumable without repeatedly losing the response stream.
• If the retained thread state is too large or unhealthy, the app should surface a clear recoverable state or offer a checkpoint/handoff to a fresh thread.
• A transient stream failure should resume without terminating a turn after tools have already completed.

Privacy note

I am intentionally not attaching the raw 115 MB rollout, screenshots containing private document content, local paths, account identifiers, or the affected thread ID. I can provide redacted diagnostics through a private support channel if needed.