Skip to content

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

Open
Open
Codex Desktop Remote Control transcript remains partial after sequence gap despite complete canonical history#35727
Labels
appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)remote

Description

@jonathanli12
jonathanli12
opened on Jul 28, 2026

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

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    remote
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    app-serverIssues involving app server protocol or interfaces
    on Jul 28, 2026

  2. github-actions commented on Jul 28, 2026

    @github-actions
    github-actionsbot
    on Jul 28, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. jonathanli12 commented on Jul 28, 2026

    @jonathanli12
    jonathanli12
    on Jul 28, 2026 – with ChatGPT Codex Connector
    Author

    Additional sanitized evidence from the representative reconnect:

    • Recovery logged previousStreamingCount=11, previousRoleCount=5, and markedCount=5, so only a subset of tasks previously considered streaming were marked as needing resume.
    • The app subsequently completed a thread/read / thread/resume path for the current route and reported reconnect recovery done.
    • Later, the visible primary renderer still logged missing-turn / missing-item state and dropped command execution events for the affected task.

    This does not prove the subset-marking logic is the sole cause, but it narrows the likely failure boundary: reconnect recovery can report success without replacing all stale renderer turn/item state from canonical history.

  4. hd2210 commented on Oct 12, 2026

    @hd2210
    hd2210
    on Oct 12, 2026

    I can reproduce what appears to be the same Remote Control streaming/synchronization issue in a Mac-to-Mac setup.

    Environment

    • Codex Desktop version: 26.1007.30912 on both Macs
    • Host (remote machine): Mac mini, running Codex locally
    • Client (controlling machine): MacBook Air, using Codex Desktop Remote Control
    • Host network: OpenWrt with Clash transparent proxy
    • Client network: Company Wi-Fi with Clash TUN enabled
    • Tailscale: Installed on both machines

    Symptoms

    1. Remote Control initially connects successfully, and I can open the Mac mini's active Codex session from my MacBook Air.
    2. After some time, the remote client stops displaying new output, sometimes remaining stuck on "Loading model...".
    3. Codex continues executing normally on the Mac mini. I have verified directly on the host that the task is still running and producing output.
    4. When I leave and reopen the remote session on my MacBook Air, all previously missing output appears immediately.
    5. Live streaming then resumes temporarily, but the problem occurs again.

    This is reproducible and significantly affects long-running tasks.

    Diagnostic findings

    I examined both the Codex app-server SQLite logs and the Codex Desktop application logs.

    The client-side Desktop logs contain repeated occurrences of:

    • SEQUENCE_GAP
    • UNKNOWN_CONVERSATION
    • TRANSPORT_CLOSED
    • CONNECTION_FAILED
    • WEBSOCKET_ERROR
    • WebSocket close code 4000

    There were multiple clusters of sequence-gap errors, along with repeated WebSocket and transport failures.

    The Rust-side app-server logs also showed intermittent remote-control WebSocket disconnections, including:

    remote control websocket reader disconnected,
err: failed to read from websocket:
IO error: peer closed connection without sending TLS close_notify

    And reconnection failures such as:

    failed to connect to app-server remote control websocket:
IO error: tls handshake eof

    These Rust-side connection errors were observed on the MacBook Air, although they may relate to its own Remote Control host connection rather than the client-side subscription to the Mac mini.

    Troubleshooting performed

    • Confirmed that the Mac mini continues processing tasks normally while remote output is frozen.
    • Confirmed that both machines use the exact same Codex Desktop version (26.1007.30912).
    • Enabled Clash TUN on the MacBook Air, which resolved the initial Remote Control connectivity issue but did not resolve the recurring live-output freezes.
    • Confirmed basic HTTPS connectivity to the Remote Control endpoint.
    • Reopening the affected remote session consistently restores the missing output without restarting the task.

    Suspected issue

    The behavior suggests that the remote event stream may be interrupted or develop a sequence gap, and the client does not reliably recover its live subscription afterward.

    The fact that reopening the session immediately restores the complete output suggests that the host-side execution and persisted conversation state remain intact, while the client-side live synchronization becomes stale.

    I cannot yet determine whether the initial interruption is caused by the network/proxy or the Remote Control transport itself. However, the failure to recover live updates appears to be an important part of the issue.

    Expected behavior

    Remote Control should automatically reconnect, recover any missing events, and continue streaming new output without requiring the user to manually leave and reopen the session.

    Is this a known issue in build 26.1007.30912? Are there any workarounds or additional diagnostics that would help identify why live event synchronization fails to recover?

    I can provide additional sanitized logs or perform targeted tests if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)remote

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions