Failed to authorize remote control

Resolved 💬 41 comments Opened May 14, 2026 by MerijnRaaijmakers Closed May 16, 2026

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

Codex 26.513.20950

What subscription do you have?

Pro plan

What platform is your computer?

MacOS - Darwin 25.2.0 arm64 arm

What issue are you seeing?

Codex just got updated and trying to setup the "Control other devices" under the connections tab in settings. Sadly getting the "Failed to authorize remote control" error after pressing the "Authorize on chatgpt.com" button.

What steps can reproduce the bug?

Go to the connections page under the settings panel.
Click the Control other devices tab.
Click "Set up".
On the popup panel click "Authorize on chatgpt.com"
Error happens "Failed to authorize remote control"

What is the expected behavior?

Browser opens to authorize on chatgpt.com

Additional information

Already got SSH configured without problems.

View original on GitHub ↗

41 Comments

johnsilvavlogs · 2 months ago

I can reproduce this on another Mac with the same Codex app build.

Environment:

Codex Desktop 26.513.20950, build 2816 (com.openai.codex)
Bundled app-server reports currentVersion=0.131.0-alpha.9
codex-cli 0.130.0
macOS 26.3 (25D125), arm64, Apple M1 Max
ChatGPT-authenticated Pro account

Observed behavior:

Connections -> Control other devices -> Authorize on chatgpt.com
No browser authorization page opens
Codex immediately shows the toast: Failed to authorize remote control
Reproduced twice in the same session around 2026-05-14T21:13:36Z and 2026-05-14T21:13:45Z

Local log clues, with account/user identifiers redacted:

[remote-control-websocket] remote_control_client_enrollment_start_request hasExistingEnrollment=false ...
[remote-control-websocket] remote_control_client_enrollment_start_response hasExistingEnrollment=false ...
[remote-control-websocket] remote_control_client_enrollment_start_account_mismatch ...
[electron-message-handler] [remote-connections/settings] remote_control_authorize_failed errorMessage="Remote control enrollment start does not match current account."

The actionable detail from the full local log is that the request has matching headerChatGptAccountId / tokenAccountId, but the enrollment response's responseAccountUserId appears to use the bare user-id shape while selectedAccountUserId / tokenAccountUserId use the combined user_id__account_id shape.

This looks like an account identifier normalization/comparison mismatch before the browser authorization page is opened, not just a browser launch failure.

jasonarend · 2 months ago

Another repro from a Mac with the same current desktop build.

Environment:

Codex Desktop 26.513.20950, build 2816 (com.openai.codex)
codex-cli 0.130.0
macOS 26.4.1 (25E253), arm64
ChatGPT-authenticated account

Observed behavior:

Mobile-device remote control works from this account.
Computer-to-computer authorization fails on multiple already-signed-in Macs.
In Codex Desktop: Connections -> Control other devices -> Set up -> Authorize on chatgpt.com
The app immediately shows the toast: Failed to authorize remote control.
The browser auth flow does not complete before the failure toast appears.
Reproduced around 2026-05-14 16:32 America/Chicago.

This looks aligned with the existing report: the failure appears specific to authorizing this Mac to control other signed-in desktop devices, not general ChatGPT/Codex auth and not mobile remote-control connectivity.

I checked the accessible local logs on this machine, but did not find a clean remote_control_client_enrollment_start_account_mismatch line to add without including unrelated/sensitive telemetry. The visible behavior and build/version match this issue exactly.

fqure · 2 months ago

Codex Desktop 26.513.20950, build 2816 (com.openai.codex)
macOS 26.3 (25D125), arm64
ChatGPT-authenticated account

Able to connect iPhone with same crews but not M1 controlling an M4 Mac

Mobile/iPhone remote control works for the same account, but Codex M1 Desktop-to-Codex M4 Desktop authorization fails from Settings -> Connections -> Control other devices -> Authorize on chatgpt.com with “Failed to authorize remote control”.

noctilust · 2 months ago

I am seeing the same failure on Codex 26.513.20950 (2816) on macOS 26.5 / Darwin 25.5.0 arm64.

I dug into the local Codex logs around the toast. The visible failure is preceded by a remote-control enrollment account mismatch, but the values look like a format mismatch rather than a real account mismatch:

remote_control_client_enrollment_start_request
  hasExistingEnrollment=false
  headerChatGptAccountId=<account-id-A>
  selectedAccountUserId=<user-id>__<account-id-A>
  tokenAccountId=<account-id-A>
  tokenAccountUserId=<user-id>__<account-id-A>
  tokenAuthUserId=<user-id>

remote_control_client_enrollment_start_response
  responseAccountUserId=<user-id>
  responseClientId=cli_...
  responseChallengeId=rch_...

remote_control_client_enrollment_start_account_mismatch
  responseAccountUserId=<user-id>
  selectedAccountUserId=<user-id>__<account-id-A>
  tokenAccountId=<account-id-A>
  tokenAccountUserId=<user-id>__<account-id-A>
  tokenAuthUserId=<user-id>

remote_control_authorize_failed
  errorMessage="Remote control enrollment start does not match current account."

This happened at 2026-05-14T23:16:11Z immediately after clicking Authorize on chatgpt.com. The same pattern appears on repeated attempts.

I also inspected the packaged app code locally and it looks like enrollment start does a strict comparison between the API response account_user_id and the current token account-user id. In this case the ChatGPT account id matches, but the enrollment API returns the bare user id while the token/current account user id includes the __<account-id> suffix. That appears to make Codex reject a valid enrollment response.

There is also repeated log noise in the same session where experimentalFeature/enablement/set for auth_elicitation returns unsupported feature enablement, which may indicate client/server feature-contract skew, but the direct cause of the toast is the remote-control enrollment account-id comparison above.

michaelko · 2 months ago

Also getting this same issue

o1xhack · 2 months ago

I can reproduce the same issue.

Environment:

Codex Desktop: 26.513.20950, build 2816
macOS: arm64
ChatGPT-authenticated account
Desktop-to-desktop remote control authorization fails
The failure happens immediately after clicking Authorize on chatgpt.com

Observed:
Settings → Connections → Control other devices → Set up → Authorize on chatgpt.com

Codex immediately shows:

Failed to authorize remote control

The browser authorization flow does not open or complete.

I checked the local Codex Desktop logs under:

~/Library/Logs/com.openai.codex/YYYY/MM/DD

The local logs show repeated occurrences of the same pattern:

remote_control_client_enrollment_start_response

followed by:

remote_control_client_enrollment_start_account_mismatch

followed by:

remote_control_authorize_failed

with:

errorMessage="Remote control enrollment start does not match current account."

Redacted shape of the relevant fields:

responseAccountUserId=<user-id>

but:

selectedAccountUserId=<user-id>__<account-id>

and:

tokenAccountUserId=<user-id>__<account-id>

while:

headerChatGptAccountId=<account-id>

and:

tokenAccountId=<account-id>

match.

This appears to be the same account identifier normalization/comparison mismatch described above: the enrollment API response returns the bare user id, while the selected/token account user id uses the combined user_id__account_id shape. Codex then rejects the enrollment before the browser authorization flow opens.

JiehoonKwak · 2 months ago

same issue. it seems no user-side workaround so far

damudao · 2 months ago

Experiencing the same here. Very similar setup to posters above.

Tile124 · 2 months ago

Same issue here.
Additionally I started experiencing weird web ChatGPT issues today. Multiple 404 and 403 errors related to shared Project files/images and even billing. Is there some kind of account identity/object auth issue that is related to this?

rosswaycaster · 2 months ago

I’m seeing this too on Codex 26.513.20950 on macOS.

The UI shows the same toast after clicking Authorize on chatgpt.com:

Failed to authorize remote control

I checked the local Codex logs and found the underlying failure:

remote_control_client_enrollment_start_account_mismatch
remote_control_authorize_failed errorMessage="Remote control enrollment start does not match current account."

So it looks like the remote-control enrollment response account/user id is not matching the currently selected Codex account context. This happens before the browser authorization page opens.

qimiaoguo · 2 months ago

I have the same issue, after I revoke the chatgpt codex auth

elhean · 2 months ago

I can reproduce what looks like the same issue, with one extra detail: mobile remote control works, while desktop-to-desktop remote-control authorization fails.

Setup

Two macOS machines, both signed into the same ChatGPT Personal account/workspace:

MBP: arhitek, active roots under /Users/arhitek/Code/...
Studio Mac / Mac mini: dejantomka, active roots under /Users/dejantomka/Code/...

Versions on both machines:

codex --version
# codex-cli 0.130.0

/Applications/Codex.app/Contents/Resources/codex --version
# codex-cli 0.131.0-alpha.9

Connection matrix

iPhone → MBP Codex Desktop: works
iPhone → Studio Codex Desktop: works
MBP Codex Desktop → Studio remote-control authorization: fails
Studio Codex Desktop → MBP remote-control authorization: fails
MBP ↔ Studio SSH remote projects: work

So this does not appear to be a general mobile remote-control failure, and it does not appear to be an SSH remote project issue. It seems specific to desktop-to-desktop remote-control enrollment/account matching.

Failing flow

In Codex Desktop:

Settings → Connections → Control other devices → Authorize on chatgpt.com

Actual result:

failed to authorize remote control

The error appears immediately as a red toast inside Codex Desktop. The browser does not open.

Expected result: Codex Desktop should start the remote-control authorization flow and enroll the other desktop host.

SSH remote project status

SSH remote projects work in both directions.

One SSH issue did appear initially: Studio → MBP could not find codex because non-interactive SSH on the MBP did not include /opt/homebrew/bin in PATH.

I fixed that on the MBP with a minimal ~/.zshenv:

export PATH="/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:$PATH"

After that, this works from Studio:

ssh mbp 'echo "PATH=$PATH"; command -v codex; codex --version'

Output:

PATH=/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
/opt/homebrew/bin/codex
codex-cli 0.130.0

After this PATH fix, the Studio → MBP SSH remote project connection updated successfully.

Troubleshooting already tried

Confirmed both Codex Desktop apps are signed into the same ChatGPT account
Confirmed both are using the Personal workspace
Signed out and signed back in to Codex Desktop on both machines
Fully quit and reopened Codex Desktop on both machines
Ran this on both machines:

pkill -f Codex 2>/dev/null || true
pkill -f "codex app-server" 2>/dev/null || true

Reopened Codex Desktop and retried remote-control authorization
Same error still occurs in both directions

Relevant log lines

After reproducing the error, I checked:

~/Library/Logs/com.openai.codex/...

Relevant redacted lines:

remote_control_client_enrollment_start_request hasExistingEnrollment=false ...
remote_control_client_enrollment_start_response hasExistingEnrollment=false ...
remote_control_client_enrollment_start_account_mismatch ...
remote_control_authorize_failed errorMessage="Remote control enrollment start does not match current account."

Key error:

Remote control enrollment start does not match current account.

There are also repeated nearby feature sync errors:

unsupported feature enablement `auth_elicitation`: currently supported features are apps, memories, mentions_v2, plugins, remote_control, tool_search, tool_suggest, tool_call_mcp_elicitation

and similar variants without mentions_v2.

Question

Could this be a desktop-to-desktop remote-control enrollment bug?

The important distinction is:

mobile/iPhone remote control to both desktop hosts works
SSH remote projects work
only Codex Desktop → Control other devices → Authorize fails, in both directions, before the browser opens

Is there a safe local state reset/workaround for this? I would prefer not to delete the entire ~/.codex directory because it contains sessions, history, logs, and local Codex state.

If a reset is needed, which files are safe to remove/regenerate? For example, is it safe to reset only:

~/.codex/.codex-global-state.json
~/.codex/.codex-global-state.json.bak

or is there another specific remote-control enrollment/cache file that should be cleared?

jackshiung · 2 months ago

I’m seeing the same issue on two Macs.

Plan: ChatGPT Pro
Codex App: 26.513.20950
Codex CLI: 0.130.0
Platform: macOS / Apple Silicon

Both machines show:

codex features list | grep remote_control
remote_control under development false

Codex App shows:
Failed to authorize remote control

Relevant logs:

remote_control_authorize_failed
Remote control enrollment start does not match current account.
remote_control_client_enrollment_start_account_mismatch

This happens after updating Codex, signing out/in, and using the same ChatGPT Pro account on both machines.

arnasjag · 2 months ago

Same issue. no way to bypass it

arthurhjorth · 2 months ago

Same. I can remotely control from iPhone to Mac, but cannot control from Mac to Mac. Tested between macbook pro m4, mac studio m2, mac studio m3. I'm on MacOS 26.5 on all.

eba8 · 2 months ago

Eagerly waited for the Connections tab to appear and now also facing the same issue :(

MalikElate · 2 months ago

following - having the same issue

dionysuzx · 2 months ago

same issue here

UtkuDalmaz · 2 months ago

same issue

Dknightsure · 2 months ago

same issue

saidmukhamad · 2 months ago

Same issue, can reproduce on 2 machines, mac 2 mac

kyleh · 2 months ago

I’m hitting the same issue on two Macs.

Codex version: 26.513.20950
Both Macs are signed into the same OpenAI account
Both Macs are using the same ChatGPT workspace
Mobile remote control works on both Macs
SSH/Tailscale is already configured and working
Dotfiles are not sharing Codex local state/auth/device files

Flow that fails:

Settings → Connections
Control other devices
Set up
Authorize on chatgpt.com

Result:

Codex immediately shows “Failed to authorize remote control” and never opens a browser.

Relevant log line:

remote_control_client_enrollment_start_account_mismatch

The logs appear to show Codex gets an enrollment response, then rejects it locally as an account mismatch even though the selected account/workspace is the same on both machines.

starsingchow · 2 months ago

same issue here

ghkdqhrbals · 2 months ago

Same here.

Also, once you set up the mobile device and remove the mobile ACL, there’s no way to reconnect it.

HeroOfOdyssey · 2 months ago

Same issue here. On iPhone I can see the remote environment (Ubuntu using experimental remote-control mode) and chat with it (although with unrelated issues related to authorizations/approvals for actions). When I first set it up, the remote host was showing on my mac but no longer does after a couple minutes and a codex restart

noclascio · 2 months ago

Same issue. Can connect through the ios app but not through another macos codex app. So many bugs.

BIGWOO · 2 months ago

I can reproduce this as a high-severity blocker on the same ChatGPT account, and I want to add a stronger impact signal here because this is not just a minor remote-connection inconvenience.

This feature worked once for me yesterday: I was able to set up mobile access to a local Codex App host. Shortly afterward it became disconnected, and since then I have been unable to authorize remote control again. The same ChatGPT account now fails with the same behavior on another computer as well, so this does not look like one corrupted local Codex profile.

This is a serious adoption blocker for me. I am trying to teach coworkers and students how to use Codex remote workflows, but the current failure mode makes the feature unusable and very hard to explain or recommend. From a user perspective, the setup flow presents itself as available, then fails with a generic authorization error. There is no recovery path in the UI, no clear way to reset the broken server-side enrollment, and repeated sign-out/sign-in attempts do not fix it.

Environment from one affected Mac:

Codex Desktop: 26.513.20950
CFBundleVersion: 2816
Bundled CLI: codex-cli 0.131.0-alpha.9
Homebrew CLI: codex-cli 0.130.0
macOS: 26.5 (25F71)
Darwin: 25.5.0 arm64
Auth mode: ChatGPT login

What I tried:

- Signed out of Codex App, signed back in
- Signed out of ChatGPT Web, signed back in
- Confirmed the same ChatGPT account/workspace is selected
- Fully restarted Codex App
- Enabled the documented/known feature flag:

  [features]
  remote_connections = true

- Retried setup from Settings -> Connections -> Control other devices -> Set up
- Reproduced the same issue on another computer with the same ChatGPT account

Current behavior:

Codex App shows:
Failed to authorize remote control

The latest local log attempt on this Mac was around:

2026-05-16 09:43:19 Asia/Taipei

Redacted log sequence:

remote_control_client_enrollment_start_request hasExistingEnrollment=false ...
remote_control_client_enrollment_start_response hasExistingEnrollment=false ...
remote_control_client_enrollment_start_account_mismatch ...
remote_control_authorize_failed errorMessage="Remote control enrollment start does not match current account."

The important comparison from the same attempt:

hasExistingEnrollment: false
headerChatGptAccountId == tokenAccountId: true
selectedAccountUserId == tokenAccountUserId: true
responseAccountUserId == tokenAccountUserId: false
responseAccountUserId == tokenAuthUserId: true
localEnrollmentAccountUserId: null
localEnrollmentClientId: null

That strongly suggests the enrollment start response is returning the bare auth user id, while the desktop client expects the account-scoped chatgpt_account_user_id form. The app then rejects the enrollment response even though the account id itself matches and the response appears to refer to the same underlying user.

I also checked the local remote-control state after cleanup/re-login. These keys were absent, so there does not appear to be an old local client enrollment to refresh or delete:

electron-local-remote-control-installation-id: absent
electron-local-remote-control-environment-id: absent
codex-mobile-has-connected-device: absent
remote-project-connection-backfill-completed: absent
electron-remote-control-client-enrollments: absent
added-remote-control-env-ids: absent

At the same time, Codex still refreshes a remote-control environment and reports one disconnected connection:

refresh_remote_control_completed autoConnectConnectionCount=0 nextConnectionCount=1 previousConnectionCount=0
remote_connections.manager_state_set hostId=remote-control:<redacted> nextState=disconnected

So from the outside this looks like:

1. Remote-control setup/enrollment succeeded once.
2. The remote-control environment later became disconnected.
3. The local state can be cleaned and auth can be refreshed successfully.
4. Re-authorization still fails because the server/client account-user-id representation does not line up.
5. The same account can reproduce the issue across multiple computers.

Please prioritize this. Remote control is a core workflow for using Codex across machines and for teaching teams how to adopt Codex. Right now the feature can enter a broken account/enrollment state with no user-visible recovery path and no reliable workaround. If there is a safe server-side reset or a specific local state reset that users should perform, please document it clearly; otherwise this looks like it needs a client/server fix for the account user id comparison or the enrollment response shape.

MerijnRaaijmakers · 2 months ago

I've just gotten the Version 26.513.31313 (2867) and this issue seems to be resolved!

xiamx · 2 months ago

the latest update resolved the issue for me Version 26.513.31313 (2867)

noctilust · 2 months ago

Verified the fix in Version 26.513.31313 (2867)

christophervankammen · 1 month ago

I am still having issues with this to this day. I have no restrictions I can find nor company restrictions (these are my own personal devices) can't find any reason for it

HeroOfOdyssey · 1 month ago

What version of the app are you on and what platform, and same for remote host? also did you try logging out and logging back in completely? @christophervankammen

I am still having issues with this to this day. I have no restrictions I can find nor company restrictions (these are my own personal devices) can't find any reason for it

ashe0047 · 1 month ago

I am on Codex App 26.519.81530 (3178) MacOS and i am still facing this issue as well today

paulomu · 1 month ago

I'm also having this issue on Codex 26.519.81530 (3178) for macOS.

CHENXCHEN · 1 month ago

also having this issue on Codex 26.519.81530 (3178) from macOS, Pro Plan

maximusrus · 1 month ago

The same issue Version 26.601.21317

RobbeAaltra · 1 month ago

Same for Version 26.602.30954

virgilshelton · 1 month ago

Same for Version 26.602.30954

Solved: Looks like Codex pairing requires MFA. On your iPhone, install Google Authenticator, then go to your ChatGPT/OpenAI account Security settings and turn on Two-Factor Authentication. Scan the QR code with Google Authenticator, save the backup codes, then sign out and back into Codex and try pairing again. It only takes a couple of minutes.

ashe0047 · 1 month ago

> Same for Version 26.602.30954 Solved: Looks like Codex pairing requires MFA. On your iPhone, install Google Authenticator, then go to your ChatGPT/OpenAI account Security settings and turn on Two-Factor Authentication. Scan the QR code with Google Authenticator, save the backup codes, then sign out and back into Codex and try pairing again. It only takes a couple of minutes.

Didnt work, still the same for me even after setting up MFA and relogin

cantonalex · 28 days ago

this is still happening on intel macs

Udo · 4 days ago

Still happening on both Intel and AS Macs