Codex Desktop Remote Control transcript remains partial after sequence gap despite complete canonical history

App version

• Viewer Mac: Codex App 26.721.41059 (bundle 5848)
• Host Mac: Codex App 26.721.41059 (bundle 5848)
• Connection: macOS Codex Desktop to macOS Codex Desktop through Remote Control

Issue

A remote task continues normally on the host and reaches completion, but the viewer Mac shows only an early portion of the streamed transcript. The viewer pane never appends the remaining progress or final response, even though canonical thread history on the host contains the completed turn.

In one reproduced incident on 2026-07-28:

• Approximately 03:28 UTC: the remote turn began.
• Approximately 03:37 UTC: the viewer detected a Remote Control sequence gap.
• Approximately 04:00 UTC: the host completed the turn normally.
• After completion: canonical thread history returned the complete final response, while the viewer pane remained partial.

The host app-server stayed running. Both devices used the same Codex build, so this does not appear to be version skew.

Minimal reproduction

1. Connect from one Mac running Codex Desktop to another Mac through Remote Control.
2. Start a sufficiently long or event-heavy task on the host and keep its task pane open on the viewer.
3. Allow a brief relay/WebSocket interruption or sequence gap to occur while the turn is streaming.
4. Observe that the host continues executing and eventually completes.
5. Observe that the viewer transcript stops at an earlier point and does not receive the remaining progress or final response.
6. Read the completed turn from canonical thread history and confirm that the missing final content was persisted on the host.

Expected behavior

After a sequence gap or reconnect, the viewer should rehydrate the active turn from canonical history and then resume live deltas. A completed host turn should always become complete in the viewer pane.

Actual behavior

The viewer reconnects, but its renderer can retain an incomplete turn. Logs then contain missing-state errors and later output deltas are dropped. The visible transcript remains permanently partial even after the host completes.

Sanitized evidence

Across the examined 2026-07-27 to 2026-07-28 window for the affected host connection, the viewer recorded:

• 24 sequence-gap events
• 26 pong timeouts
• 6 unknown-stream events

Relevant viewer-log strings:

remote control app-server stream sequence gap detected
remote control app-server stream became unknown
Synthesizing missing turn
Item not found in turn state
outputDelta for missing item

The evidence supports, but does not conclusively prove, this recovery failure: after a gap or reconnect, incremental renderer state is incomplete; later events refer to missing turns/items and are discarded. A robust recovery path would replace or reconcile the active renderer turn from canonical thread/read state before processing more deltas.

Potentially related issues

• #32241 reports the same recurring stream became unknown and sequence gap detected Remote Control resets. This report adds the persistent post-reconnect transcript-hydration failure despite complete canonical history.
• #23482 reports Remote Control state-propagation problems and unknown-conversation events while the host app-server remains responsive.

No transcript bodies, prompts, project or personal names, local paths, account or host identifiers, thread or turn identifiers, task URLs, credentials, tokens, or raw logs are included.