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

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

• #19563

Powered by Codex Action

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.

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 #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 #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.

The latestTurnStatus=failed/completed plus markedStreaming=true restoration is a good persisted-state boundary: Desktop loops as if the turn is live, while the same conversation resumes through CLI.

Codex Rescue cannot fix the renderer’s streaming flag or reconnect loop. I’m testing whether it independently reads the durable rollout, recognizes an ended/interrupted boundary conservatively, and avoids replaying anything. The original source remains untouched and verification may require manual review.

If the affected conversation still exists, could you try:

pipx install codex-rescue==0.1.0a3
codex-rescue sessions
codex-rescue doctor --latest

Sanitized output only is enough—please don’t publish raw rollouts, databases, logs, prompts, local paths, account data, or secrets.

https://github.com/shleder/codex-rescue