Skip to content

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

Open
Open
Android ChatGPT remote connection to Windows Codex stuck on “Waiting for desktop…”#22733
Labels
appIssues related to the Codex desktop appbugSomething isn't workingremote

Description

@yanivavrahami
yanivavrahami
opened on May 15, 2026

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

26.513.11550

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Windows 11, x64

What issue are you seeing?

I am trying to start a remote Codex session from the ChatGPT Android app to my Windows PC. On Android, the ChatGPT app shows “Waiting for desktop...”, but on the Windows Codex desktop app I do not see any incoming request, notification, approval prompt, or session.

Steps to reproduce

  1. Open the Codex desktop app on Windows and make sure I am signed in.
  2. Open the ChatGPT app on Android.
  3. Start a remote Codex session from Android.
  4. Try to connect to my Windows desktop.
  5. Wait for the desktop app to respond.

Expected behavior

The Windows Codex desktop app should show an incoming remote session request, approval prompt, notification, or start the remote connection.

Actual behavior

The Android ChatGPT app stays stuck on “Waiting for desktop...”.

The Windows Codex desktop app shows nothing. There is no notification, no approval prompt, and no visible incoming connection.

What steps can reproduce the bug?

  • Restarted the Codex desktop app
  • Restarted the ChatGPT Android app
  • Confirmed I am signed in on both devices
  • Tried again multiple times

What is the expected behavior?

The Windows Codex desktop app should show an incoming remote session request, approval prompt, notification, or start the remote connection.

Additional information

No response

Activity

  1. yanivavrahami
    added
    appIssues related to the Codex desktop app
    on May 15, 2026
  2. etraut-openai
    added
    bugSomething isn't working
    remote
    on May 15, 2026

  3. JoeGou commented on May 15, 2026

    @JoeGou
    JoeGou
    on May 15, 2026

    Codex remote control only support in MacOS now.

    waiting for windows version

  4. arejager commented on May 15, 2026

    @arejager
    arejager
    on May 15, 2026

    My Mac is the same way

  5. acutype commented on May 15, 2026

    @acutype
    acutype
    on May 15, 2026

    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.

  6. acutype commented on May 15, 2026

    @acutype
    acutype
    on May 15, 2026

    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.

  7. LYLiu-028 commented on May 17, 2026

    @LYLiu-028
    LYLiu-028
    on May 17, 2026

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

  8. Nasnl commented on May 17, 2026

    @Nasnl
    Nasnl
    on May 17, 2026

    Same here....

  9. Hylouis233 commented on May 17, 2026

    @Hylouis233
    Hylouis233
    on May 17, 2026

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

  10. marcelo-azevedo-br commented on May 21, 2026

    @marcelo-azevedo-br
    marcelo-azevedo-br
    on May 21, 2026

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

  11. lucky0218 commented on May 22, 2026

    @lucky0218
    lucky0218
    on May 22, 2026

    Yes, please consider us Windows users!

  12. AntaresFeng commented on May 22, 2026

    @AntaresFeng
    AntaresFeng
    on May 22, 2026

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

  13. x3r0s commented on May 22, 2026

    @x3r0s
    x3r0s
    on May 22, 2026

    Same

  14. mariusriishaugan commented on May 27, 2026

    @mariusriishaugan
    mariusriishaugan
    on May 27, 2026

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

  15. WESLEY780 commented on Jul 10, 2026

    @WESLEY780
    WESLEY780
    on Jul 10, 2026 – with ChatGPT Codex Connector

    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

  16. kendonB commented on Jul 22, 2026

    @kendonB
    kendonB
    on Jul 22, 2026

    Still a problem - garbage feature

  17. kendonB commented on Jul 22, 2026

    @kendonB
    kendonB
    on Jul 22, 2026

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

  18. guschain commented on Aug 14, 2026

    @guschain
    guschain
    on Aug 14, 2026 – with ChatGPT Codex Connector

    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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingremote

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions