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

[jjoanna2-debug]

What version of the Codex App are you using?

Originally observed on host Codex App 26.513.20950 (bundle 2816).

Still present after updating the host app to 26.513.31313 (bundle 2867) on 2026-05-17.

Current bundled/local CLI observed on the host: codex-cli 0.131.0-alpha.9.

Authoritative release check on 2026-05-17:

• Latest stable openai/codex GitHub release: rust-v0.130.0, published 2026-05-08.
• Newest openai/codex alpha release visible in GitHub releases: rust-v0.131.0-alpha.22, published 2026-05-15.
• Installed host app currently reports 26.513.31313 / 2867.

This report does not claim the mobile path was tested against 0.131.0-alpha.22; it claims the failure remains after updating the installed Codex desktop app available on this host.

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Host: MacBook Pro, Apple M3 Pro, Darwin 25.5.0 arm64 arm

Mobile: ChatGPT iOS app on iPhone 17 Pro Max, iOS 26.5

What issue are you seeing?

ChatGPT iOS Remote Control is not acting like a live control surface for the connected macOS Codex App host.

The host app is online and usable, but iOS shows stale, contradictory, or failed state:

• iOS can fail to hydrate a thread with Error loading messages: There is a problem with your request. (403, ...).
• The Codex iOS home screen can show the same host with a red/offline dot.
• The iOS Connections sheet can show the same Codex Desktop host enabled with the toggle on.
• The iOS thread list can show a spinner beside the host and pinned-thread placeholders instead of usable content.
• The desktop Codex app can be open and responsive at the same time, proving the host is not simply down.
• Push notifications for approval/completion arrive extremely late or not at all.
• Mobile state lags behind the host session instead of tracking the real session.
• Context compaction can show Compacting context and still surface Implement this plan?, even though Plan mode was not being used.
• Plan prompts can stay visible after execution has already started.
• Plan/approval UI is too faint and oversized to use confidently.
• Skill picker text is washed out while typing because the overlay is too transparent.

This is not UI polish. Remote Control depends on three things being correct: attention delivery, current session state, and approval routing. If the phone is late, stale, offline while the host is online, or showing the wrong prompt, it cannot supervise long-running Codex work.

Current corroboration

This issue now has multiple independent reports in the comments:

• Android/app-server: ordinary ChatGPT push works, but app-server/remote-control Codex turns can complete locally without mobile push; the mobile app only catches up after manual reload.
• ChatGPT mobile + Codex desktop: desktop updates at an acceptable speed while the mobile Codex surface lags far behind.
• Linux/app-server Plan signal: TUI Plan Mode emits a real TurnItem::Plan, while ChatGPT iOS was reported to send a different implementation phrase and record the mobile-created plan as a normal assistant message. That points to Plan/app-server state-machine divergence, not just a slow UI.

What steps can reproduce the bug?

1. Open the Codex desktop app on macOS and keep the host online.
2. Open ChatGPT on iOS.
3. Connect to the macOS Codex App host.
4. Start or continue a Codex thread from iOS.
5. Open existing/pinned threads and observe whether messages hydrate.
6. Open the iOS Connections sheet and compare the connection toggle/state against the main Codex screen.
7. Compact an existing chat/context from iOS and observe whether an unexpected Implement this plan? prompt appears.
8. Trigger an approval or Plan-style prompt and observe readability/staleness.
9. Start a new thread and type/search until skill suggestions appear.
10. Leave the phone/host running long enough to observe delayed completion or approval push timing.

What is the expected behavior?

• If the macOS host is online, signed in, and running Codex App, iOS should not show the same host as offline or stuck loading without an actionable error.
• Message hydration should either load the thread or show a stable, actionable failure state; it should not leave the phone with a 403 and no recovery path.
• The main Codex screen, Connections sheet, thread list, and approval UI should agree on host/session state.
• Push notifications for completion, approval, failure, disconnection, or required input should arrive promptly enough to act on them.
• Mobile state should track the host session closely enough to use the phone as the control surface.
• Context compaction should stay in the compaction flow and should not surface a Plan-mode implementation prompt unless the user explicitly asked for Plan mode.
• Once a plan is accepted and execution starts, the stale Implement this plan? prompt should be consumed.
• Approval controls and skill results should be readable without guessing.

Related issues checked

Same defect family / supports amending this issue:

• iOS mobile thread opens with metadata but message hydration fails: CodexClientError error 11 #22705: iOS opens thread metadata but message hydration fails. The new 403 screenshot is the same class of failure.
• iOS mobile control shows Codex run failed after completed turn when bridge restarts #22693: iOS reports a run failed after the host-side turn completed.
• Android Codex mobile loses Android-started active threads after force quit; permissions UI greyed out as Default only #22800: Android mobile loses active threads after force quit while the host still has them.
• Codex mobile shows running desktop as offline and Reconnect silently does nothing #22898: mobile shows a running desktop as offline and Reconnect silently does nothing.
• iOS/goal mode: stale “Implement this plan?” prompt blocks steering after execution has already started #23066: stale Implement this plan? prompt blocks steering after execution has already started. It was marked duplicate of this issue.
• Codex App notification doesn't work when using it with remote connection #20930: notifications do not work for remote connections.
• Send Codex notifications to chatgpt phone app #11820: earlier request for Codex permission/completion notifications in the ChatGPT phone app.
• Codex Mobile keeps stale Codex Desktop connection and new pairing becomes CLI instead of Codex Desktop #23134, Revoked remote control access for a device, connections remain on ChatGPT mobile app without a way to delete, cannot pair again #22700, iOS Connections edit mode has no delete option for stale CLI Codex connection #22701, Codex mobile Remote Control stale host cannot be removed and QR pairing fails #22714: stale or unremovable mobile connection rows and pairing state divergence.
• Waiting for desktop despite Codex App being authorized #22715, Android ChatGPT remote connection to Windows Codex stuck on “Waiting for desktop…” #22733, In the chatGPT app, unable to connect to Codex Desktop. Shows "Waiting for desktop..." Follow the instructions in the desktop app to get connected. #22750, Codex mobile pairing stuck on Waiting for desktop when remote-control daemon cannot use proxy #22851: setup/startup failures where mobile waits for desktop or cannot reach an available host.

Related but narrower / should not be merged into this issue as the main claim:

• ChatGPT iOS remote-control skill picker becomes unreachable when keyboard is open over a long composer #22864: skill picker can become unreachable behind the iOS keyboard when the composer is long.
• Codex Git commit prompt does not work when using ChatGPT for iOS remote control on macOS #23111: Git commit prompt/config does not take effect through iOS Remote Control.
• Codex mobile Remote Control shows only one macOS host and overwrites it with the last active desktop host #22950: mobile shows only one macOS host and overwrites it with the last active host.
• ChatGPT iOS Codex SSH connection works on linux, but the bootstrap/proxy flow is fragile and hardcoded #23102: SSH bootstrap/proxy assumptions are fragile on Linux.
• Codex Mobile setup QR on Android resolves to unhandled https://com.openai.chat link #23122: Android QR setup opens an unhandled link on ColorOS.

The split is important: this issue is the live-supervision/state-propagation failure across iOS/macOS Remote Control. The other issues are narrower setup, config, keyboard, multi-host, or SSH-bootstrap defects.

Implementation signal

The team marked Remote Control available in preview in #9224 and asked users to file bugs. This is one of those bugs.

A concrete benchmark is Emanuele-web04/remodex: https://github.com/Emanuele-web04/remodex

Remodex is a third-party local-first Codex remote-control app, not an OpenAI replacement. It is useful evidence for feasibility: the public repo currently has about 3k GitHub stars, 342 forks, an Apache-2.0 codebase, an npm bridge (remodex), an App Store iPhone app, and an inspectable architecture where Codex stays on the Mac while the phone connects through a paired bridge.

Its documented feature set includes live streaming to iPhone, trusted reconnect, in-app notifications for turns needing attention, queueing follow-up prompts while a turn is running, git actions from the phone, photo attachments, subagents, Plan mode, access controls, shared thread history, and a /compact flow.

The App Store listing reports Remodex as free to download, about 81.4 MB, with version 1.5 released on 2026-05-05. Its release notes explicitly call out Smoother streaming and scrolling, More reliable reconnect, Cleaner Plan Mode timeline, Sharper skill and file autocomplete, and fixes for Plan Mode, padding, lag.

That comparison is not a demand for feature parity. It is a feasibility check. A third-party bridge should not be ahead of the official ChatGPT iOS Remote Control preview on the core loop of seeing a live run, receiving attention events, reconnecting, and approving or steering safely.

Additional information

Official docs checked on 2026-05-17:

• https://developers.openai.com/codex/remote-connections
• https://developers.openai.com/codex/app#remote-connections

The docs describe ChatGPT mobile as a supported Remote Control surface for starting, steering, approving, reviewing, getting notified about Codex work, switching connected hosts/threads, and controlling a macOS Codex App host. I understand the feature is a preview. Preview status does not make the core control loop optional.

Redacted / metadata-stripped screenshots:

[zorkary]

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.

[thughy]

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:

• iOS mobile thread opens with metadata but message hydration fails: CodexClientError error 11 #22705, where mobile opens thread metadata but message hydration fails or lags.
• Android Codex mobile loses Android-started active threads after force quit; permissions UI greyed out as Default only #22800, where Android-started active threads disappear after force quit and mobile permission/session state diverges.
• Codex mobile shows running desktop as offline and Reconnect silently does nothing #22898, where mobile shows a running desktop as offline and Reconnect provides no visible feedback.
• Codex App notification doesn't work when using it with remote connection #20930, where notifications do not work for remote connections.
• Thread navigation/loading slows from unbounded metadata and eager large-history hydration #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.