Codex remote-control pairing reuses cloned Mac installation_id and steals another host's connection

Summary

When a Mac has been cloned/migrated from another Mac, Codex/ChatGPT Desktop can reuse the original machine's remote-control identity instead of creating a new host. The iPhone ChatGPT app then shows the new Mac under the old Mac label/connection and effectively steals the old host's connection.

Observed on macOS with ChatGPT Desktop/Codex:

• Source machine: MBP64
• Cloned/current machine: MBP16
• Current host name: Alans-MacBook-Pro-16.local
• Pairing UI/display still reused the MBP64 connection/display name
• Local app-server logs previously showed remote-control collision behavior, including the old server/env being reused

Root Cause Found Locally

The durable source was ~/.codex/installation_id, which still contained the original MBP64 installation UUID after the machine clone/migration.

Clearing only these did not work because Codex recreated the same remote-control environment from the old installation ID:

• ~/.codex/.codex-global-state.json keys:
• electron-local-remote-control-installation-id
• electron-local-remote-control-environment-id
• electron-remote-control-client-enrollments
• added-remote-control-env-ids
• ~/.codex/state_5.sqlite table:
• remote_control_enrollments row for app_server_client_name = 'Codex Desktop'

The identity only changed after also rotating ~/.codex/installation_id.

Local Fix That Worked

1. Quit ChatGPT Desktop.
2. Back up ~/.codex/.codex-global-state.json, .bak, ~/.codex/installation_id, and ~/.codex/state_5.sqlite*.
3. Replace ~/.codex/installation_id with a fresh UUID.
4. Delete the local global-state keys listed above.
5. Delete the remote_control_enrollments row where app_server_client_name = 'Codex Desktop'.
6. Reopen ChatGPT Desktop.

After this, the desktop enrollment changed from the old cloned environment to a new environment for Alans-MacBook-Pro-16.local.

Expected Behavior

Codex/ChatGPT Desktop should detect cloned or migrated installations and avoid reusing another physical Mac's remote-control identity. Pairing from iOS should create a distinct host record for the new Mac instead of updating/replacing the previous Mac's record.

Suggested Product Fix

One or more of:

• Include a local machine-specific factor in remote-control identity derivation or validation.
• Detect when ~/.codex/installation_id is reused on a different macOS host/hardware identity and prompt/regenerate.
• Add a UI action to reset the local remote-control pairing identity without wiping chats/workspaces.
• During iOS pairing, warn if an existing remote-control host has the same installation identity but a different hostname/hardware context.

Notes

I avoided posting full raw IDs here, but the pattern was clear: the old installation UUID persisted in ~/.codex/installation_id, and the remote-control environment/server IDs were regenerated from it until that file was rotated.