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

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

• #30791
• #31786

Powered by Codex Action

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.

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.

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.

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.

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.

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.

if it helps 5.6 Sol thinks it's a failure of the Android side (my app is up to date and I have tried refreshing local data / cache)

"""
The Windows host is working; the pairing failure is on the Android/account side.

Evidence from this machine:

• The desktop app successfully created a QR pairing session with no error.
• No pairing completion ever returned from the phone.
• The Windows Store reports the desktop app is current.
• Your account is not subject to Enterprise Remote Control restrictions.
• OpenAI currently reports no service outage. [OpenAI Status](https://status.openai.com/)

Most likely, the Android app is outdated or signed into a different ChatGPT account/workspace. Remote now uses authenticated one-to-one QR pairing, so old pairings may no longer work. [OpenAI release notes](https://help.openai.com/en/articles/6825453-chatgpt-release-notes)

Do this:

1. Update ChatGPT in Google Play, then force-stop and reopen it.
2. Confirm mobile and desktop use the same ChatGPT account and workspace.
3. Open the Remote tab inside ChatGPT Android and scan a freshly generated desktop QR code—don’t scan it with the ordinary Camera app.
4. If that fails, temporarily disable the phone’s VPN, Private DNS, or ad blocker and retry, first on Wi-Fi and then mobile data.

If you send me the exact Android error or a screenshot, I can narrow down which mobile-side cause it is.

I also added OpenAI’s official documentation source to Codex during the diagnosis; it will become available after the desktop app next restarts.
"""

Additional host-side Remote Control timeline from Codex Desktop 26.715.10079.0:

• From 18:20:00 through 18:29:48 +02:00, the local app-server recorded 445 Remote Control websocket/server-API transport entries.
• The sequence included 10 failed server-token refresh / connection attempts (mirrored as warnings across the server-API and websocket targets) plus increasing reconnect backoff.
• At 18:29:50, Windows recorded ChatGPT.exe Application Hang Event 1002 and WER MoAppHang; AppModel destroyed the Codex AppX container.
• Windows then initiated a full shutdown at 18:30:17 and started again at 18:30:36; Wi-Fi/network profile reinitialization followed. Therefore the later network events are explained by the reboot and do not establish whether connectivity was healthy before the app hang.
• A fresh Codex AppX container was created at 18:31:08. Remote/task activity became available again only after local recovery/interation.
• No git, gh, npm, or npx process was active at recovery.

This does not yet prove whether the Remote Control reconnect loop contributed to the main-process hang or was an early symptom of host starvation. The MoAppHang preceded system shutdown by roughly 27 seconds, but the shutdown/restart also limits what can be inferred from the connection ending. What is proven is that remote heartbeat/recovery currently shares the failing desktop-host lifecycle. A host-visible last seen, last successful server-token refresh, reconnect reason/backoff, and an out-of-process recovery path would materially improve diagnosis and recovery. The matching WER/AppX timeline is linked here: https://github.com/openai/codex/issues/17229#issuecomment-5048797578.

Additional Windows/Pro corroboration with rollout timing:

Remote phone-to-PC control had previously worked on the affected Windows host. After the July 9 unified ChatGPT Work / Codex desktop rollout, the host-side Codex application could remain open and locally usable while the remote host/heartbeat path stopped presenting a recoverable connection to the phone client.

Observed distinction:

• local Codex process/workspace remained available on the PC;
• the remote client could not establish a usable host session;
• the product did not expose a trustworthy last-heartbeat, pairing generation, backend-session, or remote-service state;
• physical/local intervention was required to diagnose or restore the path.

That timing does not prove the rollout caused the regression, but it provides a useful before/after boundary for telemetry correlation. Please preserve host registration generation, last successful heartbeat, desktop build, mobile build, WebSocket close reason, and pairing/session invalidation reason so these failures can be separated without physical access.

btw, this feature works 100% flawlessly using the Claude Windows desktop app + Claude Android app, so it's 100% a codex software issue, not an environment issue.

Additional reproduction observed on 2026-08-21 (KST), Windows host → ChatGPT mobile Remote Control.

Current failure pattern is slightly more intermittent than the original report but appears to be the same Remote Control / relay family:

1. Remote Control connects successfully for a short period.
2. The connection then drops unexpectedly.
3. Reconnecting may succeed briefly.
4. It disconnects again shortly afterward.
5. Repeating reconnect attempts produces the same connect → short-lived session → disconnect cycle, making sustained remote operation unreliable.

This is occurring during a long-running Codex workflow where the host-side work itself can continue independently, so the symptom is not simply that the coding task has ended. The failure appears to be in the Remote Control/app-server/relay path rather than the underlying workload.

No claim is being made here that this is a global OpenAI outage. The key user-visible problem is repeated loss of the remote-control transport after an initially successful connection, with recovery lasting only briefly.

This also seems related to the relay auto-reconnect failure described in #26786, although this reproduction is on the Windows Remote Control workflow rather than WSL2.

It would be very useful if the client exposed diagnostics for each disconnect/reconnect cycle, especially:

• host online / last heartbeat
• app-server / relay connection state
• disconnect reason / transport error
• reconnect attempt count
• whether the host process/session is still healthy
• last successful remote message timestamp

Expected behavior: once the host is still alive, Remote Control should either remain connected or recover automatically and stay recovered, rather than reconnecting only for a few seconds/minutes and dropping again.

Additional Windows 11 reproduction on 2026-08-21, Codex Desktop package 26.818.2872.0, using ChatGPT mobile Remote Control.

Remote Control repeatedly enters Reconnecting... or connects briefly and then drops, while the Windows host remains usable locally. I completed the documented recovery steps: toggled discovery/control permission, fully restarted Codex, refreshed the pairing, restarted the mobile app, and verified the same account/workspace.

Basic network checks passed (DNS, TCP/443, and HTTPS to OpenAI endpoints; no proxy configured). The issue persists and matches the repeated forwarding remote control connection closed transport event pattern.

This looks like a Remote Control reconnect/state bug rather than basic network reachability. No private diagnostics, identifiers, tokens, or raw logs are attached.

Adding an independent Windows reproduction with host-side TCP lifecycle evidence. This appears to be the same permanent Remote reconnect/offline failure, while the desktop and local app-server remain usable.

Environment

• Windows host
• ChatGPT/Codex Desktop package: OpenAI.Codex 26.818.3698.0
• Local app-server process remained alive as:

codex.exe -c features.code_mode_host=true app-server --analytics-default-enabled

• ChatGPT mobile Remote client
• Desktop package is current according to the configured Windows package sources
• Account, device, environment, pairing, network, and local-path identifiers omitted

Reproduction timeline

1. Removed the existing phone connection, restarted Desktop, reinstalled the mobile app, and completed a fresh pairing.
2. The fresh pairing became usable at approximately 10:27 local time.
3. Remote worked normally for roughly one to two hours.
4. The phone later showed Connecting... followed by a red disconnected indicator and could no longer open the host.
5. At the same time, Desktop still listed the phone with a very recent Last connected value. The Desktop UI and local Codex work remained responsive.
6. Re-pairing/restarting temporarily restores Remote, but the failure returns.

No corresponding host sleep or Windows network-disconnect event was found for the failure window.

Socket evidence

The long-lived app-server TCP connection created at 10:27:00, matching the successful fresh-pairing time, is now stuck in CLOSE_WAIT. Additional app-server port-443 connections accumulated in CLOSE_WAIT while Remote remained unavailable:

State      Creation time
CLOSE_WAIT 10:27:00
CLOSE_WAIT 11:50:54
CLOSE_WAIT 11:59:35
CLOSE_WAIT 12:03:45
CLOSE_WAIT 12:13:27
CLOSE_WAIT 12:17:46
CLOSE_WAIT 12:18:11

At the same observation point, the same app-server process still had 37 Established connections. General HTTPS/API connectivity therefore continued while the closed connections were not released or replaced.

The sanitized PowerShell check was:

$appServerPid = (Get-CimInstance Win32_Process |
  Where-Object { $_.Name -eq 'codex.exe' -and $_.CommandLine -match 'app-server' } |
  Select-Object -First 1).ProcessId

Get-NetTCPConnection -OwningProcess $appServerPid |
  Group-Object State

Get-NetTCPConnection -OwningProcess $appServerPid -State CloseWait |
  Sort-Object CreationTime |
  Select-Object State, CreationTime, RemotePort

Assessment

This is consistent with a relay/WebSocket reader or worker stopping after the peer closes the underlying TCP connection, while Desktop's persisted Remote state continues to report a recently connected/available host. The app-server does not appear to tear down and replace the stale transport in-process.

Potential durable recovery:

• supervise and recreate the Remote transport whenever its reader/worker exits or its underlying connection closes;
• reconcile desktop-visible Last connected/availability with actual relay heartbeat state;
• expose a transport-only remoteControl/reconnect operation that preserves enrollment, threads, and active turns;
• log the last successful relay heartbeat, close reason, and reconnect attempt/backoff.

No account IDs, device IDs, installation/environment IDs, pairing material, tokens, IP addresses, usernames, private paths, or conversation contents are included.