›_ Codex Issues
Codex Issues / #31973

Windows Remote Control gets permanently stuck in "Reconnecting..." with no way to recover remotely

Open 💬 7 comments Opened Jul 10, 2026 by LeeDoGwan
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Codex App (Windows) ChatGPT Mobile Remote Control (QR Pairing)

What subscription do you have?

Plus

What platform is your computer?

Host Windows 11 Codex App (latest) Remote ChatGPT Mobile QR Pairing

What issue are you seeing?

Summary

After running normally for a period of time, the mobile remote client becomes permanently stuck in "Reconnecting...".

The most serious issue is that there is no way to determine whether the Windows host is still alive or to recover the remote session without physically accessing the host machine.

This issue has occurred multiple times under the same workflow.

---

Impact

This is a significant issue for users who operate Codex remotely.

Typical workflow:

  • Windows PC stays at home running Codex.
  • User controls it remotely from ChatGPT Mobile.
  • User may also access ChatGPT from another computer via a web browser.

When the Remote Control enters the "Reconnecting..." state, the user completely loses access to the host and cannot determine whether the issue is:

  • the Windows application,
  • the Remote Control service,
  • the backend session,
  • or the mobile client.

If the host computer is located elsewhere, Remote Control becomes unusable until someone can physically access the machine.

What steps can reproduce the bug?

Steps to Reproduce

  1. Install the Codex App on a Windows PC.
  2. Pair ChatGPT Mobile using the QR code.
  3. Leave the Windows PC running at home.
  4. Connect to the host remotely from ChatGPT Mobile.
  5. Continue using Remote Control for several hours (sometimes after idle periods).
  6. Eventually, the mobile client becomes stuck on "Reconnecting..." indefinitely.
  7. Restarting the ChatGPT mobile app does not recover the session.
  8. Switching between Wi-Fi and LTE does not recover the session.
  9. The only way to recover is to physically access the Windows PC and restart the Codex application.

What is the expected behavior?

Expected Behavior

If the desktop application is still running, the remote session should automatically recover.

If automatic recovery is not possible, users should at least be able to determine the host status through diagnostics such as:

  • Host Online / Offline
  • Last Seen
  • Last Heartbeat
  • Remote WebSocket status
  • Backend session status

It would also be helpful to provide recovery actions such as:

  • Force Reconnect
  • Restart Remote Service
  • Reset Remote Session
  • Re-register Host

---

Actual Behavior

The mobile client remains permanently stuck on:

Reconnecting...

There is no way to determine whether:

  • the Windows Codex application is still running,
  • the remote connection is still alive,
  • the backend session has become stale,
  • the pairing has become invalid,
  • or the desktop application has crashed.

The user has no diagnostic information and no recovery mechanism without physical access to the host.

Additional information

Suggested Improvements

Diagnostics

Please expose the following information:

  • Host Online / Offline
  • Last Seen
  • Last Heartbeat
  • Desktop App Version
  • Remote WebSocket Status
  • Backend Session Status

Recovery

Please provide one or more of the following:

  • Force Reconnect
  • Restart Remote Service
  • Reset Remote Session
  • Re-register Host

These actions should be available without requiring physical access to the Windows host.

Additional Notes

  • This issue has happened multiple times under the same workflow.
  • Restarting the mobile application does not resolve the problem.
  • Switching networks (Wi-Fi ↔ LTE) does not resolve the problem.
  • The only reliable recovery method so far has been physically accessing the Windows machine and restarting the Codex application.

I would also appreciate any diagnostic logs or troubleshooting methods that users can access remotely to determine whether the host is still alive when the mobile client is stuck on "Reconnecting...".

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 11 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #30791
  • #31786

Powered by Codex Action

tal-shilian · 9 days ago

I think i have the same problem the mobile and desktop connect to remote te server windows and alot of times its hppane stack in reconnecting.

JeffreyBai · 8 days ago

No, the tickets you provided described communication issues, but in my issue, the tasks totally stopped working at all. They no longer produce any outputs, which they should and commit after each step. The tasks simply freezed.

JeffreyBai · 8 days ago

This was not limited to a single conversation. All Codex tasks were frozen and produced no further progress, while Windows and other applications (including Claude Code Remote) continued to function normally.

LeeDoGwan · 8 days ago
I think i have the same problem the mobile and desktop connect to remote te server windows and alot of times its hppane stack in reconnecting.

The connection keeps dropping or becoming unstable, which is really frustrating.

2batsloverandomartifactromps-dotcom · 6 days ago

Adding a current Windows 11 host-side reproduction with a repeatable failure sequence. This looks like a Remote Control connection-registry/state race, not simply the desktop process being dead.

Environment:

  • Windows 11 Home 64-bit, build 26200
  • Codex Desktop builds reproduced: 26.623.13972.0 and 26.707.3748.0
  • Current installed build: 26.707.9981.0
  • Remote environment/account/request identifiers redacted

Reproduction 1 — 2026-07-03, build 26.623.13972.0

The local app-server came up normally:

12:09:20.158Z initialize_handshake_result outcome=success transportKind=stdio
12:09:20.984Z response_routed method=remoteControl/status/read durationMs=1

Remote Control refresh/enable also appeared successful:

12:09:21.519Z refresh_remote_control_started previousConnectionCount=0
12:09:21.524Z response_routed method=remoteControl/enable durationMs=0
12:09:21.908Z refresh_remote_control_completed nextConnectionCount=1 previousConnectionCount=0

But immediately after the refresh reported one connection, the host-scoped status read could not resolve that connection:

12:09:22.057Z Request failed method=remoteControl/status/read durationMs=75
  "Connection for host ID remote-control:<redacted-env-id> not found"
12:09:22.062Z remote_connections.manager_state_set
  nextState=disconnected source=bootstrap_connection_state_fetch

Reproduction 2 — 2026-07-12, build 26.707.3748.0

The same ordering occurred again:

18:25:46.921Z initialize_handshake_result outcome=success transportKind=stdio
18:25:48.031Z response_routed method=remoteControl/status/read durationMs=1
18:25:48.554Z refresh_remote_control_started previousConnectionCount=0
18:25:48.585Z response_routed method=remoteControl/enable durationMs=1
18:25:48.946Z refresh_remote_control_completed nextConnectionCount=1 previousConnectionCount=0
18:25:49.020Z Request failed method=remoteControl/status/read durationMs=35
  "Connection for host ID remote-control:<redacted-env-id> not found"
18:25:49.032Z remote_connections.manager_state_set
  nextState=disconnected source=bootstrap_connection_state_fetch

About 12 minutes later, refresh removed the connection entirely:

18:38:18.156Z refresh_remote_control_started previousConnectionCount=1
18:38:18.158Z refresh_remote_control_completed nextConnectionCount=0 previousConnectionCount=1
18:38:18.234Z remote_connections.manager_state_set
  nextState=disconnected source=registry_delete_manager

The strongest signal is that refresh_remote_control_completed reports nextConnectionCount=1, but within 74–149 ms the app cannot look up that same host ID. The local app-server and desktop process are responsive throughout.

This could explain the user-visible “Reconnecting...”/offline state: the Remote Control inventory briefly advertises a host entry that the connection registry cannot route to, then the manager remains disconnected and may later delete the entry.

Suggested recovery behavior:

  • make connection discovery/registry publication and the initial host-scoped status read atomic, or retry the status read after a just-completed refresh;
  • if a discovered host cannot be resolved, refresh/re-register that host automatically instead of leaving a permanently disconnected manager;
  • expose last successful host registration, heartbeat/ack, registry generation, and reconnect error in diagnostics;
  • provide a safe “restart/re-register Remote Control” action that does not require restarting all of Codex Desktop.

I can provide additional sanitized log windows if maintainers need them.

2batsloverandomartifactromps-dotcom · 5 days ago

Follow-up with a later same-host incident and a source-level audit.

Environment:

  • Windows 11, current Codex Desktop 26.707.9981.0
  • bundled app-server observed as 0.144.2
  • all account/environment/server/client/request identifiers redacted
  • the phone session can work normally for a while before the failure

Host transport timeline (2026-07-15 UTC)

03:31:30  one logical phone/client connection closed
03:47:49  another logical phone/client connection closed
03:57:03  host websocket reader disconnected ("websocket disconnected")
03:57:03  writer stopped; connection cycle ended as ConnectionWorkerStopped
          while current_status was still Connected
03:57:03  new cycle began; Connected -> Connecting
03:57:33  server-token refresh timed out; Connecting -> Errored
03:57-04:05  refresh/connect failures repeated

There was no corresponding Windows WLAN, NetworkProfile, or System event showing a host Wi-Fi/adapter disconnect. Model-list child-process timeouts occurred in the same interval, so internal app-server load/head-of-line blocking remains relevant.

This is distinct from the desktop bootstrap route miss in my previous comment. The current build can show that desktop-registry warning while the phone relay is actually working, so it must not be used as an external-watchdog restart signal.

Concrete defects found on current main

  1. WebSocket handshake success reset reconnect backoff even if the connection died immediately afterward. The capped backoff also reset into a sawtooth.
  2. A worker could stop while published status remained Connected during cleanup.
  3. clear_server_token() cleared the token/expiry but not next_refresh_at; a 401/403 could therefore leave required refresh deferred.
  4. Required-refresh WouldBlock was retried every second even when the typed enrollment deferral was minutes away, producing repeated prepare/connect/log cycles.
  5. Client segment reassembly was keyed only by ClientId, although concurrent StreamId values are supported; interleaved streams could reset/drop each other.
  6. The top-level Remote websocket task still logs unexpected exit/panic but is not supervised/recreated in-process.

I prepared a local five-file proof patch (not deployed to the active Desktop app) that:

  • clears refresh deferral with a rejected token;
  • carries the refresh deadline in a typed error and sleeps until that deadline, while generic missing-account WouldBlock keeps the 1 s fallback;
  • resets backoff only after a >=30 s stable connection, with capped jitter in [27 s, 30 s);
  • publishes Errored immediately when a connection worker dies, before cleanup;
  • resets backoff on explicit disable/auth change;
  • keys segment assemblies by (ClientId, StreamId).

Validation with the pinned Rust 1.95 toolchain, two compiler jobs, and an isolated target:

3/3 focused segment tests passed
8/8 focused auth/reconnect/refresh tests passed
cargo check -p codex-app-server-transport --lib passed
cargo fmt --all -- --check passed
git diff --check passed

Recommended durable recovery work:

  • supervise/recreate the Remote worker in app-server with capped jitter and a circuit breaker;
  • expose redacted health: desired state, worker alive, backend status age, active streams, last activity, backlog age/count, and last disconnect reason;
  • add a transport-only remoteControl/reconnect operation that preserves enrollment, cursors, threads, and running turns;
  • make replay/backpressure generation-aware and per-stream;
  • on Windows, expose a current-user-only control channel or daemon so Remote transport can recover without restarting Electron/app-server and interrupting active turns.

The active app was not restarted to test this because doing so would interrupt in-progress work.