Opening reattached remote threads after host re-enrollment restarts Codex Desktop

What version of the Codex App are you using (From “About Codex” dialog)?

26.810.52044 (build 6662); bundled codex-cli 0.148.0-alpha.9

What subscription do you have?

Unknown. The controller was signed into a ChatGPT account with available Codex usage.

What platform is your computer?

Controller: Darwin 24.6.0 arm64 arm

Remote host: Apple-silicon Mac mini, macOS 26.5.2

What issue are you seeing?

Opening historical Remote Control tasks after the remote Mac was recovered and re-enrolled under a new remote environment identity repeatedly tears down and restarts Codex Desktop.

The backend task list maps the historical tasks to the new live remote host, but Desktop's cached route for the same tasks still contains the old pre-recovery host ID. Opening either of two historical parent tasks reproduced the failure. Their task IDs are intentionally omitted.

Observed sanitized controller sequence:

thread/read -> thread not loaded
thread/resume -> no rollout found for thread id
Received turn/started for unknown conversation
Invalid message received: Missing AppServer request message handler
[desktop-notifications][unhandled-rejection] Missing AppServer request message handler
IpcRouter Socket error: write EPIPE
local stdio transport -> disconnected (cause=stop_process)
remote websocket transport -> disconnected (cause=stop_process)

The app then relaunches. There were at least six Codex Desktop process instances within approximately 14 minutes while attempting to open these remote tasks. No macOS .ips report or Crashpad dump was produced, consistent with an app-controlled renderer/error-boundary restart rather than a native crash.

The remote Mac remained alive over SSH and its WindowServer and Codex processes continued running. Direct backend thread/read calls also succeeded, so the task data was available; only the Desktop task view was unusable.

What steps can reproduce the bug?

1. Configure a Mac as a Codex Remote Control host and accumulate historical tasks, including a parent task with multiple child/subagent workstreams.
2. Recover or rebuild the host so that Remote Control re-enrolls it under a new environment identity while the historical tasks remain visible to the controller.
3. Reopen Codex Desktop on the controlling Mac.
4. Click a historical task whose cached route references the old host identity but whose backend list entry now references the new live host.
5. Observe repeated hydration/resume attempts, unknown-conversation events, Missing AppServer request message handler, EPIPE, transport teardown, and app restart.
6. Relaunch and open a second historical remote task; observe the same failure.

What is the expected behavior?

Desktop should reconcile historical task routes to the current live host before hydrating the task. Events for an unknown conversation should be buffered or dropped safely until the conversation is registered. A missing request handler must not become an unhandled rejection or tear down unrelated local and remote transports.

If the task cannot be safely reattached, Desktop should show a recoverable error and keep the rest of the app usable.

Additional information

This closely overlaps #21167 (turn/started for unknown conversation reconnect loop) and #31090 (renderer crash after reopening a parent with multiple subagents). The new evidence here is the deterministic old-host/new-host route mismatch after Remote Control re-enrollment, two independently affected historical parent tasks, and the repeated Missing AppServer request message handler -> EPIPE -> stop_process sequence.

The report intentionally omits hostnames, environment IDs, account IDs, cookies, full paths, and task contents.