[macOS Desktop] Active remote thread loses in-app Browser route after archive/reopen

Start with the Browser runtime's iab discovery, the session-owned route lifecycle, and the desktop app-server logs; compare the behavior with related issues #25353, #35083, and #33599. Reproduce archive/reopen if possible and verify that an active Codex Remote thread has an iab backend, or presents an actionable error when Browser state cannot be restored.

What version of the Codex App are you using?

• Codex Desktop: 26.721.41059 (build 5848)
• Previous version when troubleshooting began: 26.721.31836 (build 5828)

What platform are you using?

• macOS 26.5.2 (25F84)
• Apple Silicon (arm64)
• Codex Remote execution: the conversation/agent is running remotely through Codex Remote, while Codex Desktop on the user's Mac is expected to provide the local in-app Browser route and authenticated browser tabs.
• The user is operating the remote thread from another device and cannot perform local UI recovery steps on the Mac.

What issue are you seeing?

An existing Codex Remote thread that previously had a functioning local in-app Browser route no longer receives any Browser backend. The likely trigger was accidentally archiving the remote thread and then reopening it, although that causal step is not yet independently confirmed.

This is specifically a bridge failure between a remotely executing Codex conversation and the local macOS Codex app's Browser host. The remote agent continues to run normally and can invoke local tools exposed by the Mac, but the local app does not register an in-app Browser route for this active remote conversation.

The reopened thread is reported by Codex as active, and the desktop app can navigate to and continue the thread normally. However, the Browser runtime cannot discover a session-owned route:

agent.browsers.get("iab") -> Browser is not available: iab
agent.browsers.list()      -> []

Desktop logs also reported:

No ChatGPT browser route is available for browser session [redacted]

The Browser sidebar was registered to a new local thread after restart, but no route was created for the reopened Codex Remote conversation.

Steps that led to the failure

1. Start or continue a Codex Remote conversation from another device, with Codex Desktop running on the Mac and supplying its local in-app Browser to the remote agent.
2. Use the remote thread with the in-app Browser. The Browser previously worked and retained authenticated tabs on the Mac.
3. Accidentally archive the remote thread.
4. Reopen/continue the same remote thread in the macOS desktop app.
5. From Codex Remote, ask the agent to use the bundled Browser plugin.
6. Initialize the Browser runtime and request the iab backend.
7. Observe that get("iab") fails and list() is empty even though the remote thread is active and otherwise functional.

Because the archive action was accidental, this is currently a strong suspected trigger rather than a controlled minimal reproduction.

Recovery attempts

The failure persists after all of the following:

• reopening and explicitly navigating the macOS app to the affected remote thread;
• updating Codex Desktop from 26.721.31836 build 5828 to 26.721.41059 build 5848;
• fully restarting the main desktop app;
• terminating a stale pre-update app-server, its code-mode host, and its Node runtime so only the fresh post-update process tree remained;
• retrying Browser discovery from a fresh Codex Remote turn.

Before the stale process tree was removed, logs contained a native-pipe peer code-signature verification failure. After removing it, that error disappeared, but the failure changed to the missing-route error above. This indicates the native pipe recovered while the active remote conversation still lacked a local Browser route.

Expected behavior

When an archived Codex Remote thread is reopened and active in Codex Desktop, the desktop app should create or reattach a session-owned local in-app Browser route for that remote conversation. Browser discovery from the remote agent should return an iab backend.

If Browser state cannot be restored, Codex Desktop should create a fresh Browser host for the active remote thread or show an actionable UI error instead of advertising the Browser skill to the remote agent while returning an empty backend list.

Actual behavior

The Codex Remote thread remains usable for normal agent turns and other local-tool calls, but it is permanently detached from the Mac's Browser Use host. Updating, restarting, navigating to the remote thread, and removing stale helper processes do not restore the route.

This is particularly problematic for Codex Remote because the user may be away from the Mac and unable to click through local recovery UI.

Privacy

Thread IDs, authenticated URLs, credentials, and task content are omitted. Targeted sanitized logs can be supplied if maintainers provide a suitable channel.

Related issues

• #25353: no session-owned Browser route registered, but reported for VS Code/Windows
• #35083: Browser route loss and lifecycle cleanup on macOS
• #33599: Desktop task/browser tool injection failures on macOS