Repository navigation
[Codex App] IAB browser session IDs are resumed as remote SSH thread IDs #34894
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.715.10079.0
What subscription do you have?
Not provided.
What platform is your computer?
Microsoft Windows NT 10.0.22000.0 x64
What issue are you seeing?
When using the Codex Desktop app with a managed remote SSH host, some sidebar entries appear as new/local conversations but cannot be resumed. Opening one produces:
no rollout found for thread id <id>
The failing IDs appear to be In-App Browser (IAB) / Browser Use session IDs, not Codex agent thread IDs.
For example, the desktop log first records the same ID as a Browser Use session route:
IAB_LIFECYCLE webview captured browser use session route
conversationId=019f8dc7-96b5-72b2-84d3-b299dbcdba4c
Later, the desktop registers that ID as a browser-sidebar thread under /local/<id>, associates it with a remote-ssh-codex-managed host, and calls thread/resume:
maybe_resume_started conversationId=019f8dc7-96b5-72b2-84d3-b299dbcdba4c
hostId=remote-ssh-codex-managed:<redacted>
Request failed ... method=thread/resume
error={"code":-32600,"message":"no rollout found for thread id 019f8dc7-96b5-72b2-84d3-b299dbcdba4c"}
I observed the same sequence for these IDs:
019f8dc3-91d7-7ca2-947f-6ebe52c08b07019f8dc6-9a79-74b0-b2f2-f98db1487877019f8dc7-96b5-72b2-84d3-b299dbcdba4c019f8dc9-c3ab-7731-a8bb-bdeb27e50f46
For each ID, there was no matching row in Codex's local threads state table and no matching rollout JSONL file. The app is therefore attempting to resume an ID that was never a rollout-backed Codex thread.
What steps can reproduce the bug?
I do not yet have a single deterministic click sequence, but the observed flow is consistent:
- Open Codex Desktop and connect to a managed remote SSH host.
- Use a workflow that causes an In-App Browser / Browser Use session route to be captured.
- A sidebar entry is later registered with the IAB session's
conversationIdat a/local/<id>route. - Open that entry.
- The app invokes
thread/readand thenthread/resumewith the IAB session ID, which fails withno rollout found for thread id <id>.
The issue occurred on two separate managed remote SSH hosts.
What is the expected behavior?
Browser Use/IAB session IDs must not be persisted or registered as normal local Codex conversations, and must never be passed to thread/read or thread/resume as a Codex thread ID.
For remote SSH conversations, the sidebar should retain the actual rollout-backed thread ID. If no such thread exists, the UI should not create a resumable conversation entry.
Additional information
I searched existing open issues and did not find one that matched this specific IAB-session-ID-to-remote-SSH-thread-ID mismatch.
I can provide a redacted excerpt of the desktop log if useful.
Activity
github-actions commentedon Jul 23, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
No-54 commentedon Aug 28, 2026
I am seeing what appears to be the same failure class on Windows -> Linux Remote SSH, but possibly through a different trigger path.
Environment:
Observed behavior:
Three ghost entries appeared in the Windows app sidebar.
Instead of normal conversation titles, all three are displayed as the remote project path.
Opening any of them fails with:
no rollout found for thread id
The three failing thread IDs are:
The entries persist after fully exiting and restarting the Windows app.
I performed read-only checks before attempting any cleanup.
Remote Linux / Codex CLI:
codex resumeshows only the seven valid/expected sessions.~/.codex/sessions.threadstable ofstate_5.sqlite.thread_history_1.sqlite.Windows app local state:
browser-sidebar-page-states.json.I have not manually modified or deleted any Codex state databases, rollout files, caches, or session files.
This looks very similar to #34894 because the Windows sidebar is trying to resume IDs for which no rollout-backed Codex thread exists. The potentially different part in my case is that I was using the remote Codex CLI and the Windows Desktop app with the same Remote SSH project; I was not intentionally using an In-App Browser / Browser Use workflow when I noticed these entries.
If useful, I can provide redacted desktop log excerpts for the affected IDs.
No-54 commentedon Aug 29, 2026
Additional finding from a newly created fourth ghost entry:
A fourth ghost entry appeared while I was using only the Windows Codex Desktop app. I did not use the Codex CLI during this period, so CLI/Desktop synchronization does not appear to be required to trigger the issue.
The desktop logs for the new ghost ID show the same IAB -> Remote SSH thread-resume sequence described in this issue.
Relevant sequence (redacted/summarized):
IAB_LIFECYCLEreceives/captures a browser session route using the ghost conversationIdbrowser_use_iab_backend_startup_startedhostId=remote-ssh-discovered:<host>and a
/local/<conversationId>routethread/readfails with:thread not loaded: <conversationId>thread/resumethread/resumefails with:no rollout found for thread id <conversationId>and
failureReason=rollout_not_foundI was not intentionally using Browser Use / the In-App Browser when this new ghost appeared, but the desktop logs clearly show the internal IAB lifecycle handling this ID.
This makes the behavior look even closer to the IAB-session-ID -> Remote SSH thread-ID mismatch reported here, rather than being dependent on remote CLI usage.