Codex mobile shows running desktop as offline and Reconnect silently does nothing
Summary
The Codex desktop app is open and running on my Mac, but the Codex entry inside the ChatGPT iOS app shows the machine as offline. Tapping Reconnect in the iOS app does not appear to do anything: there is no loading state, no retry indication, no error message, and no diagnostic hint. The mobile app remains stuck on the offline state, so I cannot connect to Codex from my phone.
Environment
- Codex desktop app:
26.513.20950 (2816) - macOS:
Tahoe 26.4.1 - Mac hardware: MacBook Pro 16-inch, Apple M5 Max, 128 GB memory
- Desktop name shown in mobile app:
Mac.attlocal.net - ChatGPT iOS app:
1.2026.125 (25565698938) - Plan: ChatGPT Pro
- Approximate time observed: 2026-05-15 around 13:42–13:43 PDT
- Request ID / correlation ID: not available because the UI shows no error banner or failure details
Steps to reproduce
- Open and keep the Codex desktop app running on macOS.
- Open the ChatGPT app on iOS.
- Go to the Codex section/device connection page.
- Observe that the Mac entry appears as offline, e.g.
Mac.attlocal.net — Offline · Last seen 18 hours ago, even though the desktop Codex app is currently open. - Tap Reconnect.
Actual behavior
- The mobile app still shows the Mac as offline.
- The Reconnect button appears to be non-functional from the user's perspective.
- There is no visible loading spinner, state change, retry progress, permission prompt, sign-in prompt, network diagnostic, or error message.
- The UI gives no actionable explanation for why the desktop app cannot be reached.
Expected behavior
- If the desktop Codex app is currently running and signed in, the mobile app should refresh the device heartbeat/status and reconnect successfully.
- If reconnection fails, tapping Reconnect should surface a clear error state or diagnostic message, such as auth/session mismatch, relay/device discovery failure, local network issue, stale device registration, or server-side connectivity problem.
- The button should provide visible feedback while the reconnect attempt is happening, and should not fail silently.
Impact
This makes the mobile Codex integration unusable because the phone cannot connect to a desktop Codex instance that is actually open. The lack of any visible error or request/correlation ID also makes it hard for users to provide useful diagnostics.
Suggested investigation / fix
- Verify that the iOS Reconnect action is actually dispatching a reconnect request and not being swallowed by a stale UI/device record.
- Add a visible loading, timeout, and failure state for the reconnect flow.
- Refresh the desktop heartbeat/device presence when the mobile page is opened or when Reconnect is tapped.
- Surface a diagnostic error code/request ID when reconnect fails.
- Check whether recent Codex desktop/iOS app versions have a stale pairing, relay discovery, or device-registration issue between desktop Codex and ChatGPT iOS.
Screenshot
A single screenshot is attached showing the relevant iOS Codex state: Mac.attlocal.net is shown as Offline · Last seen 18 hours ago, with a Reconnect button that does not visibly respond when tapped.
The remaining environment details are described in text above instead of attaching additional screenshots.
<img width="1206" height="2622" alt="Image" src="https://github.com/user-attachments/assets/18a3f6c1-d30b-4463-9419-85504ccd82c0" />
16 Comments
the same problem +1
is this shit fixed?
This feature is really poorly implemented, the connection is extremely unstable.
same problem here
Unavailable features
I got stuck by this issue for 3 days as well.
Same problem. I don't understand how it is working for anyone. With this bug the remote control trip feature is unusable since I was able to connect once and since then the machine shows offline.
You need to quit codex desktop entirely and then re-open it, Then the mobile app will be able to connect.
The workaround where quitting and reopening Codex Desktop makes mobile reconnect is an important signal: this is probably not just a mobile button/UI issue. It suggests the desktop host can re-advertise itself correctly on fresh startup, but some heartbeat/registration/relay-presence layer becomes stale while the app is still open.
For diagnosis, I would split the UI into separate states instead of one "Offline" label:
Right now "Reconnect" failing silently hides which layer is stale, so users cannot tell whether to re-auth, forget the device, restart Desktop, or wait for backend relay recovery.
Also have this issue! Makes the mobile app unusable
I got the same issue on Windows, still not fixed and don't know what's the problem.
Yeah. And every time I start a task in the Codex interface, it starts with Reconnecting 4/5.... Why? I feel so sad about it. And my Mac always seems to be asleep on my iPhone, same here.
I tested a narrow fix for the reconnect case described here, specifically the case where the remote-control daemon/app-server still appears alive locally, but the mobile app remains stuck waiting for the desktop after the mobile app is backgrounded or loses its session.
Branch:
https://github.com/markrowan/codex/tree/fix/remote-control-reenable-reconnect
The change makes remoteControl/enable request a fresh websocket connection when remote control is already Connected, instead of treating that call as a no-op. In my local testing, this allowed the mobile client to recover the environment without manually stopping and restarting remote control.
A couple of caveats:
This was tested on Linux, which I understand is not officially supported for this flow.
I could not open a PR against openai/codex because GitHub requires collaborator permission.
So this appears to resolve the specific reconnect/no-op case we reproduced, but I have not validated broader remote-control lifecycle cases beyond that.
After two weeks of testing, the connection is mostly stable. It still drops from time to time, requiring a restart of the desktop service, but is much more robust than without the fix. For example, the past 5 days my mobile app has been connected without interruption.
Reconnecting frequently. Fix fix
I’m seeing a related persistent-session problem in normal ChatGPT mobile use:
This also happens repeatedly during ordinary mobile check-ins, so the workflow feels like a new connection is being established for each conversation rather than one persistent host connection.
Expected behavior:
A separate but related multi-device notification request is tracked in #33300.
Idk why the hell but in my case it completely works now without reconnect:
Now i can always use my mobile app without even having the laptop running. I dont know if this is a security issue though since usually i need vpn to connect to my remote server.