›_ Codex Issues
Codex Issues / #39915

[Remote][Windows/Android] Pairing succeeds and host WebSocket is Connected, but Android attach immediately closes with `Transport unavailable`

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

Summary

Codex Remote on Android can successfully pair with a Windows host, and the Windows host successfully creates a fresh Remote enrollment and reaches Connected on the Remote WebSocket, but the Android client cannot attach to the host. The mobile UI reports Transport unavailable, no chats are accessible, and the Windows logs show repeated Remote client connections being immediately closed.

This began after Remote had previously worked.

Environment

  • Host: Windows
  • ChatGPT Desktop package: OpenAI.ChatGPT-Desktop 1.2026.190.0
  • Codex Desktop client reported in logs: 26.818.31338
  • Remote controller: ChatGPT Android app
  • Remote pairing: succeeds
  • Mobile error: Transport unavailable

Current behavior

The desktop host registers successfully with Remote:

remote control websocket status changed previous_status=Connecting next_status=Connected
connected to app-server remote control websocket

A completely fresh Remote identity was generated and persisted successfully:

has_enrollment=true
server_id=Some("srv_e_...")
environment_id=Some("env_e_...")

However, when the Android client tries to connect, the desktop logs show repeated immediate closures such as:

forwarding remote control connection closed transport event connection_id=ConnectionId(3)
forwarding remote control connection closed transport event connection_id=ConnectionId(4)
forwarding remote control connection closed transport event connection_id=ConnectionId(5)
forwarding remote control connection closed transport event connection_id=ConnectionId(6)

Earlier in troubleshooting, the host Remote WebSocket also logged:

remote control websocket reader disconnected, err: failed to read from websocket: IO error: An existing connection was forcibly closed by the remote host. (os error 10054)

Important diagnostic result

The original Remote enrollment and installation identity were fully rotated to rule out stale local state.

After resetting:

  1. A new installation ID was generated.
  2. The old remote_control_enrollments row was removed.
  3. ChatGPT Desktop created a new server_id and environment_id.
  4. The new enrollment was persisted successfully in state_5.sqlite.
  5. The host Remote WebSocket reached Connected.
  6. Android re-pairing succeeded.
  7. Android still reports Transport unavailable and the client-side Remote connections are immediately closed.

This appears to place the failure after host registration/WebSocket setup, at the mobile-client attach/session transport stage.

Local troubleshooting already performed

  • Restarted ChatGPT/Codex Desktop
  • Restarted Windows
  • Signed out/in
  • Removed and recreated Remote pairing
  • Killed all ChatGPT/Codex processes and recreated local Remote queue/global state
  • Rotated the durable Codex installation_id
  • Removed the persisted remote_control_enrollments entry
  • Verified a brand-new Remote enrollment was subsequently created
  • Verified new server_id and environment_id values were generated
  • Verified host Remote WebSocket reaches Connected
  • Cleared all ChatGPT Android app data
  • Re-authenticated Android app
  • Re-paired Android device successfully
  • Tested Windows host on normal Wi-Fi and on a phone hotspot
  • Result is identical across networks
  • Verified ordinary ChatGPT/Codex HTTPS authentication/API requests return 200 OK

Expected behavior

After successful pairing and after the Windows Remote host reaches Connected, the Android Remote client should attach to the host and display/control supported Codex chats.

Actual behavior

Pairing succeeds, the host is enrolled and connected, but Android cannot attach. The phone reports Transport unavailable, no chats are accessible, and each client connection is immediately closed on the host.

Suspected failure boundary

Observed sequence:

  1. Authentication: works
  2. Host Remote enrollment: works
  3. Host WebSocket connection: works (Connected)
  4. Android pairing: works
  5. Android client attach: fails immediately
  6. Host logs repeated remote control connection closed transport event

This looks distinct from failures where /wham/tasks/list returns 503 or where the host itself cannot establish the Remote WebSocket.

Privacy

Account IDs, installation IDs, server/environment IDs, tokens, cookies, project content, and conversation content have been omitted/redacted. Additional sanitized log excerpts can be provided if needed.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 6 days ago

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

  • #39908
  • #39907
  • #39817

Powered by Codex Action

maitoneriumuxu · 6 days ago

Adding another reproduction with the same failure boundary.

Environment:

  • Windows host
  • Codex Desktop: 26.818.31338
  • Standalone Codex CLI: updated from 0.144.4 to 0.149.0
  • Android ChatGPT app: current Play Store version
  • ChatGPT Pro

Observed behavior:

  • QR pairing succeeds and the Android device appears in the Desktop authorized-device list.
  • Android remains on "Waiting for desktop" and eventually reports that it could not connect to the desktop.
  • Revoke + fresh pairing does not help.
  • Full Desktop/Windows restarts do not help.
  • Tested on normal Wi-Fi and with the Windows host connected through the phone hotspot; behavior is unchanged.
  • Ordinary Codex HTTPS/API traffic is healthy (200 OK).

I also fully reset the local Remote state before re-pairing. After the fresh pairing attempt, the Desktop logs repeatedly show the Remote client connection being created and then immediately closed, e.g.:

forwarding remote control connection closed transport event connection_id=ConnectionId(3)
forwarding remote control connection closed transport event connection_id=ConnectionId(4)
forwarding remote control connection closed transport event connection_id=ConnectionId(5)
dropping message for disconnected connection: ConnectionId(3)
remoteControl/status/changed

So this looks consistent with the issue described here: authentication/pairing succeeds, but Android attach/session transport fails immediately after connection creation.

Additional checks performed:

  • Desktop and Android apps are up to date.
  • Desktop Remote was toggled off/on.
  • Android was logged out/in.
  • Local Remote environment/installation IDs were cleared and regenerated before a new pairing.
  • Standalone CLI was aligned to 0.149.0.
  • codex remote-control start is not a usable workaround on native Windows because it returns: codex app-server daemon lifecycle is only supported on Unix platforms.

I can provide more sanitized log excerpts if useful.

chadontheroad · 6 days ago

Adding another confirmed reproduction with a slightly different diagnostic path.

This Windows host had Android Remote working successfully for months before the failure began. The Android phone can still Remote-control other Codex hosts normally, so this is isolated to one Windows host rather than a general mobile/account/network outage.

Observed state:

  • Android pairing succeeds.
  • Windows host enrollment is enabled and advertised correctly.
  • The desktop host connects successfully to the Remote relay.
  • Android reaches the host and begins initialization.
  • The session then closes before the desktop opens.
  • Android UI explicitly reports Transport unavailable.
  • Host logs show the Remote transport closing immediately after initialization, without a host-side 401/403/409/429/5xx, DNS, TLS, firewall, or relay-worker error.

An earlier host-side issue was also found during diagnosis: Remote was enabled in persisted state, but the real desktop app-server had not started its Remote worker. Restarting the real app-server and toggling Remote caused the worker to start and the host to connect to the relay, but this did not resolve the Android attach failure. The remaining failure is therefore post-registration/post-relay initialization.

Troubleshooting already performed:

  • Windows restarted
  • Codex Desktop restarted and updated multiple times
  • Remote disabled/re-enabled
  • Pairing revoked and recreated
  • ChatGPT Android app removed/reinstalled and re-paired
  • Wi-Fi restarted; other Remote hosts continue to work from the same Android device
  • Local Codex remains healthy
  • Local Chrome/Codex integration remains healthy

Failure boundary from host logs:

  1. Local Codex/authentication: healthy
  2. Host enrollment: healthy
  3. Remote worker: running
  4. Relay connection: healthy
  5. Android connection accepted / initialization begins
  6. Transport closes immediately
  7. Android displays Transport unavailable

No account IDs, server/environment IDs, installation IDs, tokens, hostnames, or project content included here. Sanitized timestamps/log excerpts are available if maintainers want them.

One timing detail that may or may not be relevant: this host had previously worked for months, and the failure appeared around the time another Remote host was added to the same account. I do not have evidence that the additional host caused the issue, so treating that only as correlation.

GrowDev1 · 4 days ago

I am seeing the same failure pattern on a Windows host with the ChatGPT mobile app: pairing succeeds, the desktop shows a recent Remote connection/heartbeat, but the phone reports Transport unavailable and cannot access the Codex chats. It reproduces on both the normal Wi-Fi network and a cellular hotspot. Both apps are updated; QR pairing was recreated; no VPN or proxy is in use; the PC remains awake with only the display allowed to turn off. DNS and TCP 443 connectivity to chatgpt.com and ws.chatgpt.com succeed. This appears to be the same post-enrollment mobile attach/transport failure described in this issue.