Mac-to-Mac remote control fetches remote thread/list but sidebar remains on local conversations

Summary

Codex Desktop on one Mac can connect to another Mac via Settings > Connections > Control other devices, and the controller logs show that the remote websocket app-server connection is healthy and that the remote thread list is successfully fetched.

However, the main Codex Desktop sidebar/home view never shows the remote Mac's projects or conversations. It continues to render only the controller Mac's local projects/conversations, and the main route remains under /local/....

This seems related to other remote-history issues, but this case is a narrower downstream failure: the remote thread/list does happen and appears to return non-empty results.

Environment

• Controller: macOS 26.5.1 (25F80)
• Controller Codex.app: 26.602.30954 (3575)
• Controller local app-server reported version: 0.137.0-alpha.4
• Target: another Mac/iMac on the same account, shown in UI as al-imac.local
• Target remote app-server reported version through controller logs: 0.137.0-alpha.4
• Remote transport: websocket, host id shape remote-control:<redacted>

What works

• Both Macs can run local Codex normally.
• The controller Codex.app settings UI can see the remote iMac as connected.
• In Settings, selecting the top-left host dropdown can switch the settings context to al-imac.local.
• ChatGPT mobile can connect to/control the same iMac.
• Direct/manual checks of the target show it has existing Codex threads; in this case there were 3 remote threads.
• Controller logs show remote connection success and a remote thread-list recovery with conversationCount=3.

Reproduction

1. Run Codex Desktop on two Macs under the same account.
2. Enable remote control on the target iMac.
3. On the controller Mac, open Settings > Connections > Control other devices and connect/select the target al-imac.local.
4. Confirm the target appears connected in settings.
5. Return to the main Codex Desktop sidebar/home view.

Expected behavior

The main Codex Desktop UI should provide a way to switch to the remote host and show the remote host's projects/conversations, so existing conversations on the iMac can be continued from the controller Mac.

This matches the remote-connections documentation expectation that a remote client can use the connected host's projects/threads and continue existing threads.

Actual behavior

The settings UI can select the remote host, but the main app sidebar remains local-only:

• only controller-local projects/conversations are visible
• no iMac projects/conversations appear
• the main route remains /local/<local-thread-id>
• repeated main/sidebar refreshes request hostId=local

Log evidence

Sanitized excerpts from the controller Mac's Codex Desktop log:

[AppServerConnection] Starting app-server connection hostId=remote-control:<redacted> transport=websocket
[AppServerConnection] Current reported app-server version: currentVersion=0.137.0-alpha.4 hostId=local
[AppServerConnection] Current reported app-server version: currentVersion=0.137.0-alpha.4 hostId=remote-control:<redacted>

[electron-message-handler] remote_connections.connection_state_changed error=null hostId=remote-control:<redacted> state=connected
[electron-message-handler] remote_connections.manager_state_set hostId=remote-control:<redacted> nextError=null nextState=connected previousError=null previousState=connecting source=host_connection_state_changed

[AppServerConnection] response_routed broadcastFallback=false conversationId=null durationMs=24239 errorCode=null hadInternalHandler=false hadPending=true method=thread/list originWebcontentsId=1 requestId=<redacted> targetDestroyed=false
[electron-message-handler] websocket_reconnect_marked_threads_needing_resume conversationCount=3 markedCount=0 previousRoleCount=0 previousStreamingCount=0
[electron-message-handler] websocket_reconnect_recovery_done currentConversationExistsOnTargetHost=false currentConversationId=null hostId=remote-control:<redacted> refreshRecentConversationsFailed=false resumedCurrentConversation=false

After that, selecting the remote host in Settings produces a remote-context request:

[electron-fetch-handler] codex-home request hostId=remote-control:<redacted> ...

But returning to the main app still keeps local route/list state:

[electron-fetch-handler] codex-home request hostId=local ...
[electron-message-handler] IAB_LIFECYCLE received browser sidebar owner sync browserTabId=null conversationId=<local-thread-id> originWebContentsId=1 ownerRoutePath=/local/<local-thread-id> windowId=1

This pattern repeats across multiple refreshes.

Why this may be useful

Related issues I found:

• #22762: Android remote control did not load host history, but that report says no thread/list requests were observed.
• #23482: macOS remote control stalls with app-server responsive but remote manager disconnected.
• #25589: iOS sends thread/list and gets an empty list.
• #22438: Desktop SSH remote persisted sessions do not appear after restart.

This report differs because the controller reaches connected, the remote app-server reports a current version, thread/list is routed successfully, and recovery sees conversationCount=3 with refreshRecentConversationsFailed=false. The failure seems to happen after the remote list is available: the visible main UI remains bound to the local route/list instead of switching/hydrating the remote host's conversations.

Hypothesis

The Settings host selector may only affect settings-context requests, while the main home/sidebar route remains bound to /local/.... Remote thread/list results may be fetched during connection recovery but not propagated into the visible conversation list, or there may be no accessible host switcher in the main desktop UI for remote-control:* hosts.

Full logs can be provided privately if needed; the public issue body intentionally omits account IDs, client IDs, and token-related fields.