[macOS app] Desktop-to-desktop Remote pairing fails with “Failed to update connection” / host ID not found

Summary

Desktop-to-desktop Remote pairing fails immediately after entering a valid pairing code. The controlling Mac shows "Failed to update connection" and remains at "No devices added yet".

The host successfully starts pairing and returns an environment ID, but the controller then fails while enabling auto-connect because that host ID is not present in its refreshed connection registry.

Environment

• Host: Mac mini, Apple silicon, macOS 26.5.1
• Controller: Intel Core i9 MacBook Pro, x86_64
• Codex desktop version on both Macs: 26.707.62119
• Bundled Codex CLI: 0.144.2
• Same OpenAI account/workspace on both Macs
• Network reachability between Macs verified over Tailscale; the failure is immediate and occurs in the application registration flow

Steps to reproduce

1. On the host Mac, open Codex Settings → Connections → Control this Mac.
2. Choose Add Computer and obtain a new pairing code.
3. On the controller Mac, open Control other devices → Add.
4. Enter the fresh pairing code.
5. Observe the immediate error toast.

Expected behavior

The host should appear under Control other devices and become available for remote control.

Actual behavior

The controller immediately shows:

Failed to update connection

The device list remains:

No devices added yet

Sanitized controller logs show:

Request failed ... method=remoteControl/status/read ...
"Connection for host ID remote-control:env_e_<redacted> not found"

[remote-connections/settings] connect_toggle_failed autoConnect=true ...
"Remote connection for host ID remote-control:env_e_<redacted> not found"

The environment ID in that error matches the host Mac's local environment ID.

Host-side logs show remoteControl/enable and pairing/start succeeding, followed by repeated client-list polling, but no completed client registration.

Troubleshooting already performed

• Generated and entered multiple fresh pairing codes.
• Confirmed both Macs run the exact same Codex desktop build.
• Confirmed both Macs use the same OpenAI account/workspace.
• Removed the selected remote-host preference and retried.
• Signed out and back in on the controller.
• Quarantined the controller's complete Codex global state, backup state, and auth state; completed fresh onboarding and login; reproduced again.
• Restarted the app after a transient black screen during the clean-state test.
• Verified the host's Remote service remains enabled and healthy.
• Previously, before revoking access, this host had listed the Intel controller as "Mac OS x64 — Last connected ...", so x86_64 controller support had worked in this same setup.

Possible implementation clue

This is an inference from inspecting the shipped app bundle, not a confirmed root cause: the manual-pairing success path appears to refresh the connection list and then immediately enable auto-connect for the returned environment ID. If the refresh does not materialize that host in the local registry, the subsequent status/read call fails with the exact "host ID ... not found" error above.

Please let me know if maintainers want a narrowly filtered diagnostic bundle; raw logs were intentionally not attached because they may contain account/session metadata.

Confirmed root cause and verified recovery

Both Macs had the same authoritative ~/.codex/installation_id value. They are physically distinct machines, but the desktop controller's self-filter discarded the Mac mini environment solely because its installation_id matched the MacBook's local value, even though their environment IDs differed.

This explains the full observed sequence:

1. Pair claim succeeds and returns the Mac mini's environment ID.
2. The client-scoped connection list is loaded.
3. The Mac mini is removed by the controller's installation-ID self-filter.
4. The post-filter catalog remains empty.
5. The renderer still enables auto-connect for the returned environment.
6. The missing registry entry produces the immediate host-ID-not-found error.

The duplicate ID was consistent with migrated/copied Codex state rather than an Intel architecture limitation.

Recovery performed

1. Fully quit Codex/ChatGPT on the controller MacBook.
2. Moved the MacBook's ~/.codex/installation_id to a timestamped backup.
3. Relaunched Codex so the public resolve_installation_id path generated a new UUID.
4. Left the Mac mini's identity and host enrollment unchanged.
5. Retried the native Remote Control connection.

Verification

The MacBook connected successfully through native Remote Control. The Mac mini appeared as a connected host, and the already-running task on the Mac mini was opened and controlled from the MacBook Codex app. The temporary SSH connection was removed and was not required.

The issue should remain open because rotating the copied identity is a local recovery, not a product fix. Desktop should prefer exact environment-ID matching for self-filtering and must not silently discard a different environment solely because a persisted installation UUID matches. The post-claim flow should also avoid committing auto-connect until the claimed environment has materialized.