Regression after unified desktop rollout: Responses WebSocket timeouts and stream disconnects

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

• #35574
• #35323
• #35513

Powered by Codex Action

Independent macOS corroboration with read-only local diagnostics.

Environment

• macOS 26.5.2 (25F84), arm64
• ChatGPT/Codex Desktop 26.727.40816 (build 6067)
• Bundled app-server/CLI 0.146.0-alpha.9.2
• ChatGPT authentication
• Models observed: gpt-5.6-terra and gpt-5.6-sol

Terminal stream failures

One long-running task recorded six terminal failures on July 30:

• Thread: 019faa40-b701-7a93-91af-c0aee186ca1b
• Failure timestamps (UTC): 18:34:01, 19:02:37, 21:53:42, 22:21:40, 22:41:20, 22:43:28
• Retained error:

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

Reconnect/compaction reproduction on July 31

A separate task repeatedly displayed Reconnecting 1/5 through 5/5 after tool calls during a four-minute turn. The turn eventually recovered and continued.

• Thread: 019fb53c-d8ce-7530-b988-a2f7f4ceb272
• Turn: 019fb930-a519-7c11-998a-82f0390f3b21
• Model: gpt-5.6-terra, reasoning effort max
• The structured log shows the Responses HTTPS transport during recovery.
• Immediately afterward it entered remote mid-turn compaction:

run_auto_compact{reason=ContextLimit phase=MidTurn}

• Latest request usage was 231,862 / 258,400 tokens.
• Cumulative task usage was approximately 110.1M tokens, mostly cached input.

This suggests context/remote-compaction pressure increases the failure rate, but it does not fully explain the separate terminal disconnects.

Network controls

At the same host:

• No active VPN, system proxy, or application firewall.
• No sleep, Wi-Fi roam, link-state change, or packet error correlated with the failures.
• 10/10 direct reachability checks to the Responses endpoint succeeded across IPv4 and IPv6.
• TLS connection time was approximately 44–59 ms.
• Network quality: approximately 632 Mbps down, 163 Mbps up.
• An authenticated /models request returned 200 OK 18 seconds before one stream failure.
• Other Codex tasks continued through the same backend.

Requested investigation

Please inspect the server-side records for the thread/turn IDs above and the WebSocket-to-HTTPS recovery path, especially during remote mid-turn compaction. The UI currently presents these retries as generic connectivity failures even when endpoint reachability and concurrent authenticated requests are healthy.

A supported HTTPS-only workaround or a more durable stream-resume/compaction fallback would help while this is investigated. No project content, local paths, credentials, or raw logs are attached.

Additional macOS desktop reproduction (2026-08-09) that may help confirm the issue is still present on a newer build.

Environment

• macOS 26.5.2 (arm64)
• ChatGPT desktop 26.803.41515 (bundle 6321)
• Bundled Codex: 0.147.0-alpha.6.5
• Long-running local-project task in the desktop app

Observed

1. A turn ran for about 18m49s and successfully wrote several local files, then failed with:

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

1. The files written before the disconnect remained intact, but the chat appeared permanently unable to connect.
2. An immediate status follow-up also appeared stuck and was later interrupted after about 77s.
3. The user started a separate recovery chat. The original chat later became active again without recreating it, and work could continue.
4. The failed turn contained no context-compaction event. This suggests the visible failure was transport/session-recovery related rather than caused by compaction.

Impact

The original task looked unrecoverable even though its local work survived, forcing the user to open a second chat to diagnose and recover it.

Expected

Automatic stream reconnection/resume, or a clear retry/recovery state that does not leave the chat appearing permanently unreachable.

I did not isolate local proxy/network conditions, so this is a corroborating field report rather than a controlled network reproduction. No project content, logs, session transcript, or thread IDs are attached.

Hi @anyawang1213-cell, regarding the missing tool output / unfinished call state in the transcript, Codex Rescue Alpha5 has bounded tool-correlation diagnostics to detect persisted correlation anomalies and incomplete turn boundaries without assuming non-execution.

To inspect the rollout locally and safely in read-only mode:

pip install codex-rescue==0.1.0a5
codex-rescue doctor <path-to-rollout.jsonl>

No private files need to be uploaded; please sanitize any repository details before sharing diagnostic output.

Additional macOS Codex Desktop reproduction with diagnostics uploaded via /feedback.

Feedback diagnostics

Feedback thread ID: 01a01813-25a9-7212-9f95-12e2e10f744f

Observed on 2026-08-19

Across multiple independent long-running local-project threads in Codex Desktop, the response stream repeatedly entered reconnect loops and failed with both of these errors:

stream disconnected before completion: idle timeout waiting for websocket

and:

stream disconnected before completion: Transport error: network error: error decoding response body

The failures frequently appeared during or immediately after automatic context compaction. One affected thread repeatedly cycled through Reconnecting 2/2 and later Reconnecting 3/5 while the underlying local worktree changes remained present.

Pattern / impact

• Reproduced across several independent Codex Desktop threads rather than one corrupted conversation.
• Ordinary internet connectivity remained healthy while the Codex stream was reconnecting.
• Local machine had >72 GB free disk space, so local storage pressure was not the apparent cause.
• Work already written to Git/worktrees generally survived, but the agent response stream/session became unreliable.
• Long-running tasks could remain trapped in reconnect cycles for hours, forcing manual stop-and-checkpoint recovery to avoid losing progress.
• The problem persisted even after splitting work into smaller checkpointed tasks and starting fresh Codex chats.

This looks closely aligned with the WebSocket/session-resume regression described in this issue. The /feedback submission was made from an affected Codex thread with current session logs included.

Please inspect the server-side records for feedback thread 01a01813-25a9-7212-9f95-12e2e10f744f, especially WebSocket timeout/resume behavior around automatic context compaction and fallback to HTTPS. A durable stream-resume path or supported HTTPS-only workaround would materially reduce the impact while this is investigated.

Additional reproduction after switching to a fresh, narrowly bounded checkpoint chat and committed handoff state.

Feedback thread for the affected account/session remains:
01a01813-25a9-7212-9f95-12e2e10f744f

On 2026-08-19, a new Codex Desktop chat was started from a clean committed checkpoint with a single bounded task: occurrence-level rights adjudication only. The task still entered a reconnect loop after about 1h49m and displayed a third related error signature:

stream disconnected before completion: WebSocket protocol error: Connection reset without closing handshake

The task eventually completed and committed its checkpoint successfully, so local work survived, but this confirms the transport problem persists even after:

• abandoning the original long-running thread,
• starting a fresh Codex chat,
• narrowing the task to one checkpoint,
• using a clean Git commit as the handoff,
• avoiding broad research and full-project rereads.

This strengthens the case that the failure is in WebSocket/session transport or resume behavior rather than ordinary client network quality or simply oversized monolithic tasks. Please include this error signature when inspecting the server-side diagnostics for the feedback thread.

Additional Windows reproduction on a newer build (2026-08-25, Asia/Shanghai).

• Windows 11 Pro 10.0.26200 x64
• Codex Desktop 26.818.41509; app-server/CLI 0.149.0
• gpt-5.6-sol, reasoning effort high
• Long-running local task; rollout ~22.9 MiB; request ~920 KB before compression (~346 KB zstd)

After a completed shell tool call, each sampling attempt returned HTTP 200 OK, then failed after roughly two minutes with:

stream disconnected before completion: Transport error: network error: error decoding response body

Codex exhausted retries 1/5 through 5/5 and the UI displayed Task encountered a system error. There were no HTTP 5xx responses, panic/fatal events, or error-level client logs; local Codex SQLite integrity checks returned ok.

The same thread has failed this way multiple times. Expected: durable stream resume/recovery and the underlying transport error shown in the UI. Full thread/turn IDs can be provided privately if needed.

Adding a recent macOS reproduction with a useful control:

Environment

• ChatGPT/Codex Desktop 26.818.61809 (build 7019)
• Bundled codex-cli 0.149.0-alpha.4.3
• gpt-5.6-sol, reasoning effort xhigh

Observed

• stream disconnected before completion: Transport error: network error: error decoding response body
• 10 identical failures across 4 sessions of the same long, tool-heavy research workflow.
• Other cases in the same workspace completed (14 successful turns), and two other local workspaces had 79 successful turns and one similar failure.
• macOS was rebooted; only one Clash Verge Rev core remained. No proxy error was recorded for the actual Codex route at failure time, while other Codex conversations remained healthy.

Most useful reproduction

• A failing session compacted successfully at 12:26:32 CST from approximately 243k tokens to approximately 22.8k.
• After compaction, the assistant emitted a progress update, entered reasoning, then produced no tool call or visible output for approximately 12 minutes.
• The response disconnected at 12:38:49 CST and entered the 1/5–5/5 reconnect loop.
• This indicates the failure is not simply context-window exhaustion or memory injection. It looks like a per-response stream/backend stall; other conversations can continue because their response streams are independent.

No project contents, case numbers, local paths, full logs, or session IDs are included here. I can provide sanitized session metadata if needed.