Codex Desktop on macOS gets stuck reconnecting because failed/completed turns are restored with markedStreaming=true #19690

Activity

1. wangyaok2

   added

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

   on Apr 26, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   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 Apr 26, 2026
3. github-actions commented on Apr 26, 2026

   

   github-actionsbot

   on Apr 26, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Desktop thrashes resume/unsubscribe when >4 heartbeat automations have target_thread_id #19563

   Powered by Codex Action
4. wangyaok2 commented on Apr 28, 2026

   

   wangyaok2

   on Apr 28, 2026

   Author

   More actions

   I checked #19563 more closely. It looks related, but not identical to this report.

   Both issues show the same suspicious symptom in the Desktop resume path: maybe_resume_success reports an already ended turn (completed or failed) while the conversation is still marked streaming (markedStreaming=true). That makes it look likely that the two reports share the same underlying resume/stream-state bug family.

   However, #19563 appears to be a specific automation-triggered repro: more than 4 heartbeat automations with target_thread_id cause repeated thread/read -> thread/resume -> maybe_resume_success -> thread/unsubscribe cycling, high CPU / Energy impact, and broad looping across multiple target threads.

   This report is different in one important way: the stuck reconnecting behavior reproduced for a normal conversation restore path without requiring heartbeat automations or the >4 target_thread_id condition. In this case, the same affected conversation can be resumed successfully from the CLI, while Desktop restore keeps behaving as if the thread is still streaming.

   So my current read is: related to #19563, and possibly the same underlying state-machine defect, but not a strict duplicate because the trigger path here does not depend on automations.
5. coindmit-cmyk commented on Aug 2, 2026

   

   coindmit-cmyk

   on Aug 2, 2026 – with ChatGPT Codex Connector

   More actions

   Windows confirmation: multi-chat reconnect state persists until a new message

   I am seeing what appears to be the Windows side of this Desktop resume/state-recovery bug, with transport failures related to #20739.

   Environment

   • Windows 11 Pro 64-bit, version 10.0.26200 (build 26200)
   • Codex Desktop 26.727.6591.0
   • Codex CLI 0.144.1
   • Observed on 2026-08-02
   • System proxy disabled
   • WinHTTP configured for direct access
   • Only two heartbeat automations exist; both are paused and have linked target threads. This is below the >4 target_thread_id trigger described in Desktop thrashes resume/unsubscribe when >4 heartbeat automations have target_thread_id #19563.

   User-visible behavior

   The issue occurs across unrelated local chats, not just one old or remote session.

   Affected turns show one of these errors:

   Reconnecting ... /5
   stream disconnected before completion: websocket closed by server before response.completed
   

   or:

   Reconnecting ... /5
   stream disconnected before completion: failed to send websocket request:
   IO error: An existing connection was forcibly closed by the remote host. (os error 10054)
   

   After the retries, Desktop can remain indefinitely in a pseudo-streaming/reconnecting state even though the network is healthy. Sending an additional user message sometimes makes the same chat responsive immediately. That suggests the new event is causing the renderer to reconcile stale turn state.

   The problem continued several hours after Desktop had updated and restarted, so it is not limited to the update interruption itself.

   Sanitized local evidence

   For 2026-08-02, aggregated Desktop logs showed:

   • resumeState=needs_resume: 31 occurrences
   • maybe_resume_success: 16 occurrences
   • 8 distinct affected conversations
   • Conversation state not found: 8 occurrences
   • unknown conversation: 20 occurrences
   • only one separate remote app-server WebSocket closure

   The currently affected chats are local (hostId=local). A floating avatarOverlay renderer was active and produced some of the missing/unknown-conversation events, while the primary renderer also handled resume activity.

   This looks like two related failure layers:

   1. The Responses WebSocket is reset before response.completed, matching Responses WebSocket closes before response.completed #20739.
   2. Desktop resume/renderer state does not reliably settle the interrupted turn, matching this issue. The chat may remain marked as active until another user event arrives.

   Network checks during a live failure

   • Three direct HTTPS requests to chatgpt.com succeeded consecutively.
   • Connection times were approximately 15-34 ms; total times were approximately 192-330 ms.
   • No WLAN, TCP/IP, DHCP, DNS, NLA, or NetworkProfile events were recorded in the relevant Windows system-log window.
   • OpenAI Status reported all systems operational at the time.

   This does not look like a general loss of internet connectivity. The 10054 reset affects the long-lived Responses WebSocket while ordinary HTTPS remains available.

   Expected behavior

   • If a stream closes before response.completed, Desktop should terminate or retry the affected turn with a bounded, actionable result.
   • A failed/interrupted/completed turn must not remain displayed as actively streaming after resume.
   • Sending a new user message should not be required to clear stale reconnecting state.
   • Resume state should be consistent between the primary renderer and optional overlay renderers.

   Raw logs are not attached because they can contain local paths, conversation IDs, remote-host aliases, and other private metadata. Redacted excerpts can be provided if a maintainer requests specific event windows.
6. pharmatorium commented on Aug 31, 2026

   

   pharmatorium

   on Aug 31, 2026

   More actions

   Additional reproduction on Codex Desktop 26.825.51511 (build 7377), bundled codex-cli 0.151.0-alpha.7.2, macOS 26.5.1 (25F80), arm64.

   Two unrelated local tasks simultaneously reproduced the completed-backend / streaming-UI mismatch:

   • Desktop kept showing “In progress” for roughly 3–4 hours, with the Stop button still visible.
   • Authoritative thread reads showed status=notLoaded and latest turn=completed; the actual turns had completed after about 26 and 32 minutes. No backend compute remained active.
   • Clicking Stop returned the German UI error “Chat konnte nicht gestoppt werden” (“Chat could not be stopped”), consistent with there being no active backend turn.
   • A message entered in the stale UI remained in a failed local queue with “Retry”; it was not accepted by the backend.
   • Navigating to another task and back did not reconcile the renderer state.
   • Resuming the exact existing session through the bundled CLI forced a fresh state transition. One affected task then appeared as idle; for the other, a minimal terminal no-op turn produced a fresh completed event. Existing results were preserved.

   Expected: when the latest turn is terminal, the Desktop renderer should immediately clear the streaming/in-progress state, hide/disable Stop, clear stale queue state, and allow a new turn.

   This appears to be the same root condition described here (latestTurnStatus=completed while the renderer remains marked streaming), with two additional user-visible consequences: cancellation errors and an unusable local message queue. I can provide sanitized screenshots and matching desktop-log excerpts if maintainers need them.
7. ChrisEvans2 commented on Sep 8, 2026

   

   ChrisEvans2

   on Sep 8, 2026

   More actions

   I can reproduce a closely related state-recovery failure on a newer Codex Desktop build.

   Environment

   • Codex Desktop: 26.901.51231
   • macOS 26.6.2 (Apple Silicon)
   • Model: gpt-5.6-sol, reasoning effort high
   • Local project task

   Timeline

   1. A turn started normally, emitted reasoning, read one local file, and then failed after about 10 minutes with:
      stream disconnected before completion: Transport error: network error: error decoding response body
   2. The rollout recorded task_complete with that error, but last_agent_message was empty.
   3. I sent continue in the same task.
   4. A new turn started, but the UI repeatedly restarted/appended the same beginning of the answer instead of completing. I eventually interrupted it manually.
   5. After reopening/resuming the task, Desktop logged latestTurnStatus=interrupted markedStreaming=true, along with:
      • Rebinding placeholder latest turn to incoming event
      • Conversation state not found
      • Received item/started for unknown conversation

   Additional session evidence

   • Before the disconnect, several distinct reasoning item IDs were completed with duplicated/cumulative summaries.
   • The follow-up continue turn never persisted a completed assistant message or a usable final answer.
   • The failed stream did not persist a usable provider response_id, so this evidence proves one Codex turn with multiple reasoning items, but not the exact number of provider Responses.
   • I am not attaching the raw session JSONL because it contains prompts, local paths, and identifiers.

   Expected behavior

   • A transport failure should leave the turn in a terminal, recoverable state.
   • Sending a follow-up after the failure should start from a clean state.
   • An interrupted/failed turn should not be restored with markedStreaming=true.
   • Partial or orphaned streamed items should not be repeatedly appended to the UI.

   This appears closely related to this issue. The additional user-visible symptom here is repeated answer content after sending continue, rather than only a reconnecting/Thinking state.
8. H644b commented on Sep 30, 2026

   

   H644b

   on Sep 30, 2026

   More actions

   I have the same problem
9. jordanschwartz-js commented on Oct 16, 2026

   

   jordanschwartz-js

   on Oct 16, 2026 – with ChatGPT Codex Connector

   More actions

   I am also experiencing recurring stuck follow-up messages in the macOS desktop app. After a response finishes, the next message can remain in the queue indefinitely. Fully quitting and reopening the app temporarily restores sending, but it recurs. Restarting is disruptive when other chats are running. Is there a supported recovery for just the affected chat without restarting the whole app?