Repository navigation
Remote Control stuck on "connecting" with environmentId null on macOS #38534
Description
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
Activity
limenglong032-commits commentedon Aug 14, 2026
github-actions commentedon Aug 14, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
remote-control pairtimes out after 2s while backend pairing request allows 30s #37698Powered by Codex Action
limenglong032-commits commentedon Aug 14, 2026
已解决，根因为 MFA + 重复实例
jdcodes1 commentedon Aug 18, 2026
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 tracingwarn!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--jsongives youstatus: connecting/erroredwith no reason.environmentId: nulljust means enrollment never completed (it's only published after a successful enrollment,desired_state.rs#L168), and thepairtimeout 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 websocketfollowed by the warn line witherror/error_kindin$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: Stringalongside the status enum and print it inremote-control start --json, so users don't need log spelunking to see a connectivity cause.