Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix Pairing stuck on "Waiting for desktop" after QR scan — all client-side resets exhausted

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

After scanning the Codex desktop pairing QR with the iOS system Camera (Universal Link correctly opens ChatGPT app), ChatGPT lands on the generic "Waiting for desktop" page (monitor icon + "Please follow instructions in desktop app") with no Approve / Cancel buttons. The pairing never completes. Doing every possible client-side reset (token refresh, state file purge, keychain wipe, full Application Support deletion, DNS flush) does not change the symptom.

This appears related to but more advanced than #22715, #22851, #23078 — all of those have a clear root cause (proxy missing / device offline / stale backend record). In my case all of those have been verified clean and the symptom persists.

Error Message

  • A. Electron renderer: Click "Add" generates QR but doesn't successfully POST the pairing token to the backend (silent failure, no error UI, no log)
  • C. iPhone app routing: Deep link handler receives the URL, fails to fetch token details, falls back to generic waiting page without surfacing the error The "silent fallback to generic waiting page" behavior is suspicious in itself — even if the underlying registration/lookup fails, the iPhone app should surface a clear error ("Could not verify pairing token, please try again") rather than imitating the success state. That alone is worth a UX fix.

Root Cause

This appears related to but more advanced than #22715, #22851, #23078 — all of those have a clear root cause (proxy missing / device offline / stale backend record). In my case all of those have been verified clean and the symptom persists.

Fix Action

Workaround

None found for the iPhone pairing path. Using https://chatgpt.com/codex from a regular browser as an alternative remote-control entry works.

RAW_BUFFERClick to expand / collapse

Codex mobile pairing: QR scan opens ChatGPT but lands on generic "Waiting for desktop" instead of approval page; client-side cleanups exhausted

Summary

After scanning the Codex desktop pairing QR with the iOS system Camera (Universal Link correctly opens ChatGPT app), ChatGPT lands on the generic "Waiting for desktop" page (monitor icon + "Please follow instructions in desktop app") with no Approve / Cancel buttons. The pairing never completes. Doing every possible client-side reset (token refresh, state file purge, keychain wipe, full Application Support deletion, DNS flush) does not change the symptom.

This appears related to but more advanced than #22715, #22851, #23078 — all of those have a clear root cause (proxy missing / device offline / stale backend record). In my case all of those have been verified clean and the symptom persists.

Environment

Codex Mac app26.513.31313
macOS13.7.8 (22H730), Intel Mac
ChatGPT iOS app(latest from App Store as of 2026-05-18)
Planchatgpt_plan_type: "prolite" (Pro Lite, $100)
Sign-in method (both sides)Google OAuth, same chatgpt_user_id
Region / localesg
NetworkDirect (no proxy/VPN on Mac after Bifrost was disabled — verified TLS handshake returns real Google Trust Services certs from chatgpt.com, not MITM)

Steps to reproduce

  1. Mac Codex → Settings → Connections → Add
  2. QR appears, page title "Approve on mobile device", iOS/Android tabs
  3. iPhone scans the QR with iOS system Camera
  4. Banner shows "Open in ChatGPT" (Universal Link recognized correctly)
  5. Tap banner → ChatGPT app opens

Expected: ChatGPT navigates to the approval page shown in the on-Mac mockup ("Allow this phone to access Codex on your computer?" + Allow / Cancel buttons).

Actual: ChatGPT navigates to a generic "Waiting for desktop..." page (monitor icon + subtitle "Please follow the instructions in the desktop app"), no buttons, no Mac details. Indefinite wait. Mac stays on the "waiting for mobile approval" QR page.

Diagnostic findings

1. Network is healthy and direct

  • curl --noproxy '*' https://chatgpt.com returns real cert (issuer: O=Google Trust Services)
  • All Codex outbound TCP sockets reach Cloudflare IPs serving chatgpt.com (104.18.32.47, 104.18.37.228, 172.64.155.209)
  • auth.openai.com reachable; token refresh works

2. Auth state is fresh and consistent

  • ~/.codex/auth.json rewritten on each sign-out/in cycle
  • Decoded id_token claims: valid expiration, sub: google-oauth2|..., chatgpt_user_id: user-OoS...
  • iPhone ChatGPT app signed in with same Continue with Google, same email
  • Note: iPhone Settings UI displays subscription as "ChatGPT Pro" even though token says prolite — assume UI shorthand, not an account mismatch

3. Mac UI / local-state inconsistency

  • Before my cleanup: Application Support Cookies file fresh, but ~/.codex/.codex-global-state.json had electron-remote-control-client-enrollments populated (with Secure Enclave keyId dk_hse_qDMTiyED5WEMF0q5bm6Wce_DdMTIOyeT5WF0CLpg8zE) and codex-mobile-has-connected-device: true, yet the Connections UI showed "No devices that can control this Mac" with the empty placeholder + Add button
  • After clearing those keys and restarting: a stale device "Macintosh Intel Mac OS X — last connected 2 hours ago" appeared in the list (likely a backend ghost record from earlier attempts)
  • Revoking that stale entry, clicking Add, scanning again: same "Waiting for desktop" outcome on iPhone

4. Click "Add" on Mac → ZERO Rust-backend log activity, ZERO new TCP sockets

This is the most interesting finding. With a clean baseline (7 ESTABLISHED sockets, all to chatgpt.com CF + 1 to gcp.nel.cloudflare.com), clicking Add to generate a fresh QR:

  • lsof connection set: identical source ports before/after, no new sockets
  • ~/.codex/log/codex-tui.log: 81 new lines, all from an unrelated background chat session (gpt-5.5 pnpm test in another workspace). Zero events from any module matching remote_control|enroll|relay|pair|register|websocket.*(remote|relay)
  • macOS log show --predicate 'process CONTAINS Codex' --last 90s: only HIToolbox/NotchFrame UI events

Interpretation: The QR pairing flow is entirely client-side in the Electron renderer (JS/TS), and its HTTP traffic is multiplexed over existing HTTP/2 connections (invisible to lsof). The Rust codex app-server is not involved at all in QR generation or remote-control registration.

Without --remote-debugging-port exposed on a production Codex build, I cannot observe what (if any) request the renderer makes to register the pairing token with the backend.

5. Things I tried (every one of them; none changed the symptom)

  • Disabled corporate MITM proxy (it was breaking WSS Upgrade); confirmed direct connections work and Cloudflare returns real chatgpt.com certs
  • Sign out + Sign in (Google) on both Mac Codex and iPhone ChatGPT
  • Deleted electron-remote-control-client-enrollments, electron-local-remote-control-installation-id, codex-mobile-has-connected-device from .codex-global-state.json
  • Revoked the stale "Macintosh Intel Mac OS X" device entry in Mac Connections UI
  • Fully removed ~/Library/Application Support/Codex/ (backup kept)
  • Deleted both Codex Safe Storage keychain items (forced safeStorage key regeneration)
  • Cleaned ~/.codex/tmp/, ~/.codex/cache/
  • sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
  • Restarted Codex from canonical /Applications/Codex.app path
  • Tried iPhone on Wi-Fi (works for normal ChatGPT chat at full speed)
  • Codex Mac CLI subcommand codex remote-control fails with managed standalone Codex install not found at ~/.codex/packages/standalone/current/codex — that workaround from #22851 is not applicable to the bundled Electron install path

Hypothesis

The failure is in one of:

  • A. Electron renderer: Click "Add" generates QR but doesn't successfully POST the pairing token to the backend (silent failure, no error UI, no log)
  • B. Backend: Token is registered but the relay/account state machine doesn't return Mac details to iPhone when iPhone POSTs the token after scan
  • C. iPhone app routing: Deep link handler receives the URL, fails to fetch token details, falls back to generic waiting page without surfacing the error

The "silent fallback to generic waiting page" behavior is suspicious in itself — even if the underlying registration/lookup fails, the iPhone app should surface a clear error ("Could not verify pairing token, please try again") rather than imitating the success state. That alone is worth a UX fix.

What would help diagnose further

If an OpenAI engineer can:

  • Look up account user-OoSEiSE3o6J2g1oFQFngUVYg and see whether the most recent Add-generated pairing token T was ever received by the backend, and what the response was when iPhone POSTed T
  • Look at this account's relay/remote-control subscription state at the time of the scan
  • Confirm whether prolite plan in this region/account has remote-control feature flag fully enabled

Workaround

None found for the iPhone pairing path. Using https://chatgpt.com/codex from a regular browser as an alternative remote-control entry works.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#installation#latency issue#model loading#dependency error#configuration error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Pairing stuck on "Waiting for desktop" after QR scan — all client-side resets exhausted