›_ Codex Issues
Codex Issues / #32882

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

Open 💬 2 comments Opened Jul 13, 2026 by DEVLlN

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.

View original on GitHub ↗

2 Comments

DEVLlN · 1 month ago

Additional root-cause evidence from Codex Desktop 26.707.62119:

  1. The manual-pair claim succeeds and returns an environment_id.
  2. The controller refresh then remains empty (previousConnectionCount=0 nextConnectionCount=0) for minutes.
  3. The renderer ignores whether the claimed environment appeared in that refresh and immediately enables auto-connect for remote-control:<environment_id>.
  4. Main persists the auto-connect flag before validating/materializing the host. It also selects which catalog to refresh by current catalog membership, so an unknown remote-control: host falls through to the SSH refresh path.
  5. The resulting status/connect calls fail with Connection for host ID ... not found / Remote connection for host ID ... not found.

This failure is in the shipped Electron desktop layer. The public Rust app-server remoteControl/status/read handler reads only the local server status and does not accept a host ID.

There is also a deterministic way for the controller catalog to become empty after a successful pair: the shipped desktop self-filter drops every environment whose installation_id equals the controller's local installation ID, even when the environment IDs differ. The authoritative ID is persisted in ~/.codex/installation_id; public resolve_installation_id accepts and reuses any valid UUID, with no clone/collision detection. A Mac migrated or cloned from another Mac can therefore silently filter that other Mac as “self.” I am checking whether the two machines in this report share that ID; this should be covered regardless.

Suggested desktop fix:

  • After claim, require the client-scoped refresh result to contain the returned environment before creating a manager or changing auto-connect.
  • Classify remote-control: host IDs by namespace/type, not current catalog membership.
  • Commit auto-connect only after successful materialization, and restore the previous value on failure.
  • For self-filtering, prefer exact local env_id; use installation_id only when no local environment ID is available. Do not drop a different env_id solely because an installation ID matches.
  • Surface a typed “duplicate installation identity” / “pair grant not materialized” error instead of the generic update failure.

Regression cases:

  • claim succeeds + client-scoped refresh omits environment;
  • two distinct environment IDs share one migrated installation ID;
  • unknown remote-control: host never refreshes the SSH catalog;
  • failed auto-connect leaves no persisted true value.

Related reports with the same Mac-to-Mac pattern: #26193, #27231, and the July 13 controller log in #23915.

DEVLlN · 1 month ago

Confirmed on the affected pair: both Macs' authoritative ~/.codex/installation_id values have the same SHA-256 hash. The controller's requested host environment is the Mac mini's exact local environment ID.

This makes the duplicate-installation path deterministic for this report: the client-scoped API can return the mini, but the desktop self-filter removes it because its installation_id equals the MacBook's local value. The post-filter catalog remains at zero, and the unconditional auto-connect path then produces the reported host-not-found error.

The machines are distinct hardware (Intel MacBook Pro controller and Apple Silicon Mac mini host), consistent with a migrated/copied Codex home. Rotating only the controller MacBook's ~/.codex/installation_id while all Codex/ChatGPT processes are stopped is the local recovery; the product fix should still change self-filtering to prefer exact environment ID and avoid excluding a different environment solely because the persisted installation UUID matches.