Codex mobile pairing stuck on Waiting for desktop when remote-control daemon cannot use proxy

Open 💬 12 comments Opened May 15, 2026 by Electro-Dig

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?

On macOS with a required local proxy, open Codex Desktop.
Open Settings → Set up Codex Mobile / Control this Mac and generate a QR code.
Scan from ChatGPT mobile app on Android or iOS.
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.

View original on GitHub ↗

12 Comments

Electro-Dig · 2 months ago

Additional debugging narrative / how we narrowed this down:

The original symptom looked exactly like a pairing/mobile problem: after scanning the Codex Desktop QR code from ChatGPT mobile, the phone stayed on Waiting for desktop, while the desktop stayed on the QR / approval screen. This reproduced with both iOS and Android QR flows, and reopening the QR modal did not change the behavior.

We first checked the common failure modes reported by other users:

Account mismatch

Verified the desktop and mobile were intended to use the same ChatGPT account/workspace.
Local logs did not show the account mismatch / remote_control_client_enrollment_start_account_mismatch pattern seen in some other issues.

Old/stale QR code

Reopened the Codex Mobile setup screen and explicitly switched to Android QR.
Re-scanning a freshly captured QR still left mobile stuck on Waiting for desktop.
This made an old QR less likely as the main cause.

Missing local remote-control component

Initially, codex remote-control could not find the expected standalone ~/.codex/packages/standalone/current/codex binary.
Creating/fixing the standalone symlink to the bundled Codex binary made codex remote-control start successfully.
After that, codex remote-control reported remoteControlEnabled: true, and the app-server control socket existed.
However, pairing still failed, so this was necessary but not sufficient.

Stale local pairing state

Inspected ~/.codex/state_5.sqlite, especially remote_control_enrollments.
Old enrollment rows existed, but scanning the QR did not add any new rows or update recent timestamps.
Clearing/restarting local remote-control state did not by itself make the backend see the desktop.

Desktop UI feature flag confusion

codex features list sometimes showed remote_control as false for the normal local app-server path.
Inspecting the packaged desktop code showed the GUI/local app-server intentionally removes remote_control from the regular config path before local app-server startup, while the dedicated daemon is launched with --enable remote_control.
Therefore this was confusing but not the decisive root cause.

The turning point was comparing local daemon state with backend state.

Even though the local daemon was running:

codex remote-control
{"status":"alreadyRunning","backend":"pid",..."remoteControlEnabled":true,...}

and the socket existed:

~/.codex/app-server-control/app-server-control.sock

the backend still returned no environments for the account:

{"items":[],"cursor":null}

That meant the phone was waiting for a desktop environment that the server did not know was online.

The key evidence came from lsof on the remote-control daemon. In the failing state, the daemon had an outbound HTTPS connection stuck in SYN_SENT to an external address. On this machine, direct access to the backend times out unless traffic goes through the local proxy (127.0.0.1:7897). A manual backend request with curl --proxy http://127.0.0.1:7897 worked, while direct access did not.

After restarting only the remote-control daemon with explicit proxy environment variables, the connection changed from direct SYN_SENT to:

localhost:<port> -> localhost:7897 (ESTABLISHED)

Immediately after that, the backend environment list changed from empty to an online Mac:

{
  "online": true,
  "busy": false,
  "client_type": "CODEX_DESKTOP_APP",
  "originator": "Codex Desktop",
  "app_server_version": "0.131.0-alpha.9"
}

So the final conclusion is: the visible mobile symptom (Waiting for desktop) was downstream of the desktop remote-control daemon not being able to reach the remote-control backend. The QR flow and local daemon could appear present, but because the daemon was not using the required proxy, the backend environment list stayed empty and mobile had nothing to connect to.

The practical workaround was to start the remote-control daemon with explicit proxy variables. The product-side fix should probably ensure the remote-control daemon inherits or reads the same proxy configuration as Codex Desktop/Electron, and the UI should surface a clear backend connectivity error instead of silently leaving both sides waiting.

yanyige · 2 months ago

I hit what looks like a second failure mode while applying the proxy workaround.

After setting the proxy, lsof showed Codex traffic going through the local proxy:

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

However, mobile pairing still stayed on Waiting for desktop.

Further debugging showed that codex remote-control was failing with:

Error: managed standalone Codex install not found at /Users/<user>/.codex/packages/standalone/current/codex; install Codex first

On this machine, the expected managed standalone path did not exist at all:

~/.codex/packages/standalone/current/codex

Creating that path and symlinking it to the bundled Codex binary fixed this part:

mkdir -p ~/.codex/packages/standalone/current
ln -sf /Applications/Codex.app/Contents/Resources/codex ~/.codex/packages/standalone/current/codex

After that, codex remote-control successfully bootstrapped:

{
  "status": "bootstrapped",
  "backend": "pid",
  "autoUpdateEnabled": true,
  "remoteControlEnabled": true,
  "managedCodexPath": "/Users/<user>/.codex/packages/standalone/current/codex",
  "socketPath": "/Users/<user>/.codex/app-server-control/app-server-control.sock",
  "cliVersion": "0.131.0-alpha.9",
  "appServerVersion": "0.131.0-alpha.9"
}

I then restarted remote-control with explicit proxy environment variables:

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

Before the explicit proxy restart, local logs showed that a new remote-control enrollment was created, but the WebSocket connection still timed out:

created new remote control enrollment ...
failed to connect to app-server remote control websocket:
wss://chatgpt.com/backend-api/wham/remote/control/server
IO error: Operation timed out (os error 60)

After both fixes, mobile pairing succeeded.

So in this case there were two required fixes:

Restore/create the expected managed standalone Codex path: ~/.codex/packages/standalone/current/codex
Start the remote-control daemon with explicit proxy environment variables, because it was not reliably inheriting the system/app proxy configuration.

simpsonkorea · 2 months ago

Additional data point: I am now seeing a stale-host / missing-current-host variant of this issue.

Goal: connect ChatGPT mobile / Codex mobile to my main Mac mini. Instead, mobile keeps showing an old MacBook Pro host. Reinstalling the Android app does not remove it, and I cannot find any mobile-side UI to remove the stale host or add another desktop.

Current server-side environment list for the account only returns the stale MacBook Pro:

{
  "items": [
    {
      "display_name": "MacBook-Pro-8.local",
      "host_name": "MacBook-Pro-8.local",
      "online": false,
      "app_server_version": "0.131.0-alpha.9",
      "installation_id": "070da248-4647-437f-a336-7c398f658942",
      "client_type": "CODEX_DESKTOP_APP",
      "originator": "Codex Desktop",
      "last_seen_at": "2026-05-16T11:53:20.874167Z"
    }
  ],
  "cursor": null
}

The intended host is the Mac mini:

ComputerName: MAIN Mac mini 64GB
installation_id: 3ea9af4c-9882-4433-be72-154380e04060
macOS: 26.3.1 (Build 25D771280a)
codex-cli: 0.131.0-alpha.9

Local state on the Mac mini looks enabled, but it still does not appear in the backend environment list:

{
  "status": "started",
  "backend": "pid",
  "pid": 61526,
  "socketPath": "/Users/<user>/.codex/app-server-control/app-server-control.sock",
  "cliVersion": "0.131.0-alpha.9",
  "appServerVersion": "0.131.0-alpha.9"
}

Process is running with remote control enabled:

/Users/<user>/.codex/packages/standalone/current/codex --enable remote_control app-server --listen unix://

The managed standalone path was also restored on this machine:

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

But ~/.codex/state_5.sqlite has no rows in remote_control_enrollments, and the backend environment query still returns only the stale offline MacBook Pro.

This appears to be two product issues combined:

Stale remote desktop hosts remain server-side and continue to appear on mobile even after local disconnect / app reinstall.
A locally enabled Mac mini remote-control daemon can be running, but the Mac mini still does not get registered in /backend-api/codex/remote/control/environments.

Request: please provide a way to purge/reset stale remote-control hosts for the account/workspace, or expose a mobile/desktop UI to remove old hosts and force-register the current host.

alioftech · 2 months ago

Having the same issue

barayuda · 2 months ago

sameissue, but quick solutions from me right now, after update codex desktop, I did logout and completely close the app (both on my macOS and iPhone)

Then trying to scan and check on the manage connect from desktop app if the connection success. After that, all worked fine for me

Snailflyer · 2 months ago

This report is useful because it shows the desktop QR screen can be a false positive.

Generating a QR code only proves the local UI can start the pairing flow. It does not prove the remote-control daemon has successfully registered an online host with the backend.

For debugging, I would split the setup into visible gates:

local desktop UI generated pairing token;
managed daemon exists at the expected path;
daemon can reach the backend using the same proxy/network policy as the app;
backend environment list shows the intended host online;
mobile scan binds to that online environment.

If gate 1 is green but gate 3 or 4 is red, mobile will sit on Waiting for desktop even though the QR path looked valid. The product should probably surface this as desktop daemon not online / cannot reach backend rather than a generic pairing wait.

tonyzhu163 · 1 month ago

I've been stuck with the same issue for a week. Thanks OP.

iomitch · 1 month ago

Same issue here.

SquirminatorHotHead · 1 month ago

Codex Mobile Pairing Stuck on "Waiting for Desktop"

I hit the same issue and fixed it. In my case, the QR code was valid, but the desktop host never became an online remote-control environment.

Symptoms

Codex Desktop on macOS shows the QR code or "Approve on your device".
ChatGPT mobile scans the QR code successfully.
The mobile app then stays on "Waiting for desktop".
The desktop app stays on the QR code screen and never advances.

Root Cause

The Codex Desktop app itself may use the macOS proxy, but the managed remote-control / app-server daemon may not inherit the proxy environment variables.

As a result, the OpenAI backend never sees the Mac as an online Codex remote-control environment. The QR flow starts, but there is no registered desktop host for the phone to connect to.

Fix

First confirm your local proxy port:

networksetup -getwebproxy Wi-Fi
networksetup -getsecurewebproxy Wi-Fi
networksetup -getsocksfirewallproxy Wi-Fi

In my case, the proxy was:

127.0.0.1:7897

Then restart the managed remote-control daemon with explicit proxy environment variables:

pkill -f '/Users/.*/.codex/packages/standalone/current/codex app-server --remote-control --listen unix://' 2>/dev/null || true
pkill -f '/Users/.*/.codex/packages/standalone/current/codex app-server daemon pid-update-loop' 2>/dev/null || true
pkill -f 'remote_control app-server' 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 start --json

If successful, it should print something like:

{
  "mode": "daemon",
  "status": "connected",
  "serverName": "192.168.x.x",
  "environmentId": "env_...",
  "timedOut": false,
  "daemon": {
    "status": "bootstrapped",
    "remoteControlEnabled": true,
    "socketPath": "/Users/<user>/.codex/app-server-control/app-server-control.sock"
  }
}

You can verify that the daemon is really using the proxy:

lsof -nP -iTCP | grep -i codex | grep 789

Expected result:

codex ... TCP 127.0.0.1:xxxxx->127.0.0.1:7897 (ESTABLISHED)

Also check that there are no direct failed connections:

lsof -nP -iTCP -sTCP:SYN_SENT | grep -i codex

In the working state, the managed daemon had:

codex ... TCP 127.0.0.1:xxxxx->127.0.0.1:7897 (ESTABLISHED)

and no Codex SYN_SENT connections.

Final Step

After the daemon is connected:

Cancel the old "Waiting for desktop" screen on the mobile app.
Close the old QR code screen in Codex Desktop.
Open Set up Codex mobile again.
Generate a fresh QR code.
Scan the new QR code from ChatGPT mobile.

The important detail for me was running:

/Applications/Codex.app/Contents/Resources/codex remote-control start --json

with explicit proxy environment variables. Simply opening the Codex Desktop app or running the command without start did not actually bring the managed remote-control daemon online.

SquirminatorHotHead · 1 month ago

# Codex Mobile Pairing Stuck on "Waiting for Desktop" I hit the same issue and fixed it. In my case, the QR code was valid, but the desktop host never became an online remote-control environment. ## Symptoms Codex Desktop on macOS shows the QR code or "Approve on your device". ChatGPT mobile scans the QR code successfully. The mobile app then stays on "Waiting for desktop". The desktop app stays on the QR code screen and never advances. ## Root Cause The Codex Desktop app itself may use the macOS proxy, but the managed remote-control / app-server daemon may not inherit the proxy environment variables. As a result, the OpenAI backend never sees the Mac as an online Codex remote-control environment. The QR flow starts, but there is no registered desktop host for the phone to connect to. ## Fix First confirm your local proxy port: networksetup -getwebproxy Wi-Fi networksetup -getsecurewebproxy Wi-Fi networksetup -getsocksfirewallproxy Wi-Fi In my case, the proxy was: `` 127.0.0.1:7897 ` Then restart the managed remote-control daemon with explicit proxy environment variables: pkill -f '/Users/.*/.codex/packages/standalone/current/codex app-server --remote-control --listen unix://' 2>/dev/null || true pkill -f '/Users/.*/.codex/packages/standalone/current/codex app-server daemon pid-update-loop' 2>/dev/null || true pkill -f 'remote_control app-server' 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 start --json If successful, it should print something like: { "mode": "daemon", "status": "connected", "serverName": "192.168.x.x", "environmentId": "env_...", "timedOut": false, "daemon": { "status": "bootstrapped", "remoteControlEnabled": true, "socketPath": "/Users/<user>/.codex/app-server-control/app-server-control.sock" } } You can verify that the daemon is really using the proxy: lsof -nP -iTCP | grep -i codex | grep 789 Expected result: ` codex ... TCP 127.0.0.1:xxxxx->127.0.0.1:7897 (ESTABLISHED) ` Also check that there are no direct failed connections: lsof -nP -iTCP -sTCP:SYN_SENT | grep -i codex In the working state, the managed daemon had: ` codex ... TCP 127.0.0.1:xxxxx->127.0.0.1:7897 (ESTABLISHED) ` and no Codex SYN_SENT connections. ## Final Step After the daemon is connected: 1. Cancel the old "Waiting for desktop" screen on the mobile app. 2. Close the old QR code screen in Codex Desktop. 3. Open Set up Codex mobile again. 4. Generate a fresh QR code. 5. Scan the new QR code from ChatGPT mobile. The important detail for me was running: /Applications/Codex.app/Contents/Resources/codex remote-control start --json with explicit proxy environment variables. Simply opening the Codex Desktop app or running the command without start` did not actually bring the managed remote-control daemon online.

In my case, I just let my codex desktop app know what the issue look like and post this github issue in it, it helped me yo solve the problem. Now it works!

handlf · 15 days ago

Confirmed on Windows 11 — same root cause, and here is a Windows workaround that makes the fix persistent.

Environment

Windows 11 Pro, Codex Desktop (Microsoft Store package OpenAI.Codex_26.623.13972.0_x64)
Local proxy: v2rayN, HTTP proxy at http://127.0.0.1:10808 (system proxy is set and the main Codex chat works fine through it)

Symptoms (identical to OP)

Toggling Allow connections in Settings → Connections fails with "Could not update remote control status"
The pairing QR code sometimes renders, but the phone reports "This isn't a valid remote control pairing code" — i.e. the QR is rendered locally while the backend registration never happened
netstat shows connections stuck in SYN_SENT (the remote-control daemon is trying to reach chatgpt.com directly, ignoring the system proxy)

Windows workaround (persistent, no manual daemon launch needed)

Instead of launching the daemon manually with env vars (macOS workaround above), set user-level environment variables so the Codex app — and the daemon it spawns — inherit them automatically on every launch:

[Environment]::SetEnvironmentVariable("HTTP_PROXY",  "http://127.0.0.1:10808", "User")
[Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://127.0.0.1:10808", "User")
[Environment]::SetEnvironmentVariable("NO_PROXY",    "localhost,127.0.0.1,::1", "User")

Then fully kill all Codex processes (closing the window is not enough — check with Get-Process | Where-Object {$_.ProcessName -match "codex"}) and relaunch the app:

Get-Process | Where-Object {$_.ProcessName -match "codex"} | Stop-Process -Force

After relaunch:

The Allow connections toggle turns on and stays on, no error banner
The pairing QR code is generated and accepted by the phone

Notes

Replace 10808 with your own local proxy port.
NO_PROXY matters — without it, local loopback traffic may also be routed to the proxy.
Side effect: these are user-wide variables, so CLI tools that honor them (git/pip/npm/curl…) will also route through the proxy. Remove with [Environment]::SetEnvironmentVariable("HTTP_PROXY", $null, "User") (same for the other two) if needed.

Hope the daemon can respect the OS system proxy (or at least the app's own proxy settings) in a future release. 🙏

onlylemi · 14 days ago

Hitting the same class of issue on macOS. Sharing diagnosis details in case it helps.

Environment

Codex Desktop 26.623.101652 (build 4674), bundled CLI codex-cli 0.142.5
macOS 26.5.1 (arm64)
Network: outbound access requires a local proxy (Clash at 127.0.0.1:7890); the macOS system proxy is properly configured. On this network, chatgpt.com is not reachable via direct connections.

Symptom

Reproducible on macOS as well: Settings → Allow devices to control this computer → clicking Allow fails with "Couldn't enable remote control. Try again". Everything else (conversations, etc.) works fine.

Diagnosis: two network paths inside the same process behave differently w.r.t. proxy

Failure in the app logs (~/Library/Logs/com.openai.codex/...):

error={"code":-32603,"message":"failed to list remote control clients:
error sending request for url (https://chatgpt.com/backend-api/wham/remote/control/environments/env_e_.../clients?limit=100&order=desc)"}

Running lsof against the codex app-server process shows both kinds of connections simultaneously:

codex  ...  TCP 127.0.0.1:64555->127.0.0.1:7890 (ESTABLISHED)   <- regular API, via system proxy, works
codex  ...  TCP 192.168.x.x:64739->x.x.x.x:443 (SYN_SENT)       <- remote control, direct connection, stuck

So the main API client honors the macOS system proxy (which is why chat works), while the remote-control path uses a different network client that ignores the system proxy and attempts a direct connection — hence only this feature breaks. This looks like the same root cause as #29958 (on Windows, the WebSocket transport bypasses the system proxy and only honors env vars).

Workaround

Launching Codex with proxy environment variables fully restores remote control (remoteControl/pairing/start and client/list both succeed; lsof confirms all connections go through the proxy):

HTTP_PROXY=http://127.0.0.1:7890 HTTPS_PROXY=http://127.0.0.1:7890 \
ALL_PROXY=socks5://127.0.0.1:7890 /Applications/Codex.app/Contents/MacOS/Codex

Since Finder/Dock launches don't inherit shell env vars (see #30695), I keep a minimal wrapper .app in the Dock (a shell script that exports the proxy vars and execs the real binary).

Expectation: unify proxy behavior between the remote-control path and the main API client — honor the system proxy.