Codex Desktop remote control remains connected but unusable after remote device revoked permission, and cannot be deleted or re-authorized

Body:
I have two Codex Desktop/App Server devices signed into the same ChatGPT account.

Device A: macOS 26.4.1, Codex Desktop 26.513.31313, bundled codex-cli 0.131.0-alpha.9
Device B: gaoshaoyudeMac-Studio.local, app-server 0.131.0-alpha.9

What happened:

Device A could previously control Device B from Settings > Connections > Control other devices.
On Device B, access/permission for Device A was revoked by mistake.
After that, Device A still shows Device B under “Devices you can control from this Mac” as connected/online.
Trying to connect no longer works.
The UI does not allow me to delete Device B because the remote-control environment is still reported as online.
I also cannot force a clean re-authorization flow from Device A.

Observed diagnostics:

GET /codex/remote/control/environments returns Device B as online: true.
Device B appears as client_type CODEX_CLI / CODEX_DESKTOP_APP app-server 0.131.0-alpha.9 depending on the environment.
Local state contains selected-remote-host-id and added-remote-control-env-ids for the stale remote-control environment.
Clearing local state did not resolve the problem, so I restored it.

Expected behavior:
After a remote device revokes controller permission, the controlling Codex app should either:

show that access is revoked and provide a re-authorize flow, or
allow removing the stale remote-control device locally, even if the remote environment is still online.

Actual behavior:
The device remains shown as connected/online, but control does not work, and there is no apparent way to delete or re-authorize it from the UI.

Please advise whether there is a supported command or UI flow to revoke/reset a remote-control client enrollment and re-authorize the device pair.

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

Revoked remote control access for a device, connections remain on ChatGPT mobile app without a way to delete, cannot pair again #22700
Codex mobile remote access can reuse revoked enrollment and connect to the wrong Mac #23339
Codex mobile Remote Control stale host cannot be removed and QR pairing fails #22714
Codex mobile stale Remote Control host cannot be removed after Mac hostname change / codex feedback : no-active-thread-019e3bc9-0329-7672-9add-4731a5fccc86 #23321
Codex android chatgpt Remote Control can only connect to windows codex app and cant switch to mac codex app #22765

Powered by Codex Action

I’m seeing the same failure mode.

After revoking one controller device from the target device, signing out/in and reinstalling Codex Desktop did not recover the relationship. The UI still shows the remote-control environment as available, but connecting fails.

The more specific Desktop log error I found was:

Remote-control client has been revoked

I also saw the client trying to refresh an existing enrollment before failing, roughly in this pattern:

remote_control_client_refresh_start_request hasExistingEnrollment=true
app_server_connection.transport_connect_failed ... "Remote-control client has been revoked"

Update: the workaround below does not appear to be effective on newer versions. It may only apply to older Codex Desktop versions, so please treat it as version-specific context rather than a current fix.

For older Codex Desktop versions on macOS, the workaround was to fully quit Codex Desktop first, then clear the persisted remote-control enrollment state:

cd ~/.codex

jq 'del(."electron-remote-control-client-enrollments",
        ."added-remote-control-env-ids",
        ."electron-local-remote-control-environment-id",
        ."electron-local-remote-control-installation-id")
| .["remote-projects"] |= map(select((.hostId // "") | startswith("remote-control:") | not))
| .["remote-connection-auto-connect-by-host-id"] |= with_entries(select(.key | startswith("remote-control:") | not))' \
.codex-global-state.json > /tmp/codex-state.json && mv /tmp/codex-state.json .codex-global-state.json

cp .codex-global-state.json .codex-global-state.json.bak

sqlite3 state_5.sqlite 'delete from remote_control_enrollments;'

Then reopen Codex Desktop and re-enable/re-authorize Remote Control.

Local cleanup of .codex/.codex-global-state.json alone was not enough in my case because Codex could recreate or retain state. I also found related persisted state in .codex/state_5.sqlite, table remote_control_enrollments.

This looks like the app needs a supported “forget/re-authorize remote-control client” flow when the server says the client has been revoked, instead of treating the stale environment as online and continuing to reuse the revoked enrollment.

Have you tried it in the comments above? I’ve encountered this problem too, and the method mentioned above worked.

I am seeing what looks like the same remote-control state bug from the Codex Desktop app side.

Additional symptoms:

In Settings > Connections > Control other devices, a device can remain shown as connected even after turning its toggle off.
While it is still shown as connected, I cannot remove/delete that device from the UI.
The state seems especially fragile after switching between multiple accounts or re-binding/replacing remote-control connections.

Expected behavior: turning the toggle off or revoking access should move the device into a clear disconnected/revoked state and expose a supported way to remove it or re-authorize it.

Actual behavior: the UI can keep showing the stale device as connected, which blocks deletion and makes the remote connection state hard to recover without a supported reset flow.

I was able to recover from a very similar state and found a few details that may help narrow this down.

In my case, the server-side remote-control environments list no longer contained the old environment, but the Desktop app kept restoring the deleted/stale environment into ~/.codex/.codex-global-state.json after restart. The stale entry included an old added-remote-control-env-ids value, an old remote-connection-auto-connect-by-host-id entry, and old remote-projects.

A notable detail: state_5.sqlite had zero rows in remote_control_enrollments, so this can still happen even when that table is empty. The problematic persisted state was in .codex-global-state.json, especially the remote-control client enrollment and related remote host/project state.

Also, cleaning .codex-global-state.json while Codex Desktop was running did not stick. After restart, the stale remote environment was written back again. The recovery only worked after cleaning the file while Codex Desktop was fully stopped. In my case, a cleanup process launched from inside Codex was also terminated with the app, so I had to run the cleanup from outside the Codex process lifecycle.

The recovery path that worked was:

Fully quit Codex Desktop.
While Codex was not running, remove the stale remote-control state from .codex-global-state.json, including:
- electron-remote-control-client-enrollments
- stale added-remote-control-env-ids
- stale remote-connection-auto-connect-by-host-id
- stale remote-projects
- stale electron-local-remote-control-installation-id
Reopen Codex Desktop.
Re-enable/reconnect Remote Control.

After removing electron-remote-control-client-enrollments, Codex showed the ChatGPT first-time authorization flow again, and completing that authorization restored the connection.

This makes it look like the Desktop app can keep reusing a stale/revoked remote-control client enrollment instead of falling back to a fresh ChatGPT authorization flow. A supported “forget remote-control enrollment and re-authorize” action would likely avoid requiring manual state-file cleanup.

This issue now appears to have a workable recovery path.

Closing based on the confirmed workaround from the thread:

fully quit Codex Desktop
remove the stale remote-control state from ~/.codex/.codex-global-state.json
if needed, also clear the stale remote_control_enrollments state
reopen Codex Desktop and re-authorize Remote Control

Since this is now recoverable in practice, I’m closing this issue for now. If the problem still reproduces after following that cleanup flow on current versions, please reopen with the latest version details and logs.

This issue now appears to have a workable recovery path.

Closing based on the confirmed workaround from the thread:

fully quit Codex Desktop

remove the stale remote-control state from ~/.codex/.codex-global-state.json

if needed, also clear the stale remote_control_enrollments state

reopen Codex Desktop and re-authorize Remote Control

Since this is now recoverable in practice, I’m closing this issue for now. If the problem still reproduces after following that cleanup flow on current versions, please reopen with the latest version details and logs.

This solution will fully reset the codex, including removing the projects & history in the project. It's not elegent at all and I do advocate a proper RESET button in connection setting UI, to ONLY reset connections, nothing else.

If removing ~/.codex/.codex-global-state.json is the solution, well, the user could also rm -rf ~/.codex. This is not the point of this issue. I hope the issue can be re-opened and properly solved

This issue now appears to have a workable recovery path.
Closing based on the confirmed workaround from the thread:

fully quit Codex Desktop

remove the stale remote-control state from ~/.codex/.codex-global-state.json

if needed, also clear the stale remote_control_enrollments state

reopen Codex Desktop and re-authorize Remote Control

Since this is now recoverable in practice, I’m closing this issue for now. If the problem still reproduces after following that cleanup flow on current versions, please reopen with the latest version details and logs.

This solution will fully reset the codex, including removing the projects & history in the project. It's not elegent at all and I do advocate a proper RESET button in connection setting UI, to ONLY reset connections, nothing else.

If removing ~/.codex/.codex-global-state.json is the solution, well, the user could also rm -rf ~/.codex. This is not the point of this issue. I hope the issue can be re-opened and properly solved

I don't think they meant removing the .json file completely, only those keys mentioned.

This is still an issue, I'm encountering it now.

Because there is a super hacky manual workaround does not mean the issue is closed.

This particularly occurs if you switch ChatGPT accounts, where the first account had Remote Control set up, and the second account hasn't.

Navigation Menu

Repository navigation

Codex Desktop remote control remains connected but unusable after remote device revoked permission, and cannot be deleted or re-authorized #23865

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Codex Desktop remote control remains connected but unusable after remote device revoked permission, and cannot be deleted or re-authorized #23865

Description

Activity

github-actions commented on May 21, 2026

Sakura125809 commented on May 22, 2026

Sakura125809 commented on May 24, 2026

masayuki-akinari commented on May 25, 2026

masayuki-akinari commented on May 26, 2026

CarryJone commented on May 27, 2026

Tian99Yu commented on Jun 7, 2026

outie commented on Jun 9, 2026

mapleroyal commented on Jun 13, 2026

jacksonhvisuals commented on Aug 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions