Skip to content

Remote follow-up queue stops dispatching when the controlling desktop client sleeps #33416

Open
Open
Remote follow-up queue stops dispatching when the controlling desktop client sleeps#33416
Labels
appIssues related to the Codex desktop appbugSomething isn't workingremotesessionIssues involving session (thread) management, resuming, forking, naming, archiving

Description

@hrvojepavlinovic
hrvojepavlinovic
opened on Jul 15, 2026

What variant of Codex are you using?

Codex Remote in the ChatGPT desktop app, with one Mac acting as the always-on execution host and another Mac acting as the portable controlling client.

Version and environment

Mac1 — execution host

  • ChatGPT desktop app: 26.707.62119 (build 5211)
  • Bundled Codex CLI: codex-cli 0.144.2
  • macOS 15.6 (24G84), arm64
  • Kept awake, powered, online, and running the Codex host throughout the reproduction

Mac2 — remote controlling client

  • Portable Mac running the Codex/ChatGPT desktop app
  • Connected to Mac1 through Codex Remote
  • "Prevent sleep while running" and Amphetamine are enabled, but this report is specifically about the queue surviving after the controlling client sleeps

Control case

  • ChatGPT mobile app connected to the same Mac1 host

What issue are you seeing?

Follow-up messages queued from Mac2 into an existing thread running on Mac1 stop dispatching when Mac2 sleeps or its lid is closed, even though Mac1 remains awake, online, and available.

The active turn continues and completes on Mac1. However, the next queued follow-up does not begin until Mac2 wakes again. This makes the queue appear to be owned or dispatched by the originating desktop client rather than persisted on the execution host.

The mobile app behaves differently: sequential work submitted through mobile continues running on Mac1 while the mobile app is backgrounded or inactive.

Steps to reproduce

  1. Keep Mac1 awake, powered, online, and running Codex with Remote enabled.
  2. Connect to Mac1 from the Codex desktop app on Mac2.
  3. Open an existing thread whose execution host is Mac1.
  4. Start a turn that takes long enough to queue several follow-ups.
  5. From Mac2, use Queue to add multiple sequential follow-up messages to that same thread.
  6. Confirm that the follow-ups are visible as queued.
  7. Close Mac2's lid or allow Mac2 to sleep, while leaving Mac1 awake and online.
  8. Wait for the active turn on Mac1 to finish.
  9. Observe that the next queued follow-up does not start.
  10. Wake Mac2 and observe that queue dispatch can continue.

Control comparison:

  1. Connect the mobile app to the same Mac1 host.
  2. Submit sequential work and background the mobile app.
  3. Observe that work continues on Mac1 without the mobile app remaining active.

Expected behavior

Once a remote client has submitted follow-up messages and they are shown as queued, the queue should be persisted and dispatched by the execution host.

Specifically:

  • queued follow-ups should continue after the originating client sleeps, disconnects, or closes;
  • queue state should synchronize across connected desktop and mobile clients;
  • FIFO ordering, edits, reordering, and deletion should operate on the shared host-side queue;
  • dispatch should pause only when the execution host is unavailable, a turn needs user approval/input, or a turn fails/blocks.

Actual behavior

The active turn runs on Mac1, but queued follow-ups submitted from Mac2 depend on Mac2 remaining awake. Sleeping the portable controlling client prevents the host from starting the next queued turn.

Why this matters

Remote is most useful for handing long, sequential workflows to an always-on host. Requiring the portable controlling client to stay awake defeats that workflow and makes a large queued batch unreliable.

This is particularly surprising because the mobile client already appears able to hand work to the same host without remaining active.

Related issue

Additional information

This may be either a bug in desktop Remote queue ownership or a missing host-side queue feature. The user-facing behavior would be clearest if queued messages belonged to the target thread on Mac1 rather than to whichever remote client originally entered them.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    remote
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Jul 15, 2026

  2. github-actions commented on Jul 15, 2026

    @github-actions
    github-actionsbot
    on Jul 15, 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. hrvojepavlinovic commented on Jul 15, 2026

    @hrvojepavlinovic
    hrvojepavlinovic
    on Jul 15, 2026 – with ChatGPT Codex Connector
    Author

    I traced the current open-source boundary to see whether this could be fixed directly in openai/codex.

    Findings

    1. The remote-control transport currently forwards JSON-RPC messages received from a connected client to app-server. It tracks per-client connection/stream sequence state, but it does not own or persist a user follow-up queue. If there is no live initialized client connection, a non-initialize client message is ignored.

      Source: ClientTracker::handle_message

    2. The app-server v2 turn surface currently exposes turn/start, turn/steer, and turn/interrupt; there is no turn/queue / turn/enqueue request or shared queue-state API that a remote client could hand off to the host.

      Source: app-server request declarations

    3. The open-source TUI queue is explicitly client/UI-owned: InputQueueState keeps queued follow-up messages in an in-memory VecDeque<QueuedUserMessage>.

      Source: TUI InputQueueState

    This matches the observed behavior: Mac2 appears to retain the remaining queued follow-ups locally and only submits the next turn after receiving completion. When Mac2 sleeps, Mac1 has no host-owned queue to continue dispatching. The mobile client appears to use a different handoff/background path.

    Likely fix boundary

    A complete fix seems to require both:

    • a host-owned queue contract/state in app-server (including FIFO ordering, queue listing/notification, mutation, dedupe, and stop-on-blocked/approval semantics); and
    • desktop client changes so Queue submits the item to that host-owned queue immediately rather than retaining it only in the originating renderer.

    Because the desktop client source is not present here, a transport-only change in this repository would not fix the current desktop behavior by itself.

    Contribution question

    Would the team prefer a host-side app-server primitive such as turn/queue, or is queue persistence intended to live in the remote-control backend/product layer?

    The repository's contribution policy says external PRs are invitation-only, so I have not opened an unsolicited implementation PR. If the team confirms the desired ownership/API and invites a contribution, I would be happy to prepare a focused protocol + app-server implementation with integration coverage.

  4. wayfront-bot commented on Jul 26, 2026

    @wayfront-bot
    wayfront-bot
    on Jul 26, 2026

    Additional reproduction: queued follow-ups also stall on iOS

    The original report says that mobile behaves differently and continues handing work to the host while the app is inactive. We can reproduce the queue-stalling problem on the Codex/ChatGPT iOS app as well, specifically when the iOS device is locked.

    Steps to reproduce

    1. Open a task in the Codex/ChatGPT iOS app while a turn is already running on the remote execution host.
    2. Add one or more follow-up messages and confirm that the UI shows them as queued.
    3. Lock the iPhone screen.
    4. Wait long enough for the active turn to finish.
    5. Observe that the next queued follow-up does not start.
    6. Unlock the phone and foreground the app.
    7. Observe that queue delivery resumes.

    Actual behavior

    The running turn can finish on the host, but the next queued message is not dispatched while the iPhone is locked. Dispatch resumes only after the iOS app is foregrounded.

    Expected behavior

    Once the UI acknowledges a follow-up as queued, the queue should belong to the target task or execution host and continue independently of the originating iOS app. If iOS background-execution limits make that impossible by design, the UI should warn that the app must remain open before accepting multiple queued messages.

    This suggests the apparent desktop/mobile difference in the original report is narrower than stated: mobile may continue in some backgrounded states, but an iOS lock-screen transition still exposes the same client-owned queue behavior. No session logs or project details are included.

  5. IgorGanapolsky commented on Aug 21, 2026

    @IgorGanapolsky
    IgorGanapolsky
    on Aug 21, 2026

    The reporter's own trace is the right diagnosis: the follow-up queue lives on the originating desktop client (InputQueueState / renderer), not on the execution host. Mac1 can finish the current turn, but the next queued message is only submitted after Mac2's client wakes and sees completion. That is fail-closed from the host's point of view — and the UI should stay fail-closed. If the controlling client slept, do not claim the remaining queue is live or already handed off. A simple heartbeat / last-seen on the dispatcher would make the stall visible instead of silent.

    Until app-server owns a host-side turn/queue (or equivalent) and the desktop Queue action enqueues there immediately, overnight sequential work cannot depend on the portable client remaining connected. Persist the remaining items on Mac1 at enqueue time; dispatch should pause only for host unavailability, approval, or a blocked turn.

    Hosted Hermes on a fenced VPS, $10/mo, 14-day trial, cancel anytime, approvals in thumbgate.app. https://thumbgate.app

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 appbugSomething isn't workingremotesessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions