macOS Remote Control cannot be enabled #36946

Activity

1. ziqinickhan

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Aug 4, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   remote

   on Aug 4, 2026
3. github-actions commented on Aug 4, 2026

   

   github-actionsbot

   on Aug 4, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • macOS ChatGPT Desktop Remote Control setup fails with "Unable to check security requirements" #36450
   • [Windows] Remote Control appears but enabling it always fails after several seconds #36340
   • Regression: macOS migration clones installation identity and Remote Control fails with 409 #36295

   Powered by Codex Action
4. ziqinickhan commented on Aug 5, 2026

   

   ziqinickhan

   on Aug 5, 2026

   Author

   More actions

   These are not duplicates, I have reviewed them before raising the issue
5. nlarch commented on Sep 9, 2026

   

   nlarch

   on Sep 9, 2026

   More actions

   I can reproduce this issue on macOS.

   The UI shows:
   “Could not enable remote control. Please ensure only one instance of ChatGPT is running.”

   I confirmed that only one main ChatGPT process is running. The other processes are normal Codex renderer/service helpers.

   Interestingly, the desktop logs show that remoteControl/enable itself completes successfully with errorCode=null, followed by remoteControl/client/list, but no connection is created (nextConnectionCount=0).

   Later, the IPC router reports:

   [IpcRouter] Socket error errorCode=EPIPE errorMessage="write EPIPE"

   with the stack involving broadcastClientStatus and unregisterClient.

   I also completely reset the local ~/.codex/ipc directory and reproduced the same issue, so this does not appear to be caused by a stale local IPC socket or by multiple ChatGPT instances.

   Remote Control therefore appears to fail after remoteControl/enable succeeds, while the UI surfaces the misleading “only one instance” error.
6. matheusmomoa commented on Sep 10, 2026

   

   matheusmomoa

   on Sep 10, 2026

   More actions

   I can reproduce this issue on a newer ChatGPT Desktop build (26.825.51511) on macOS.

   I'm seeing the same two errors reported here:

   Couldn't enable remote control. Try again.
   Could not enable remote control. Please ensure only one instance of ChatGPT is running.

   I did some additional troubleshooting that may help narrow this down.

   Environment

   macOS / Apple Silicon
   ChatGPT Desktop: 26.825.51511
   Bundled Codex CLI: codex-cli 0.151.0-alpha.7.2
   Separately installed/global Codex CLI: codex-cli 0.153.4
   Desktop explicitly uses the bundled binary at /Applications/ChatGPT.app/Contents/Resources/codex

   What I verified

   Fully quit ChatGPT and confirmed with pgrep that no ChatGPT/Codex/OpenAI processes remained.
   Rebooted macOS completely and reproduced the issue immediately after launching ChatGPT exactly once.
   Confirmed there is only one main ChatGPT application process. The other processes are normal Codex Service/Renderer/app-server/Computer Use child processes.
   Inspected launchctl; no second ChatGPT instance was found.
   Found stale SingletonLock, SingletonCookie, and SingletonSocket entries under ~/Library/Application Support/Codex. With ChatGPT fully closed, I backed up and removed only those singleton entries and let the app recreate them.
   After recreating the singleton state, the error temporarily changed to Couldn't enable remote control. Try again, but later returned to the “only one instance” message.
   A full Mac reboot did not resolve it.
   macOS logs show my iPhone being detected as SameAccount, BLEPaired, CloudPaired, and Allowed: yes, so basic device/Continuity discovery appears to be working.

   Additional finding

   My normal ~/.codex/config.toml has:

   [features]
   js_repl = false

   As a diagnostic test, I tried adding:

   remote_connections = true

   After adding that flag, ChatGPT Desktop stopped completing startup and remained indefinitely on the loading screen.

   I restored the original config (removed remote_connections = true) and the app immediately started normally again.

   So I am currently back on the original configuration and ChatGPT/Codex works normally — only Remote Control fails.

   Given that this reproduces immediately after a full reboot with exactly one ChatGPT instance, the “only one instance” message appears to be either a false-positive singleton check or a generic error surfaced for another failure during Remote Control initialization.

   I also captured macOS unified logs during reproduction and can provide them if useful.

   Happy to run any additional diagnostics or test a fix/build if the team needs more information.

   
7. blueken commented on Sep 12, 2026

   

   blueken

   on Sep 12, 2026

   More actions

   I encountered the same error on macOS with ChatGPT Desktop 26.903.61454:

   Could not enable remote control. Please ensure only one instance of ChatGPT is running.

   I confirmed that only one main ChatGPT instance was running. The backend logs repeatedly showed tls handshake eof when connecting to:

   wss://chatgpt.com/backend-api/wham/remote/control/server

   I use some kind of proxy. TUN mode was enabled, and its connection list confirmed that the codex process was routed through the proxy. Switching proxy nodes did not resolve the issue.

   What worked for me: completely quit ChatGPT with Cmd+Q, then launch it from Terminal with explicit proxy environment variables:

   env
   HTTP_PROXY=http://127.0.0.1:7890
   HTTPS_PROXY=http://127.0.0.1:7890
   http_proxy=http://127.0.0.1:7890
   https_proxy=http://127.0.0.1:7890
   /Applications/ChatGPT.app/Contents/MacOS/ChatGPT

   Replace 7890 with your local HTTP proxy port, and keep your proxy client running.

   After launching this way, enabling Remote Control / adding a connection succeeded. These environment variables apply only to this launch; opening the app normally from the Dock will not preserve them.

   This is a confirmed workaround for my setup, not necessarily a fix for every case in this issue. The “only one instance” message may also surface for a proxy/TLS connection failure.

   👍React with 👍1Reacted by tarSoul

   🎉React with 🎉3Reacted by bob, Sun Shuo and tarSoul
8. matheusmomoa commented on Sep 12, 2026

   

   matheusmomoa

   on Sep 12, 2026

   More actions

   Update: Remote Control is now working, and I was able to complete an end-to-end test from my iPhone.

   I did not apply any additional configuration change to make it work. After reopening ChatGPT Desktop normally, the UI eventually reflected the Remote Control state correctly and showed:

   Allow connections enabled
   My iPhone listed as an authorized device
   Last connected populated

   The iPhone then showed my Mac as online in the Remote interface. I successfully sent a message from an existing Codex conversation on the iPhone, it was processed by Codex on the Mac, and the response was returned to the iPhone.

   The interesting part is that before the Desktop UI started working, the internal Codex logs in ~/.codex/logs_2.sqlite were already showing that Remote Control was successfully enrolled and connected:

   has_enrollment=true
   Connecting -> Connected
   successful connection to wss://chatgpt.com/backend-api/wham/remote/control/server
   valid server_id and environment_id
   desired_state=Enabled { persistence_preference: Some(true) }

   The connection occasionally logged:

   Operation timed out (os error 60)
   Connection reset by peer (os error 54)
   websocket disconnected

   but it subsequently reconnected successfully.

   I also confirmed that there was only one main ChatGPT process running, and a direct connectivity test to the Remote Control endpoint successfully completed DNS/TCP/TLS.

   So in my case, the error:

   Could not enable remote control. Please ensure only one instance of ChatGPT is running

   appears to have been misleading. The backend/app-server already considered Remote Control enrolled and connected while the Desktop UI was still reporting an activation failure.

   This looks consistent with a Desktop UI/state synchronization or Remote Control lifecycle issue, rather than an actual duplicate ChatGPT instance or basic network/TLS failure.

   Current status: working successfully without further configuration changes.
9. JimmieZC commented on Sep 22, 2026

   

   JimmieZC

   on Sep 22, 2026 – with ChatGPT Codex Connector

   More actions

   I can reproduce the same failure on a newer desktop build.

   Environment

   • ChatGPT/Codex desktop app: 26.915.31945 (build 9922)
   • macOS: 15.6.1 (build 24G90)

   Steps

   1. Open Settings → Connections → Control this Mac.
   2. Select Allow under “Allow devices to control this computer?”

   Actual result
   The app displays: “Couldn’t enable remote control. Try again” and Remote Control is not enabled.

   Expected result
   The Mac is enrolled as a Remote Control host and device pairing becomes available.

   This confirms the issue still occurs on desktop version 26.915.31945.
10. leopoldchou commented on Sep 29, 2026

    

    leopoldchou

    on Sep 29, 2026

    Last edited by leopoldchou

    More actions

    I ran into exactly the same issue, but there’s no need to explicitly inject environment variables anymore. There’s now a new way to fix it: add the following to ~/.codex/config.toml:

    [features]
    respect_system_proxy = true

    After adding this, reopen Codex and Remote Control should work normally.
11. zhouhn312121-code commented on Oct 2, 2026

    

    zhouhn312121-code

    on Oct 2, 2026 – with ChatGPT Codex Connector

    More actions

    I’m experiencing this on ChatGPT desktop 26.930.21537 (“Powered by Codex & OWL”), macOS Sequoia 15.7.3. Allow connections remains off. The Chinese UI has shown “Please ensure only one instance of ChatGPT is running” and, later, “Unable to update remote control status”. Phone pairing also times out.

    Fully quitting and reopening did not resolve it. Activity Monitor showed one ChatGPT main process plus auxiliary processes.

    Local executor logs repeatedly report rendezvous unavailable with reason=websocket_error. Separate durable-transport logs show timeouts, DNS lookup failures and connection refusals; I cannot confirm a shared cause.

    macOS system proxies are configured. An explicit curl request through the local HTTP proxy reached codex-cloud-backend.chatgpt.com and received CONNECT 200, then HTTP/2 403 with cf-mitigated: challenge. This does not prove successful WebSocket connectivity or that the app uses the same proxy route.

    Could a maintainer confirm this build’s proxy handling, provide a supported way to collect the underlying remote handshake error safely, and advise whether a known fix applies? I have not verified which public Codex revision this desktop build includes.