Codex App 26.519.22136: Remote Control setup authenticates but shows no devices

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

• #23865
• #22763
• #22804
• #22810

Powered by Codex Action

Follow-up after additional local repair attempts:

• Installed the official standalone Codex package required by codex app-server daemon restart.
• Before install, daemon restart failed because ~/.codex/packages/standalone/current/codex was missing.
• After install, standalone Codex is 0.133.0, codex doctor reports the runtime as standalone and the background app-server as running in persistent mode.
• Re-ran codex app-server daemon enable-remote-control; it now reports remoteControlEnabled: true.
• Backed up local global state and removed only the desktop controller enrollment key, electron-remote-control-client-enrollments, to force a fresh controller enrollment.

Current remaining symptom:

• The desktop app still has the saved remote host/project entries locally.
• The active desktop window continues retrying saved remote-control:env_* hosts.
• Each remote host still fails with Remote control enrollment requires explicit authorization in settings.
• The app also continues logging unsupported feature enablement auth_elicitation.

Interpretation:

The Mac now has the required standalone daemon and local remote-control authorization enabled, so the remaining failure appears to be either:

1. stale controller enrollment state that requires a full desktop app restart and fresh setup, or
2. each remote host's app-server requiring the same standalone install plus codex app-server daemon enable-remote-control / restart on the host side, or
3. an app-side regression where the desktop controller auth path succeeds but cannot list or authorize the already working remote devices.

Second follow-up with screenshot/retry result:

• User retried setup after standalone install, local daemon enablement, controller-enrollment reset, and desktop restart.
• UI now shows Remote control authorized, confirming Mac/controller enrollment succeeds.
• The Add Device modal still says No signed-in devices available.
• New logs show a fresh controller enrollment was created successfully:
• hasExistingEnrollment=false
• remote_control_client_enrollment_finish_response
• scopes=["remote_control_controller_websocket"]
• Immediately afterward the app logs:
• refresh_remote_control_completed
• autoConnectConnectionCount=4
• nextConnectionCount=4
• shared_object_synced connectionCount=4
• Those four known remote-control:env_* connections then each fail with:
• Remote control enrollment requires explicit authorization in settings.

Current interpretation:

The Mac/controller-side setup now succeeds. The app appears to know about the existing four remote-control connections, so the empty Add Device picker may simply have no additional devices to add. The remaining blocker is that each existing remote host refuses the controller connection because remote control is not explicitly authorized on the host side, or the Mac app is applying a newer authorization gate that the host-side app-server state does not satisfy.

Likely required repair:

Each remote host needs the standalone Codex package installed/updated and remote control explicitly enabled/restarted on that host:

curl -fsSL https://chatgpt.com/codex/install.sh | sh
~/.codex/packages/standalone/current/codex app-server daemon enable-remote-control
~/.codex/packages/standalone/current/codex app-server daemon restart

Third follow-up with root cause narrowed to the desktop controller enrollment cache key:

I inspected the updated Codex Desktop bundle and correlated it with the local logs/state. The failure is not that the Mac authorization flow fails; it succeeds. The bug appears to be that the authorized controller enrollment is persisted under one account-user-id form, but the remote connection path looks it up under the other form.

Observed flow:

1. remote_control_client_enrollment_start_request uses the qualified account-user id from the token:

``text
tokenAccountUserId=user-<redacted>__<account_id>
tokenAuthUserId=user-<redacted>
headerChatGptAccountId=<account_id>
``

1. remote_control_client_enrollment_start_response and finish_response return the unqualified user id:

``text
responseAccountUserId=user-<redacted>
accountUserId=user-<redacted>
scopes=["remote_control_controller_websocket"]
``

1. The desktop code explicitly allows that mismatch when the ChatGPT account id matches, but then stores the enrollment under the response/unqualified id. The later no-step-up remote connection path first looks up by the token/qualified id. Because that key is missing, it throws:

``text
Remote control enrollment requires explicit authorization in settings.
``

1. The Add Device modal then says No signed-in devices available, but the app logs show the known remote-control connections still exist:

``text
refresh_remote_control_completed autoConnectConnectionCount=4 nextConnectionCount=4 previousConnectionCount=4
shared_object_synced connectionCount=4
``

Local workaround validated at the state-file level:

I backed up ~/.codex/.codex-global-state.json and duplicated the existing electron-remote-control-client-enrollments entry under the qualified account-user-id key. This is expected to require a full Codex Desktop restart because the running Electron process may already have global state loaded in memory.

Proposed product fix:

When the enrollment start response account user id is accepted as equivalent to the token account user id via the account-id fallback, persist/alias the enrollment under both keys, or normalize to one canonical account-user-id before both read and write. The key invariant is: after the settings authorization flow succeeds, the reconnect path without a step-up callback must be able to find the same controller enrollment.

Yeah, also facing issues with RC!

I also pushed a public diagnostic branch from this investigation:
https://github.com/H-H-E/codex/tree/codex/doctor-remote-control-controller-diagnostic

Commit:
https://github.com/H-H-E/codex/commit/6967dbfc94

This adds a read-only codex doctor check for the Desktop controller-enrollment state that detects the empty signed-in-devices case found here: remote devices exist, a controller enrollment exists for the current ChatGPT user, but the selected account-user enrollment key is missing. It reports only redacted counts/booleans plus remediation.

I attempted to open a PR from the fork, but GitHub returned: H-H-E does not have the correct permissions to execute CreatePullRequest for this auth context.

Verification completed locally:

• /opt/homebrew/bin/cargo-fmt --all -- --check
• git diff --check
• CARGO_INCREMENTAL=0 CARGO_NET_GIT_FETCH_WITH_CLI=true RUSTFLAGS='-C debuginfo=0' /opt/homebrew/bin/cargo test -p codex-cli desktop_remote_control --bin codex
• CARGO_INCREMENTAL=0 CARGO_NET_GIT_FETCH_WITH_CLI=true RUSTFLAGS='-C debuginfo=0' /opt/homebrew/bin/cargo test -p codex-cli current_chatgpt_account_user_identity --bin codex

Maintainer-actionability follow-up after checking the related reports and contribution policy:

• This appears to be the same account-user-id representation bug class as #22763, #22804, and #22810, but still reproducible on 26.519.22136 (3003) with the newer symptom where setup succeeds and the Add Device picker is empty.
• #23922 independently reported the same post-update "auth succeeds, no signed-in devices available" behavior and was closed as a duplicate of this issue.
• The existing open remote-control/auth PR #23775 appears adjacent but not identical: it wakes/retries after auth recovery, while this issue is specifically that the controller enrollment is written under the unqualified user id and later looked up under the selected qualified account-user id.

I also noticed docs/contributing.md says external code contributions are by invitation only and that uninvited PRs are closed without review. I therefore pushed the diagnostic branch for review/cherry-pick rather than opening more noisy PR attempts:

https://github.com/H-H-E/codex/tree/codex/doctor-remote-control-controller-diagnostic

The branch is intentionally narrow and public:

• one read-only codex doctor check
• no tokens, raw ids, or private state in output
• detects the concrete state shape from this issue: existing remote env ids + controller enrollment for the current user + missing selected account-user key
• includes focused unit coverage for the qualified/unqualified key case and selected-account identity derivation

If this direction is useful, could a Codex maintainer either invite a PR from that branch or confirm the preferred implementation shape? For the actual product fix, my recommendation remains to make the Desktop enrollment read/write key invariant explicit: when the settings step-up accepts user-... and user-...__<account_id> as the same ChatGPT account context, persist/alias the controller enrollment under the same canonical account-user id that the no-step-up reconnect path will use.

having the same issue. the remote devices are available on my iPhone but not on my mac. Seems to be an issue with latest update.

EDIT--can't even connect from my phone anymore after updating server and redoing login thinking that would help

After updating to Desktop 26.519.31651 / build 3017, Mac Desktop now sees the other Mac.
Presence updates work: disabling discovery/control on the remote Mac immediately changes its status to offline, and enabling it changes it back to "Connected".
However the status dot remains gray rather than green, so the Mac cannot start controlling the other Mac.
Mobile can control both Macs successfully.

Having trouble connecting iOS to Codex via new ChatGPT desktop app.

GPT 5.5 wrote this for me to send:

I'm seeing what may be a related regression, but with the new integrated ChatGPT desktop app rather than the standalone Codex app. Environment: ChatGPT Desktop 26.707.31428 macOS Tahoe 26.5.1 ChatGPT iOS 1.2026.167 The iOS Codex onboarding instructs me to click "Set up remote control" in the desktop sidebar to obtain a pairing code. The current ChatGPT desktop app has no such sidebar item. There is no Remote, Remote Control, Devices, or pairing UI anywhere. Plugins only lists MCP plugins. Settings → Connections already shows my iPhone ("Last connected"), so the devices appear to know about each other, but iOS still requires a pairing code that cannot be generated. Is this the expected workflow for the new ChatGPT desktop app, or is the iOS onboarding still referencing the old standalone Codex UI?

I am still reproducing this issue with Mac-to-Mac Remote Control.

Environment:

• Two Apple Silicon Macs
• ChatGPT desktop app 26.707.41301, build 5103, on both Macs
• Same ChatGPT account and workspace on both devices
• The target Mac has Remote Control enabled
• An iPhone can control the same target Mac successfully

Troubleshooting already attempted:

• Updated both desktop apps to the same version
• Fully quit and restarted the app on both Macs, starting the target first
• Revoked the Mac controller on the target and paired it again with a newly generated code
• Removed only the stale controller-side Remote Control state after making a backup
• Repeated setup with both Macs awake and online
• Verified that the target's local state database passes SQLite quick_check

The controller enrollment itself completes successfully. The sanitized log sequence is:

remote_control_client_enrollment_start_request hasExistingEnrollment=false
remote_control_client_enrollment_key_created protectionClass=hardware_secure_enclave
remote_control_client_enrollment_step_up_validated
remote_control_client_enrollment_challenge_signed
remote_control_client_enrollment_finish_response
scopes=["remote_control_controller_websocket"]

However, immediately after the successful enrollment, the desktop app receives no remote connections:

refresh_remote_control_completed
autoConnectConnectionCount=0
nextConnectionCount=0
previousConnectionCount=0

When the app then attempts to use the target host, it fails with:

Connection for host ID remote-control:<redacted> not found
connect_toggle_failed

I also verified locally, without exposing the identifiers, that:

• The host ID requested by the controller matches the target Mac's active Remote Control enrollment.
• The ChatGPT account ID matches on both sides.
• The target enrollment is enabled.
• The target database is healthy.

This does not appear to be an MFA, account, workspace, version, network reachability, or corrupted-database problem. Authentication and controller enrollment finish successfully, but the macOS controller receives an empty host list. The same target remains accessible from iOS.

This looks consistent with the desktop controller/device-list synchronization problem described in this issue. Please let me know if a sanitized diagnostic bundle or additional redacted log lines would help.