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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on Jul 30, 2026
2. github-actions commented on Jul 30, 2026

   

   github-actionsbot

   on Jul 30, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex VS Code extension frequently disconnects with stream disconnected before completion #35574
   • Codex CLI Falling back from WebSockets to HTTPS transport #35323
   • Windows App Server direct-stdio synthetic turn has one observed Responses transport failure on CLI 0.145.0 #35513

   Powered by Codex Action
3. aandresalvarez commented on Jul 31, 2026

   

   aandresalvarez

   on Jul 31, 2026 – with ChatGPT Codex Connector

   More actions

   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.

   👍React with 👍1Reacted by Alvaro A. Alvarez
4. professional933 commented on Aug 9, 2026

   

   professional933

   on Aug 9, 2026

   Last edited by professional933

   More actions

   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)
   

   2. The files written before the disconnect remained intact, but the chat appeared permanently unable to connect.
   3. An immediate status follow-up also appeared stuck and was later interrupted after about 77s.
   4. The user started a separate recovery chat. The original chat later became active again without recreating it, and work could continue.
   5. 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.
5. boombx403-byte commented on Aug 18, 2026

   

   boombx403-byte

   on Aug 18, 2026

   More actions

   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.
6. IDEA-ag commented on Aug 19, 2026

   

   IDEA-ag

   on Aug 19, 2026 – with ChatGPT Codex Connector

   More actions

   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.
7. IDEA-ag commented on Aug 19, 2026

   

   IDEA-ag

   on Aug 19, 2026 – with ChatGPT Codex Connector

   More actions

   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.
8. PerrinYong commented on Aug 25, 2026

   

   PerrinYong

   on Aug 25, 2026 – with ChatGPT Codex Connector

   More actions

   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.
9. zhouzhikwo2 commented on Aug 26, 2026

   

   zhouzhikwo2

   on Aug 26, 2026

   More actions

   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.
10. Bananhylsa commented on Aug 30, 2026

    

    Bananhylsa

    on Aug 30, 2026

    Last edited by Bananhylsa

    More actions

    I can reproduce this regression on Windows.

    Desktop version: 26.825.6671.0
    Bundled Codex/app-server: 0.151.0-alpha.7.2
    Authentication: ChatGPT

    Responses error:
    stream disconnected before completion: failed to send websocket request:
    IO error: An established connection was aborted by the software in your
    host machine. (os error 10053)

    Feedback upload also fails:
    failed to upload feedback to Sentry:
    operation timed out

    Feedback ID:
    01a04d8c-3c2f-7691-bdec-093c191803b5

    WinHTTP is configured for direct access, with no proxy environment
    variables. TCP port 443 to the Sentry endpoint is currently reachable,
    so the upload timeout appears intermittent or application-specific.
    Long-running Codex tasks are affected, while some short tasks succeed.