iOS/macOS Remote Control broken after desktop update: host online, mobile 403/offline/stale Plan state

Additional Android/app-server signal here.

Environment:

• Codex desktop: 26.513.20950, bundle 2816
• Codex CLI: 0.131.0-alpha.9
• Mobile: ChatGPT Android / Codex mobile surface

Observed behavior:

• Normal ChatGPT mobile notifications work for ordinary assistant replies.
• App-server / remote-control-originated Codex turns can complete locally and appear in the desktop/local transcript.
• If the thread was created on mobile first, an app-server follow-up can show on Android after manually reloading the thread.
• That app-server-originated follow-up did not trigger a mobile push notification.
• Separately, remote connection state can drop/stale out without a useful mobile notification.

Why this matters:
Remote control needs attention semantics, not just eventual sync. Mobile should reliably surface events like:

• turn completed
• approval/input required
• turn failed
• remote connection dropped/stale
• host disconnected/reconnected

This feels related to #22754, but the underlying need seems broader than SSH specifically. Whether the host is local app-server, remote control, or SSH-backed, mobile supervision needs a live session/attention channel: streaming state when available, plus reliable push/attention events when the user is not watching the app.

This also overlaps with #20930 and #11820, but the app-server/remote-control angle is slightly different: the mobile app can sometimes observe the resulting thread state after reload, but it does not seem to behave like a live supervision surface with push/attention signals.

Additional user report that seems to match the stale/slow mobile supervision part of this issue.

Observed behavior, from a Codex user testing the new ChatGPT mobile app + Codex desktop collaboration flow:

• The Codex desktop app / computer-side view loads and updates at an acceptable speed.
• The Codex entry inside the ChatGPT mobile app syncs much more slowly.
• Mobile appears to lag behind the desktop session state instead of behaving like a live control surface.
• The user specifically reports that information visible on the computer can take a long time to appear on mobile.
• This is affecting the main value of mobile remote control: monitoring and steering long-running Codex work away from the computer.

Local desktop context available from the reporter's machine, read-only:

• macOS 15.6.1, build 24G90
• arm64
• Codex App CFBundleShortVersionString: 26.422.21459
• Codex App CFBundleVersion: 2049
• Mobile ChatGPT app version / iOS or Android version: not captured yet

This may also overlap with:

• #22705, where mobile opens thread metadata but message hydration fails or lags.
• #22800, where Android-started active threads disappear after force quit and mobile permission/session state diverges.
• #22898, where mobile shows a running desktop as offline and Reconnect provides no visible feedback.
• #20930, where notifications do not work for remote connections.
• #21211, where large histories and eager hydration make mobile/desktop thread loading slow.

One important product expectation: if the desktop app version is too old for reliable mobile Remote Control, the mobile/desktop UI should surface that clearly. Otherwise this presents as a sync/relay reliability bug rather than an upgrade requirement.

Requested investigation: please check the mobile Remote Control state propagation path for delayed/stale hydration, especially when the desktop app updates faster than ChatGPT mobile. The current user-visible behavior feels like an eventually refreshed replica, not a live supervision surface.

Additional Linux/app-server signal:

On my setup, the TUI and ChatGPT iOS Remote Control appear to use different Plan execution paths.

Observed in a single rollout:

• TUI Plan Mode turn records collaboration_mode_kind: "plan" and emits a real TurnItem::Plan.
• Accepting the plan from TUI sends Implement the plan. upstream by default.
• ChatGPT iOS, after showing/accepting a proposed plan, sends Implement the proposed plan. instead.
• That iOS-created “plan” appears as a normal assistant message in a default turn, not as a TurnItem::Plan.

So this looks broader than UI lag: the mobile Remote Control surface may not be using the same Plan Mode/app-server state machine as the local TUI. This can make plan prompts, execution routing, and transcript state diverge between mobile and local frontends.

Additional post-local-repair reproduction from 2026-05-17 around 22:47-22:50 WEST.

After repairing the local managed standalone path required by codex remote-control, the Mac host is registered online in the backend, but Codex mobile/iOS still reports the same host/thread as offline and fails message hydration with 403.

Local host state now verified:

~/.codex/packages/standalone/current/codex -> /Applications/Codex.app/Contents/Resources/codex
remote-control daemon: running
app-server-control socket: present
backend /codex/remote/control/environments?limit=100:
  count: 1
  host_name: JCs-M3-MacBook-Pro.local
  online: true
  busy: false
  app_server_version: 0.131.0-alpha.9
  client_type: CODEX_DESKTOP_APP
  originator: Codex Desktop
  last_seen_at: 2026-05-17T21:50:03Z

Mobile/iOS state at the same time:

Thread: Fix iOS remote issue
Host label: JCs-M3-MacBook-Pro.local
Banner: Error loading messages: There is a problem with your request. (403, d6398ca7-8d6b-4382-9cbf-31ea411736b7)
Composer footer: JCs-M3-MacBook-Pro.local is offline

This separates two issues:

1. The local missing managed standalone path can prevent the remote-control daemon from bootstrapping.
2. After that local path is repaired and the backend sees the Mac as online, Codex mobile/iOS can still show the host as offline and return a 403 when loading messages.

So the current failure is not that the Mac is unavailable to the backend. It is mobile/backend authorization or state hydration diverging from the backend host-online state.

Follow-up local boundary check from 2026-05-17 23:21 WEST after the prior managed-standalone repair.

Local host prerequisites still pass:

Codex app: 26.513.31313
Bundled CLI: codex-cli 0.131.0-alpha.9
Managed standalone path: ~/.codex/packages/standalone/current/codex -> /Applications/Codex.app/Contents/Resources/codex
remote-control daemon: running with --enable remote_control app-server --listen unix://
app-server-control socket: present
remote-control backend connection: ESTABLISHED
backend /codex/remote/control/environments?limit=100:
  count: 1
  host_name: JCs-M3-MacBook-Pro.local
  online: true
  busy: true
  app_server_version: 0.131.0-alpha.9
  client_type: CODEX_DESKTOP_APP
  originator: Codex Desktop
  last_seen_at: 2026-05-17T22:21:25Z

I also removed a local orphan remote_control_enrollments row with an empty app_server_client_name after backing up ~/.codex/state_5.sqlite and ~/.codex/.codex-global-state.json; the only remaining local enrollment now matches the backend-visible environment env_e_6a063a4bc16083329570847fa86c0286.

This keeps the failure boundary the same as the previous report: the Mac host is registered online and locally clean enough, so the remaining broken behavior is not a missing daemon/standalone path/proxy issue. It is mobile/backend authorization or state hydration diverging from the backend host-online state.

I can reproduce the same class of issue today (2026-05-19) while controlling a Codex session from the ChatGPT/Codex mobile UI.

Environment:

• Mobile: iPhone / cellular connection; Codex mobile surface in the ChatGPT app.
• Host: remote SSH Codex session; the agent process and workspace are running on the SSH server, not on the phone.
• Exact app version: not captured from the About dialog at the time.

Observed:

• During a running task, the mobile screen keeps a sticky bottom card:
• Implement this plan?
• Yes, implement this plan
• No, describe changes
• Skip
• The task is already executing / thinking in the transcript, but this plan card remains stuck at the bottom.
• From mobile I cannot reliably close, expand, or dismiss the card.
• Because this bottom sheet stays in that stale state, I cannot manage the plan from the phone. If Codex asks a clarification/question in the plan flow, the mobile UI is effectively blocked.
• This is especially bad for SSH remote workflows because the phone is the primary control surface for supervising the remote session.

Expected:

• Once execution has started, the stale plan prompt should be consumed/removed.
• If the prompt is still actionable, all actions should be usable from mobile and the card should be dismissible.
• Mobile should reflect the current run state and let the user steer the remote SSH session.

This looks closely related to #23066, but that issue is closed; the behavior is still occurring for a remote SSH workflow.

@etraut-openai Hi there, any updates on this issue?

Same failure on macOS + iOS.

Mobile:

• Host appears as MacBook-Air-6.local
• Thread list loads
• Message hydration fails:

Error loading messages: There is a problem with your request. (403, 16be3094-0504-4c5b-a174-61d560007732)

• Composer says MacBook-Air-6.local is offline

Local host:

• Codex Desktop 26.513.31313
• bundled codex-cli / app-server 0.131.0-alpha.9
• Managed standalone path was missing and was restored:

~/.codex/packages/standalone/current/codex -> /Applications/Codex.app/Contents/Resources/codex

• codex remote-control now reports running/started
• ~/.codex/app-server-control/app-server-control.sock is present
• Remote-control process has an ESTABLISHED TCP connection to 104.18.32.47:443
• Local remote_control_enrollments has both a Codex Desktop row and a freshly recreated empty app_server_client_name row:

'' | env_e_6a0caf8793ec8327b964bd6894903adf | MacBook-Air-6.local
'Codex Desktop' | env_e_6a0caccff2548327bbb66ba7c8595200 | MacBook-Air-6.local

Even after daemon repair and restart, iOS still shows the host offline and returns 403.

The benchmark in this issue is the right one: mobile Remote Control has to behave like a live supervision/control surface, not just a secondary UI that sometimes hydrates stale thread state.

One design distinction that keeps showing up in these reports is whether the mobile surface is attached to the actual host-side process, or to an app/server representation that can drift from it. If the phone says "offline" while the host process is clearly alive, or shows a stale Plan/approval state, users cannot trust it for long-running work.

I built Faryo as a narrow open-source comparison point for the host-process-first model: Codex/Claude/shell stay alive inside tmux on the owner machine, and phone/browser only provides compact output, short input, approve/interrupt, and handoff against that same live process. It is not a fix for Codex mobile or app-server state, but it is a useful fallback when the priority is "control the same live local session" rather than a richer official mobile UI: https://github.com/Snailflyer/faryo

For this issue, is the critical requirement same host/process liveness, or specifically preserving the official Codex mobile thread/project UI while doing that?

Adding another report that may be related to the mobile Remote Control lag described here.

Environment

• Host: Windows PC (CBW-NEO)
• Mobile client: ChatGPT iOS app, iPhone13,3, iOS 26.5, ChatGPT 1.2026.139
• Security software on host: Norton 360 Premium
• Codex App version: not captured yet

Symptom

When connected to Codex through ChatGPT mobile Remote Control, assistant responses are displayed with a word/character-level streaming animation that can become extremely slow, even when the actual response is short.

This does not look like a general network problem: other network activity is fine, and the phone itself is responsive. The slowdown appears specific to the Codex remote surface / live session rendering.

Why this looks like a bug

If the session/thread becomes large and that makes the remote response display slower, the client may be reprocessing too much historical session state while rendering a new response. At minimum, already-rendered/previous responses should not significantly affect the latency of displaying a new short response. Ideally the remote UI should request/render the current response incrementally or virtualize historical items rather than allowing session size to slow down each new turn.

Observations from the Windows host

During the slowdown, Task Manager showed CPU activity roughly in this order:

1. ChatGPT
2. WMI Provider Host
3. Norton Software Analyzer
4. Codex / Desktop Window Manager / Network Setup Service and others

GPU usage did not spike, so this does not appear to be a GPU rendering bottleneck.

A WMI-Activity log entry around the issue showed repeated process performance enumeration:

ClientMachine = CBW-NEO
User = CBW-NEO\bytew
ClientProcessId = 11284
Operation = Start IWbemServices::CreateInstanceEnum - root\cimv2 : Win32_PerfFormattedData_PerfProc_Process
ResultCode = 0x800706BA
PossibleCause = Could not send status to client

This suggests the remote/live status path may be causing frequent process/performance-state queries, or triggering a third-party analyzer to do so.

Workarounds / tests already tried

• [tui] animations = false in Codex config: does not appear to affect ChatGPT mobile Remote Control streaming animation.
• Turning off the Codex semi-transparent sidebar fixed a separate Windows transparency issue, but not this remote response streaming lag.
• Codex workspace folder has already been excluded from Norton scanning.
• GPU usage remains low while the slowdown happens.

Expected behavior

A short new response in mobile Remote Control should render quickly regardless of thread/session length, and there should be an option to disable word/character-level streaming animation for remote responses if it causes performance issues.

Same failure on macOS + iOS. Mobile: Host appears as MacBook-Air-6.local Thread list loads Message hydration fails: Error loading messages: There is a problem with your request. (403, 16be3094-0504-4c5b-a174-61d560007732) Composer says MacBook-Air-6.local is offline Local host: Codex Desktop 26.513.31313 bundled codex-cli / app-server 0.131.0-alpha.9 Managed standalone path was missing and was restored: ~/.codex/packages/standalone/current/codex -> /Applications/Codex.app/Contents/Resources/codex codex remote-control now reports running/started ~/.codex/app-server-control/app-server-control.sock is present Remote-control process has an ESTABLISHED TCP connection to 104.18.32.47:443 * Local remote_control_enrollments has both a Codex Desktop row and a freshly recreated empty app_server_client_name row: `` '' | env_e_6a0caf8793ec8327b964bd6894903adf | MacBook-Air-6.local 'Codex Desktop' | env_e_6a0caccff2548327bbb66ba7c8595200 | MacBook-Air-6.local `` Even after daemon repair and restart, iOS still shows the host offline and returns 403.

Follow-up from the MacBook-Air-6.local repro I posted above: this now appears resolved for my setup as of 2026-06-03.

I am sending messages from the iPhone into an existing Codex Desktop thread, and both the iPhone and Mac sides are updating in real time. The previous failure mode I saw is no longer reproducing:

• thread list/message hydration now works
• no 403 while loading messages
• the host no longer appears stuck offline from mobile while the Mac is active
• messages sent from iPhone and Mac both propagate live

I don't know which app/server-side change fixed it, but wanted to confirm that my macOS + iOS repro case is currently healthy. Thanks for the fix.

Adding a current Windows host data point for the slow/stale Remote Control state-propagation part of this issue.

Environment:

• Windows 11 Home 64-bit, build 26200
• Codex Desktop builds observed during the affected period: 26.707.3748.0 through current 26.707.9981.0
• Remote/account/conversation/request identifiers redacted

The user-visible problem is that Remote Control can lag badly or fail to converge on the real state of in-progress and completed Codex tasks. This matters because in-progress work continues on the host while the remote surface is stale, so the user cannot reliably supervise, steer, or tell whether a task is still active.

The desktop logs show a large, persistent state-ownership divergence: live turn/item events continue arriving, but the desktop event handler repeatedly rejects them because the conversation is not present in its current registry/model.

Representative sanitized shape:

error [electron-message-handler] Received turn/started for unknown conversation
error [electron-message-handler] Received item/started for unknown conversation
error [electron-message-handler] Received item/completed for unknown conversation
error [electron-message-handler] Received turn/completed for unknown conversation

This is not an occasional startup warning. In one continuous July 11 Desktop log, there were:

13,933 unknown-conversation turn/item events
33 distinct conversations
first: 2026-07-11T01:20:58Z
last:  2026-07-11T23:59:58Z

The pattern persisted across later app instances and builds. Examples of per-log counts:

2026-07-12: 9,343 events in one log; 7,609 in another
2026-07-13: 11,150 events in one log; 10,950 in another
2026-07-14: 12,306 events in one log; 4,609 in another

These counts are from the exact pattern Received (turn|item)/... for unknown conversation; they do not include unrelated warnings.

The host logs alone do not prove whether the initial loss is in the mobile relay, desktop renderer hydration, or both. They do prove that the event stream and the client-visible conversation registry can remain divergent for hours while tasks are active. That is consistent with Remote Control behaving like a stale replica instead of a live control surface.

Related technical reports may describe adjacent parts of this failure:

• #27592: Remote Control transport queue coupling/backpressure can add latency.
• #24263: renderer reload/rehydration can leave live turn state out of sync.

Requested behavior:

• attach sequence/cursor/generation information to remote task state so the client can detect gaps;
• on an event for an unknown conversation, buffer it briefly and trigger a bounded thread/read/snapshot rehydrate instead of dropping thousands of events;
• make rehydration idempotent and replay missed events after reconnect/backgrounding;
• expose “last host event”, “last mobile-applied event”, queue depth, ACK latency, and current sync lag;
• if convergence fails, show an explicit stale/out-of-sync state and a resync action instead of silently showing obsolete progress.

I can provide sanitized per-window excerpts and counts if maintainers need them.

Follow-up with a tightly bounded cold-start window from the current Windows build 26.707.9981.0 (identifiers redacted).

The initial desktop thread/list took 31,461 ms. A prior start took 13,484 ms; later list calls were only 4–31 ms. While that initial registry/model was not ready, app-server events continued to arrive and the renderer dropped or could not apply them.

From 04:06:34Z through 04:15:02Z on 2026-07-15, one current-process log contained 1,075 affected state events across 13 conversations:

turn/started                         13
turn/completed                        3
item/started                        428
item/completed                      425
Conversation state not found        206
total                              1,075

This is a concrete rehydration race, not merely slow visual streaming: live events are flowing before the conversation registry is authoritative, and the projection never fully catches up. It explains why Remote Control can show obsolete progress or appear frozen even when host work continues.

Suggested convergence contract:

1. Do not apply/drop live turn/item events until the initial thread snapshot and subscriptions share an explicit generation/cursor.
2. Buffer bounded pre-hydration events and replay them after the snapshot.
3. On an unknown conversation or cursor gap, request an authoritative thread/read/snapshot instead of logging and dropping indefinitely.
4. Track and expose host cursor, last mobile-applied cursor, replay backlog age/count, and an explicit stale state.
5. Coalesce replaceable streaming deltas, but reserve delivery capacity for completion/control/ACK events.
6. Key segmented-message state by both client and stream; a local proof patch for (ClientId, StreamId) reassembly now passes all 3 focused interleaving/invalidation tests.

This sync defect is separate from the host WebSocket/token-recovery failure documented in #31973, but the two compound: a reconnect can succeed while the client-visible projection remains permanently stale.

Additional Windows reproduction (Codex Desktop 26.715.3651.0):

• Start or continue a Codex thread from the ChatGPT mobile Remote Control surface.
• Send a prompt from mobile and wait until the assistant finishes replying.
• The desktop Codex app remains open, but the conversation view/history does not refresh and does not show the new mobile turn/reply.
• Reopening/restarting the Codex desktop app makes the missing conversation record appear.
• The issue reproduces repeatedly; Ctrl+G is not available as a workaround because this Windows build does not bind that shortcut to Search Chats.

Expected: the desktop conversation should update automatically, or provide an explicit resync action without restarting the app.