Codex Mobile restores stale revoked Mac connection and fails with 403

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

• #23078
• #22700
• #22714
• #23110
• #22773

Powered by Codex Action

Possibly related to #23110.

One extra detail that may help triage: this does not look like only a local Desktop cache issue. After clearing local Desktop remote/mobile state, Codex Desktop generated a new local environment_id, but the iPhone still restored the stale old Mac connection.

Expected behavior:

• Revoking the iPhone from Codex Desktop should remove or invalidate the mobile-side connection.
• The iPhone app should expose a way to remove/reset a stale Desktop connection.
• Scanning a new QR code should either create a new working pairing or show an explicit error.

Additional information:

• The stale connection is partially restored: the iPhone can list chats from the old Mac connection, but opening any thread fails with 403.
• Deleting and reinstalling the iPhone app with “Delete App” did not clear the stale connection.

I tried this gist: https://gist.github.com/sirmalloc/fefef0b65729d9644794a3c67d1a28b9

but every time I open codex desktop it recreates the deleted session.

Had the same problem, need a clean unbind&rebind logic when have connection problems at least.

The detail that Desktop generated a new local environment_id while iPhone restored the old Mac connection is the key discriminator here.

That suggests the stale state may not be only a Desktop local-cache issue. There may be an account-side or mobile-side association that survives local reset and wins over the newly generated desktop environment.

I would try to capture which identity appears in the failing 403 path:

• old environment / connection id that was supposed to be revoked;
• new environment id generated after Desktop reset;
• mobile-side device/client id after reinstall;
• request id from the failed message-load call.

If the 403 references the old connection, the fix is likely clean unbind/rebind with a tombstone or generation counter so mobile cannot resurrect revoked hosts. If it references the new environment, the problem is closer to auth/permission propagation for the fresh pairing.

The detail that Desktop generated a new local environment_id while iPhone restored the old Mac connection is the key discriminator here. That suggests the stale state may not be only a Desktop local-cache issue. There may be an account-side or mobile-side association that survives local reset and wins over the newly generated desktop environment. I would try to capture which identity appears in the failing 403 path: old environment / connection id that was supposed to be revoked; new environment id generated after Desktop reset; mobile-side device/client id after reinstall; request id from the failed message-load call. If the 403 references the old connection, the fix is likely clean unbind/rebind with a tombstone or generation counter so mobile cannot resurrect revoked hosts. If it references the new environment, the problem is closer to auth/permission propagation for the fresh pairing.

Thanks for the clarification! The issue was resolved by:

1. Revoking device access for the Codex app
2. Deleting the remote environment
3. Reinstalling the ChatGPT app

Adding another data point because I think I’m hitting the same class of issue, though my setup is Mac Codex app -> Windows Codex Desktop instead of iPhone -> Mac.

In my case this did not start as a normal Windows/Mac networking problem. The Windows host was still able to reach chatgpt.com, remote control showed Connected, and the Windows remote_control_enrollments row kept refreshing with new environment/server ids. But the Mac client either failed to connect or appeared to use stale state before it ever reached the Windows host cleanly.

The sequence that seemed to make it worse:

1. Mac had a saved Windows host connection.
2. Remote file browsing started acting odd: folder tree showed, but files would not load.
3. I removed the connection on the Mac.
4. It did not clearly disappear on the Windows side, so I revoked it from Windows.
5. After that, trying to add/reconnect kept failing or behaving inconsistently.

The interesting part: Windows logs showed the host enrollment continuing to refresh, but Mac-side state still had stale remote-control environment ids in ~/.codex/.codex-global-state.json. The selected remote host id and auto-connect entries pointed at older remote-control:env_... values, while Windows had already rotated to a newer environment id. So the client looked like it was trying to restore or target stale remote-control state instead of creating a clean new connection.

This makes me think the root issue may be stale remote-control auth/enrollment state after revoke, not a platform-specific Windows/Mac problem. It would be helpful if Codex exposed a supported way to clear stale remote hosts / revoked remote-control enrollments without deleting the whole .codex folder or risking local sessions.