›_ Codex Issues
Codex Issues / #38534

Remote Control stuck on "connecting" with environmentId null on macOS

Open 💬 4 comments Opened Aug 14, 2026 by limenglong032-commits
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.803.61601

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

macOS Codex Remote Control fails to establish a connection.

Codex CLI: 0.147.0
Authentication: Logged in using ChatGPT

codex remote-control start --json:
status: connecting
environmentId: null
timedOut: true

Error:
Remote control is enabled on MacBook-Pro-10.local but the connection is errored.

codex remote-control pair --json:
timed out waiting for remoteControl/pairing/start response
deadline has elapsed

Already tested:

  • Latest Codex CLI
  • Logout/login
  • Restart ChatGPT Desktop
  • Restart remote-control daemon
  • Multiple VPN/proxy nodes
  • HTTP/HTTPS proxy environment variables
  • Shadowrocket global proxy
  • Shadowrocket forced routing/tunnel mode

Feedback ID:
no-active-thread-019fff78-c4bc-75b0-ae5f-bd1276fda31e

What steps can reproduce the bug?

Feedback ID: no-active-thread-019fff78-c4bc-75b0-ae5f-bd1276fda31e

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

4 Comments

limenglong032-commits · 14 days ago
  1. Open ChatGPT/Codex Desktop on macOS.
  2. Sign in with ChatGPT Plus.
  3. Enable Remote Control.
  4. Run: codex remote-control start --json
  5. Remote remains stuck on "connecting", environmentId stays null, and the request times out.
github-actions[bot] contributor · 14 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #37698

Powered by Codex Action

limenglong032-commits · 14 days ago

已解决，根因为 MFA + 重复实例

jdcodes1 · 9 days ago

Two things worth knowing from the code here.

The status you can see is deliberately lossy: on every failed connect the daemon publishes only the bare enum RemoteControlConnectionStatus::Errored — the actual cause (HTTP status, cf-ray, error kind) goes exclusively to a tracing warn! in the daemon log (https://github.com/openai/codex/blob/1f41cc5d92/codex-rs/app-server-transport/src/transport/remote_control/websocket.rs#L775-L799). That's why --json gives you status: connecting/errored with no reason. environmentId: null just means enrollment never completed (it's only published after a successful enrollment, desired_state.rs#L168), and the pair timeout is downstream of the same dead connection — three symptoms, one failed WebSocket connect.

So the real diagnosis is in your log: look for connecting to app-server remote control websocket followed by the warn line with error / error_kind in $CODEX_HOME/log/. Given the VPN/proxy environment, a blocked or MITM'd WSS upgrade is the most likely culprit — the connect-error formatter already captures HTTP status and body when the edge rejects it.

Fix suggestion for the repo: carry a last_error: String alongside the status enum and print it in remote-control start --json, so users don't need log spelunking to see a connectivity cause.