›_ Codex Issues
Codex Issues / #35351

macOS Desktop: "Unable to update remote control state" although remoteControl/enable succeeds

Open 💬 6 comments Opened Jul 25, 2026 by SamuelXiao

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

Codex Desktop 26.721.41059 app-server 0.146.0-alpha.3.1

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS 26.5.2

What issue are you seeing?

In Settings > Connections > Control this Mac, enabling “Allow connections” immediately shows the toast:

Unable to update remote control state

The toggle then automatically turns off.

This persists after revoking all previously authorized Android remote-control clients and restarting Codex Desktop.

What steps can reproduce the bug?

  1. Open Codex Desktop.
  2. Go to Settings > Connections > Control this Mac.
  3. Turn on “Allow connections”.
  4. Observe the error toast and that the toggle immediately returns to off.

What is the expected behavior?

“Allow connections” should remain enabled, allowing a mobile device to pair with and control this Mac.

Additional information

he relevant desktop logs use UTC timestamps (China time: UTC+8).

After revoking both authorized Android clients, the service calls reported success:

2026-07-25T13:26:33.503Z info [AppServerConnection] response_routed durationMs=1680 errorCode=null method=remoteControl/client/revoke
2026-07-25T13:26:35.102Z info [AppServerConnection] response_routed durationMs=1597 errorCode=null method=remoteControl/client/list
2026-07-25T13:26:36.910Z info [AppServerConnection] response_routed durationMs=2335 errorCode=null method=remoteControl/client/revoke
2026-07-25T13:26:38.065Z info [AppServerConnection] response_routed durationMs=1153 errorCode=null method=remoteControl/client/list
2026-07-25T13:26:38.389Z info [AppServerConnection] response_routed durationMs=1 errorCode=null method=remoteControl/enable
2026-07-25T13:26:44.014Z info [remote-connections/window-context] refresh_remote_control_started previousConnectionCount=0
2026-07-25T13:26:44.018Z info [remote-connections/window-context] reconcile_completed creationFailureCount=0 nextConnectionCount=0 previousConnectionCount=0
2026-07-25T13:26:44.018Z info [remote-connections/window-context] refresh_remote_control_completed autoConnectConnectionCount=0 nextConnectionCount=0 previousConnectionCount=0

Despite remoteControl/enable returning errorCode=null, the UI reported failure and reset the toggle. No corresponding error was written to the desktop log.

View original on GitHub ↗

6 Comments

SamuelXiao · 1 month ago

Update: proxy handling appears inconsistent

Environment:

  • macOS
  • ChatGPT Desktop 26.721.41059
  • ClashX Meta enabled

Normal ChatGPT usage worked correctly, but Remote Connections could not be enabled. The switch kept failing, and the QR code was missing or appeared only intermittently.

The apparent cause is that the main ChatGPT UI and the bundled Codex/Remote Connections service do not use the same proxy mechanism. The main UI could access the network through the macOS system proxy, while the Remote Connections service, including its HTTPS and WebSocket requests, did not reliably inherit or respect that proxy.

The feature started working after:

  1. Enabling respect_system_proxy = true in the Codex configuration.
  2. Setting HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and WSS_PROXY through launchctl.
  3. Fully restarting ChatGPT Desktop.

Changing Clash nodes alone did not fix the issue.

It would be helpful if all ChatGPT Desktop components used one unified proxy mechanism—preferably the macOS system proxy—without requiring users to configure process-level environment variables separately. Proxy failures should also be surfaced clearly in the UI and logs instead of appearing only as a failed Remote Connections switch.

tzhou530 · 12 days ago

This solved my problem. Thank you!!

securAd · 10 days ago
问题解决了，谢谢！

大佬你好，我也遇到了这个问题，请问是怎么解决的方便说一下吗

tzhou530 · 10 days ago
> 问题解决了，谢谢！ > 大佬你好，我也遇到了这个问题，请问是怎么解决的方便说一下吗

直接在codex 回复：
Enabling respect_system_proxy = true in the Codex configuration.
Setting HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and WSS_PROXY through launchctl.
Fully restarting ChatGPT Desktop.

iamthecloverly · 8 days ago

I traced the Remote Control failure down to the security-check stage. macOS TCC explicitly returns result=true / authValue=2 for kTCCServiceScreenCapture requested by com.openai.codex, and the ChatGPT code signature validates successfully. Accessibility is enabled for Codex Computer Use (com.openai.sky.CUAService), which is also running and correctly signed by OpenAI. The Mac is an M4 Pro with Full Security, SIP enabled, and SSV enabled. ChatGPT backend endpoints are reachable from the Mac. Despite all of this, Control this Mac still returns "Couldn't check security requirements." This looks like a Remote Control enrollment/security-check issue rather than a macOS permission or hardware issue.

Haoyu0124 · 7 days ago

I’m seeing the same Remote Control failure on a Mac, but it happens before the Set up/Add flow becomes available.

Environment:

  • ChatGPT Desktop 26.818.21641
  • Bundled Codex: 0.148.0-alpha.21
  • macOS 26.6 (arm64)
  • The same ChatGPT account is signed in on iPhone and Mac

Reproduction:

  1. Go to Settings > Connections > Control this Mac.
  2. Turn on “Allow connections”.
  3. The toggle fails with: “Couldn’t update remote control availability”.
  4. It returns to off, and Set up/Add is not shown.

What I verified:

  • Both devices were switched from an old account to the current account.
  • The old local remote-control enrollment was removed; current enrollment count is 0.
  • SQLite integrity check passes.
  • No VPN or system HTTP/HTTPS proxy is enabled.
  • ChatGPT and Codex otherwise work normally.

This appears to fail during Remote Control availability/enrollment initialization, before QR pairing. Could maintainers confirm whether this is related to #35351 and advise what diagnostics or fix are needed?