[Withdrawn] Codex mobile streamed responses cause Desktop Remote Control presence to stop updating and go offline

What version of the Codex App are you using?

Codex Desktop App: 26.519.41501 / bundle 3044

Bundled CLI:

codex-cli 0.133.0-alpha.1

What platform is your computer?

macOS 26.4.1, Apple Silicon / arm64.

Remote client surface: ChatGPT mobile app using Codex Remote Control.

What issue are you seeing?

Codex Remote Control is stable while idle, but reliably goes offline during streamed responses from the mobile client.

The desktop app process and bundled app-server remain alive, but the backend-visible Remote Control presence stops updating. Roughly 30 seconds later the host is marked offline. Once this happens, the mobile app cannot reconnect reliably. Restarting Codex.app re-registers the same environment and restores connectivity.

This makes the mobile Remote Control experience nearly unusable for streamed turns.

Observed behavior

A local watchdog queried:

GET https://chatgpt.com/backend-api/codex/remote/control/environments?limit=100

every ~10 seconds while starting a stream from ChatGPT mobile.

Timeline from one reproduction:

13:38:03 online=True  last_seen=2026-05-23T05:38:04.484479Z  desktop_pid=41335 appserver_pid=41756
13:38:15 online=True  last_seen=2026-05-23T05:38:14.482697Z  desktop_pid=41335 appserver_pid=41756
13:38:27 online=True  last_seen=2026-05-23T05:38:30.321765Z  desktop_pid=41335 appserver_pid=41756
13:38:39 online=True  last_seen=2026-05-23T05:38:35.124696Z  desktop_pid=41335 appserver_pid=41756
13:38:51 online=True  last_seen=2026-05-23T05:38:50.829888Z  desktop_pid=41335 appserver_pid=41756
13:39:03 online=True  last_seen=2026-05-23T05:38:50.829888Z  desktop_pid=41335 appserver_pid=41756
13:39:15 online=True  last_seen=2026-05-23T05:38:50.829888Z  desktop_pid=41335 appserver_pid=41756
13:39:28 online=False last_seen=2026-05-23T05:38:50.829888Z  desktop_pid=none appserver_pid=none
13:39:40 online=True  last_seen=2026-05-23T05:39:42.479600Z  desktop_pid=49309 appserver_pid=49737
13:39:52 online=True  last_seen=2026-05-23T05:39:53.538535Z  desktop_pid=49309 appserver_pid=49737

The desktop_pid=none entry at 13:39:28 is because a local watchdog restarted Codex.app after the backend had already returned online=false. Before that restart, the desktop process and app-server were still alive while last_seen had stopped advancing.

The same host stayed stable for about 30 minutes before the streamed turn:

13:09-13:38: online=true on every 30s check; last_seen continuously advanced.

This points specifically at streamed Remote Control turns, not idle presence.

Expected behavior

During streamed mobile Remote Control turns, Codex Desktop should either:

• keep the host presence heartbeat independent of the stream data path, or
• detect that the relay/presence state is stale and reconnect/re-register the host automatically, or
• surface a precise diagnostic to the mobile client instead of leaving Reconnect ineffective.

The host should not become backend-offline while Codex.app and its bundled app-server remain running.

Actual behavior

During streamed responses:

1. The mobile stream stops receiving output.
2. The backend last_seen_at for the Desktop environment stops advancing.
3. The backend then marks the Desktop environment online=false.
4. Mobile reconnect does not reliably recover the session.
5. Restarting Codex.app restores the same environment to online=true.

Local process state

Desktop process and app-server before recovery:

/Applications/Codex.app/Contents/MacOS/Codex
/Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled

Environment of the Desktop app-server was clean:

USER=<local-user>
LOGNAME=<local-user>
HOME=/Users/<local-user>
PWD=/

No CODEX_HOME or OpenClaw-related environment variables were present.

Network context

The host is behind a macOS proxy/TUN-style network path:

route to chatgpt.com -> gateway 198.18.0.1, interface utun1024

Processes include Clash Verge / mihomo and Tailscale. This may expose long-lived WebSocket or half-open connection edge cases, but the recovery behavior still appears to be a Codex Remote Control state-machine issue: the desktop process stays alive, yet backend-visible presence stops advancing and mobile reconnect does not recover.

Related issues

This appears related to, but more specific than:

• #22898
• #24179

The narrower signal here is that idle Remote Control presence remains stable, but a mobile streamed response causes last_seen_at to stop advancing and the host is marked offline shortly afterward.