[macOS][Remote Control] Auto-update leaves selected host pointing to a stale environment ID

Summary

After the ChatGPT desktop app auto-updated on macOS from 26.727.51351 to 26.903.61454, Remote Control could no longer connect to this Mac. The persisted selected remote-control host ID did not match the desktop app's current local remote-control environment ID, and the selected host's cached thread list was empty.

Pairing and local execution had worked before the update: mobile-originated Codex tasks were confirmed to run on this Mac rather than in the cloud.

Environment

• ChatGPT desktop app: 26.903.61454 (build 8378)
• Previous desktop app version: 26.727.51351
• Host: macOS 26.6.2 (build 25G83), arm64
• Update observed: 2026-09-10 05:32 JST
• Remote client: ChatGPT mobile Remote

Observed state

Immediately after the automatic update and restart, the persisted global state contained two different environment IDs:

selected-remote-host-id = remote-control:<stale-environment-id>  # suffix 0bcc
electron-local-remote-control-environment-id = <current-environment-id>  # suffix 21b4

The identifiers are intentionally redacted. The selected host's thread-list cache was an empty array. The app was therefore looking at an older host/environment instead of the current local Remote Control environment.

A newly created task became accessible later, but the two persisted IDs remain inconsistent in the current state file.

Steps to reproduce / observed sequence

1. Pair ChatGPT mobile Remote with a Mac running the ChatGPT desktop app.
2. Start Codex tasks from mobile and confirm they execute on the paired Mac.
3. Allow the desktop app to auto-update and restart.
4. Try to reconnect from mobile.
5. Inspect the desktop global state.
6. Observe that selected-remote-host-id references a different environment than electron-local-remote-control-environment-id, while the selected host thread-list cache is empty.

This was observed across an automatic update; I do not yet have a deterministic way to trigger an app update on demand.

Expected behavior

After an app update, Codex should preserve or refresh the local Remote Control environment identity and reconcile the selected host. If the selected environment no longer exists, the app should clear or migrate the stale selection instead of silently showing an empty host with no usable Remote connection.

Actual behavior

The local environment identity changed or was recreated, but the selected host continued to point at the older environment. Restarting the updated app did not reconcile the two IDs.

Related issues

• #38015 reports host context being restored incorrectly after an app update, but involves a remote SSH host and hidden local pins.
• #23112 reports stale local Remote Control enrollment/environment IDs after revocation, rather than after an automatic update.
• #30329 reports restoration of a stale Remote Control host on Windows.

This report is specifically about a macOS desktop auto-update leaving selected-remote-host-id inconsistent with the current electron-local-remote-control-environment-id.

I can provide redacted state excerpts and relevant app-log records privately. I am not attaching raw logs because they contain local paths, prompts, and other potentially sensitive data.

Start by tracing how the persisted selected-remote-host-id and electron-local-remote-control-environment-id are restored across an auto-update and restart. Use the reported pairing and update sequence, then inspect the resulting global state and selected host thread-list cache. Done means the selected host is reconciled with the current local environment, or a stale selection is cleared or migrated instead of showing an unusable empty host.