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

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

• #22700
• #23339
• #22714
• #23321
• #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.

Same issue showing connected but saying "Failed to update connection".

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:

1. Fully quit Codex Desktop.
2. 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

1. Reopen Codex Desktop.
2. 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.