Android ChatGPT remote connection to Windows Codex stuck on “Waiting for desktop…”

Codex remote control only support in MacOS now.

waiting for windows version

My Mac is the same way

Adding another Windows + Android datapoint.

Environment observed locally:

• Windows Codex desktop app package path shows OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0.
• ChatGPT Android app shows the Codex tab but stays on Waiting for desktop _ / Follow the instructions in the desktop app to get connected.
• Before updating, local CLI was codex-cli 0.128.0 and did not expose codex remote-control.
• Running codex update upgraded CLI to codex-cli 0.130.0; after that, codex remote-control --help exists and says: [experimental] Start a headless app-server with remote control enabled.
• Starting codex remote-control from the repo directory leaves a running headless codex process. The only visible stderr so far is plugin/marketplace sync warnings, including 403s from chatgpt.com/backend-api/plugins/*, not a clear remote-control failure.

This suggests the Windows path may require the separate CLI codex remote-control host even when the desktop app is already open, or the desktop app is not surfacing the setup/approval flow yet. This matches the workaround reported in #22715.

Desired behavior: the Windows desktop app should either expose the same remote-control setup UX directly, or the Android waiting screen should say to update CLI and run codex remote-control when no host is registered.

Windows/Android repro with local evidence from a ChatGPT Pro account:

• Windows Codex app package: OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0
• Codex CLI: codex-cli 0.130.0
• Android ChatGPT Codex tab sees host Kenn-Desktop, but host/thread loading is unreliable; one screen shows Waiting for desktop, another shows the Windows host but thread content skeleton-loads.
• Local global state contains codexCloudAccess: "enabled_needs_setup" and remote-project-connection-backfill-completed: true.
• codex features list initially showed remote_control under-development and false; after enabling it locally, it shows true.
• Running a separate CLI codex remote-control while the desktop app is open produces websocket reset followed by repeated 409 Conflict responses from /backend-api/wham/remote/control/server with body {"detail":"Remote app server already online"}.
• There is one very large old local thread (Operator-codex, ~146 MB JSONL) that appears to be a separate Android thread-history hydration stress case.

Current conclusion: Windows host support appears partially visible in the Android UI but not reliable/supported yet. The best user workaround seems to be avoiding competing desktop app-server + CLI remote-control hosts, using a fresh/small thread for testing, and waiting for the official Windows host path or using a supported macOS host.

The same one，use Android to remote control windows codex, but the result shows the internet error, and the desktop app has no instructions

Same here....

The same question in both Android and IOS devices...
With 26.513.40821

same here... help @tibo-openai @dkundel-openai

Yes, please consider us Windows users!

same here. Win10 / Codex26.519.31651 / Android ChatGPT 1.2026.125(19)

Same

Same here on Codex v26.519.81530, ChatGPT for Android v1.2026 125 (19), Windows 11 v25H2

I can reproduce a closely related Remote pairing failure on Windows and Android. One difference from the original report is that the desktop detects an incoming connection, but pairing never completes on the phone.

Versions:

• Codex for Windows: 26.707.3748.0; the problem began after updating from 26.623.19656.0
• ChatGPT for Android: 1.2026.181 (6)
• ChatGPT Pro, Personal workspace

The issue reproduces with two Android phones on the same account and workspace:

• One phone reports “Pairing failed” even after uninstalling and reinstalling ChatGPT.
• A second phone remains stuck on “Connecting.”
• The phones were tested on cellular data while the PC used Wi-Fi.

Before resetting the server-side environment, desktop diagnostics showed repeated successful remoteControl/pairing/start requests and a connected WebSocket to chatgpt.com, with no reported DNS, proxy, firewall, TLS, or WebSocket errors.

I then deleted the old server-side Remote environment. The delete returned HTTP 204, and a follow-up environment listing confirmed that the old environment was gone. After re-enabling Remote, the desktop received a different server_id and environment_id, and the new environment appeared online. Pairing with a newly generated QR code still failed; the desktop showed an incoming connection, but the phone never reached the paired state.

This appears to be the same class of pairing-finalization failure described in this issue, although the desktop side does detect the incoming phone connection. The results also make a stale local enrollment or stale server-side environment unlikely.

Codex feedback/session ID: 019f4bd1-5914-7572-a725-ea30a0adb3de

Still a problem - garbage feature

It now says "Reconnecting to Codex desktop" Trying to restore your remote session

Current native Windows + Android reproduction with stronger evidence about where the failure occurs. This is not WSL and is not an initial thread/list timeout.

Environment

• Windows 11 Pro 25H2, build 26200.9168, x64
• Codex/ChatGPT desktop app 26.810.4967.0
• Bundled app-server: 0.148.0-alpha.9
• ChatGPT for Android: 1.2026.223
• Android 16
• Same ChatGPT account and workspace on both devices

Observed behavior

The Android device completes the pairing claim, appears in the desktop client list, and its lastSeen value updates immediately after each failed connection attempt. The phone then shows “Failed to connect to ChatGPT for desktop.”

At the same time:

• The primary desktop Remote WebSocket is connected and remains healthy.
• A second diagnostic host is rejected with 409 Remote app server already online, confirming that the backend recognizes the primary Windows host as online.
• There are no DNS, TLS, authentication, proxy, firewall, IPv4/IPv6, MTU, or generic WebSocket failures.
• After the Android attempt, the desktop receives zero mobile RPCs: no thread/list, thread/read, thread/start, turn/start, or any other message with a non-local connection ID.
• The only remote message received is the relay's synthetic initialize request (__slingshot_backend_initialize__). The relay connection stays open; it is not immediately rejected.

Clean-environment control

To rule out stale local state or a stale server-side enrollment, I repeated the test with:

1. A new isolated local Codex home and installation ID.
2. A brand-new Remote server/environment created by the current bundled app-server.
3. A fresh pairing, successfully claimed by Android 1.2026.223.
4. The previous Android grant revoked, so the fresh host was the only authorized target.

The final attempt at 2026-08-14T20:10:29Z updated the Android client's lastSeen, but the fresh, connected host again received zero mobile RPCs.

The supported revoke/re-pair flow also failed on the original environment. This makes stale SQLite state, the original environment, Windows networking, firewall policy, and host availability unlikely.

There is also older evidence from the same account: on 2026-07-22, GET /wham/remote/control/mfa_requirement returned HTTP 503 three times with upstream connection failure / Connection refused, while client/list still worked.

Likely failure boundary

Pairing/client bookkeeping succeeds and the Windows host-to-relay WebSocket succeeds, but the Android action is not forwarded into the connected server stream (or the Android client fails before emitting the first RPC). This appears to be backend routing/subscription or mobile-side pre-RPC state, not a Windows host transport issue.

Could the team trace the account's Remote routing around 2026-08-14T20:10:29Z, check for a stuck routing/subscription record, and add relay diagnostics for mobile RPC dispatch/drop reasons?