Remote Control task stays spinning after host turn completes following sequence gap #35955

Summary

After a Remote Control WebSocket sequence gap, a turn can finish and render correctly on the remote host while the controlling macOS Codex Desktop app continues to show an indefinite spinner.

In the observed case, the controller's global task index already reported the task as idle, but the task-specific view remained stuck at resumeState=resuming with streamRole=null. The app repeatedly retried thread/resume instead of reconciling the completed canonical state and clearing the spinner.

Diagnostics were also submitted through /feedback on 2026-07-29.

Environment

• Controller: Codex Desktop for macOS 26.721.81911 (build 5973)
• Controller OS: macOS 27.0 (26A5388g), arm64
• Remote host: Windows PC
• Remote app-server: 0.146.0-alpha.3.1
• Transport: managed Remote Control WebSocket
• A second remote Mac was also configured; both remote connections logged sequence gaps during the same diagnostic window

Reproduction

1. Open a task on a remote host from the macOS Codex Desktop app.
2. Leave the task open while a longer turn runs.
3. Allow the Remote Control WebSocket stream to encounter a sequence gap and reconnect.
4. Let the turn finish on the remote host, where its final output renders correctly.
5. Return to or observe the same task on the controller.

Expected behavior

After reconnecting, the controller should rehydrate the latest canonical turn state and clear the spinner once the task is complete. Recovery retries should be bounded and should expose an actionable reconnect error if hydration cannot succeed.

Actual behavior

• The remote host has the complete final output.
• The controller's global task index reports the task as idle.
• The controller task row/view keeps spinning indefinitely.
• The task-specific view remains resumeState=resuming, streamRole=null.
• Task-specific hydration/resume calls repeatedly fail with app-server unavailable/not-found behavior.

Sanitized diagnostic evidence

Representative log events:

remote control app-server stream sequence gap detected
closeCode=4000
thread/resume -> -32000 Codex app-server is not available
websocket_reconnect_marked_threads_needing_resume ... markedCount=0 previousStreamingCount=0
thread_stream_view_activity_changed ... resumeState=resuming streamRole=null

Within one controller log, the affected task generated approximately 100 failed thread/resume attempts. The same window contained 105 sequence-gap closes for the Windows PC connection and 101 for the other configured remote Mac.

The important state divergence was:

global task index: idle
remote host transcript: complete
task-specific controller view: resuming indefinitely

Suspected failure mode

The spinner appears to be driven by stale per-task hydration/resume state that is not overwritten by the completed canonical/index state. Reconnect recovery reports markedCount=0 and previousStreamingCount=0, but it also leaves the existing task view in resuming, producing an unbounded retry loop.

This suggests two related issues:

1. sequence-gap recovery does not always rehydrate or reconcile the active task; and
2. the renderer does not treat a completed/idle canonical state as authoritative enough to clear stale resuming UI state.

Related issues

• Codex Desktop Remote Control transcript remains partial after sequence gap despite complete canonical history #35727 — same Remote Control sequence-gap family, but reported as a partial transcript; this report adds the indefinite spinner, idle versus resuming divergence, and retry storm.
• macOS Codex App repeatedly resets healthy Remote Control streams with "stream became unknown" and sequence gaps #32241 — repeated healthy Remote Control streams being reset with sequence gaps.
• Codex Desktop session stuck as follower after backend thread is idle #24217 — similar completed backend versus stale spinner, but involving local follower/owner routing rather than Remote Control with streamRole=null.

Privacy

This public report intentionally omits task titles, thread IDs, host/account identifiers, and local filesystem paths. Full diagnostics are available through the submitted /feedback report.