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