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

Start by tracing the Codex Remote desktop Queue path from follow-up submission to dispatch on the Mac1 execution host, then compare it with the mobile-client behavior described here. Review related issue #28346 for context. Done means queued follow-ups continue after Mac2 sleeps or disconnects while preserving shared queue synchronization, ordering, edits, reordering, and deletion.

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:

11. Connect the mobile app to the same Mac1 host.
12. Submit sequential work and background the mobile app.
13. 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

• #28346 also asks for queued and steering messages to be persisted remotely, but in the context of weak networks. This report isolates a stable-host/client-sleep case and the behavioral difference between desktop and mobile clients.

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.