codex - 💡(How to fix) Fix Codex mobile pairing stuck on Waiting for desktop when remote-control daemon cannot use proxy

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

Codex Desktop 26.513.20950, build 2816 (com.openai.codex)

Bundled CLI/app-server:

/Applications/Codex.app/Contents/Resources/codex --version
codex-cli 0.131.0-alpha.9

What subscription do you have?

ChatGPT account signed into Codex Desktop and ChatGPT mobile app. Same account/workspace on both sides.

What platform is your computer?

macOS, Apple Silicon / arm64. The backend-reported remote-control environment OS was Mac OS 26.3.0, arch arm64.

The machine uses a local network proxy:

HTTP proxy:  127.0.0.1:7897
HTTPS proxy: 127.0.0.1:7897
SOCKS proxy: 127.0.0.1:7897

What issue are you seeing?

Codex mobile pairing gets stuck after scanning the QR code:

• Android/iOS ChatGPT opens the Codex pairing flow but stays on Waiting for desktop.
• Codex Desktop stays on the QR / Approve on your device screen.
• No visible desktop approval prompt appears.
• Re-scanning fresh iOS and Android QR codes did not help.

After debugging locally, this appears to be because the headless remote-control daemon was not using the machine's proxy configuration, so it could not report the local Mac as an online remote-control environment to the backend. The desktop UI could still show the QR code, which made this look like a pairing/mobile problem, but the backend environment list stayed empty.

What steps can reproduce the bug?

1. On macOS with a required local proxy, open Codex Desktop.
2. Open Settings → Set up Codex Mobile / Control this Mac and generate a QR code.
3. Scan from ChatGPT mobile app on Android or iOS.
4. Observe the phone remains on Waiting for desktop and the desktop QR page does not progress.

Diagnostics from the failing state

The local remote-control daemon was running and claimed remote control was enabled:

$ /Applications/Codex.app/Contents/Resources/codex remote-control
{"status":"alreadyRunning","backend":"pid","socketPath":"/Users/.../.codex/app-server-control/app-server-control.sock","cliVersion":"0.131.0-alpha.9","appServerVersion":"0.131.0-alpha.9"}

The socket and process existed:

~/.codex/app-server-control/app-server-control.sock
~/.codex/packages/standalone/current/codex -> /Applications/Codex.app/Contents/Resources/codex

But the backend API returned no remote-control environments for the account:

GET https://chatgpt.com/backend-api/codex/remote/control/environments?limit=100
{"items":[],"cursor":null}

Local SQLite also did not change after scanning; existing remote_control_enrollments rows were old and no new row was added.

The smoking gun was lsof on the remote-control daemon. Before the workaround, it was trying to connect directly to an external HTTPS address and remained stuck in SYN_SENT:

codex <pid> ... TCP <local-ip>:<port>-><external-ip>:https (SYN_SENT)

Direct backend access from this machine also timed out without the proxy, while the same request succeeded with --proxy http://127.0.0.1:7897.

Workaround that made the backend see the Mac

Restart only the remote-control daemon with explicit proxy environment variables:

pkill -f '/Users/.*/.codex/packages/standalone/current/codex .*remote_control app-server --listen unix://' 2>/dev/null || true
pkill -f '/Users/.*/.codex/packages/standalone/current/codex app-server daemon pid-update-loop' 2>/dev/null || true

HTTP_PROXY=http://127.0.0.1:7897 \
HTTPS_PROXY=http://127.0.0.1:7897 \
ALL_PROXY=http://127.0.0.1:7897 \
http_proxy=http://127.0.0.1:7897 \
https_proxy=http://127.0.0.1:7897 \
all_proxy=http://127.0.0.1:7897 \
NO_PROXY=localhost,127.0.0.1,::1 \
no_proxy=localhost,127.0.0.1,::1 \
/Applications/Codex.app/Contents/Resources/codex remote-control

After this, lsof showed the daemon using the local proxy:

codex <pid> ... TCP localhost:<port>->localhost:7897 (ESTABLISHED)

And the backend environment list immediately changed from empty to one online Mac:

{
  "items": [
    {
      "kind": "single",
      "display_name": "<hostname>.local",
      "online": true,
      "busy": false,
      "os": "Mac OS",
      "arch": "arm64",
      "app_server_version": "0.131.0-alpha.9",
      "client_type": "CODEX_DESKTOP_APP",
      "originator": "Codex Desktop"
    }
  ],
  "cursor": null
}

Expected behavior

The remote-control daemon should either:

• inherit/use the macOS system proxy configuration used by the Codex Desktop/Electron network layer, or
• inherit proxy environment variables from the desktop app, or
• surface a clear error in the QR pairing UI when it cannot reach the remote-control backend.

Actual behavior

The UI silently remains in the QR / waiting state, while the daemon cannot reach the backend and the backend has no online desktop environment to pair with. This makes the mobile app appear stuck even though the local daemon and QR UI are both present.

Related issues

This looks related to the broader Waiting for desktop reports, but with a more specific root cause/workaround:

• #22714
• #22715
• #22733

Additional notes

One confusing detail during debugging: the GUI/local app-server appears to remove remote_control = true from ~/.codex/config.toml for the normal local app-server path, while the dedicated remote-control daemon is started with --enable remote_control. That config rewrite does not seem to be the root cause here. The decisive change was whether the remote-control daemon could reach the backend through the proxy.