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.

• #30822
• #29609
• #29794
• #30609

Powered by Codex Action

Adding another data point for this issue.

I’m seeing the same error:

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

Observed behavior:

• The failure tends to happen after a Codex session has accumulated a large amount of context.
• Once the context grows, Codex can get interrupted by the remote compact / responses stream failure, forcing the user to stop and start a new chat/session.
• This significantly reduces productivity during long-running coding tasks.
• After manually compressing/reducing the context, the timeout stopped occurring.

This makes the issue look strongly correlated with large thread context and/or the remote compaction payload/stream path, rather than a simple local network problem.

Expected behavior:

• Remote compact should handle large sessions reliably.
• If compaction fails, the session should remain recoverable and should not force the user to create a new chat/session.
• Ideally Codex should compact earlier, reduce the compaction payload, retry/fallback more robustly, or surface a safe recovery path before the session becomes stuck.

Please prioritize a fix for long-context remote compaction / responses stream reliability.

Adding a reproducible macOS Codex App data point from 2026-07-23.

Environment:

• macOS on Apple Silicon
• Codex CLI, managed app server, and app-server protocol version: 0.144.6
• ChatGPT-backed Codex App task

The exact error occurred twice in one day across two different workloads:

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

1. A bounded background research task disconnected before returning or

persisting its result.

1. A foreground operational-diagnosis task disconnected after several

successful tool calls, before it could create the issue and finish the
remediation. The App UI displayed the error directly.

The second occurrence is important because it was not merely an idle background
worker or a remote-compaction-only symptom: an actively progressing foreground
turn was terminated. The managed app server remained running, and GitHub/API
connectivity succeeded immediately afterward. No logout, restart, upgrade, or
local-state deletion was attempted.

Expected behavior: a transient responses-stream failure should retry/resume
without terminating the turn, and already completed tool-call state should
remain recoverable so the user can continue the same operational task.

Correction to my previous recurrence report: later network diagnostics found a local confounder for the 2026-07-23 15:24 CST event.

An anonymized shared proxy leaf was consistently failing direct health probes across Discord, GitHub, GitHub Raw, OpenAI WebSocket, and the ChatGPT responses endpoint during the correlated incident window. That leaf has now been removed from the local persistent candidate pools.

Therefore, please do not treat this particular 15:24 occurrence as a clean Codex App-only reproduction. The earlier background occurrence may still be relevant, and I will monitor after the local network repair before attributing another recurrence upstream.

Final local follow-up: the confounder was two distinct failed proxy leaves rather than one. Both were removed only from their affected persistent candidate pools.

After an OpenClash-only restart and a 10-minute soak, all remaining controller candidates passed the Discord, GitHub, GitHub API/Raw, OpenAI WebSocket, and ChatGPT responses probes; client-path checks also passed.

This further disqualifies my 2026-07-23 15:24 CST event as a clean App-only reproduction. I will report a new occurrence only if it happens after this local repair.