Repository navigation
[Windows] Codex Desktop exits when Browser Use creates first IAB tab after route mismatch #33332
Description
What version of the Codex App are you using?
Codex Desktop Microsoft Store package: 26.707.9981.0
Bundled Browser plugin selected by the task: openai-bundled/browser/26.707.72221
What subscription do you have?
ChatGPT account in Codex Desktop. Subscription details omitted from this diagnostic.
What platform is your computer?
Windows 10.0.26200.8655 x64.
What issue are you seeing?
Codex Desktop exits completely when Browser Use creates its first controlled in-app-browser tab. Windows itself remains stable; this is only a Codex Desktop process/AppX-container termination.
Browser runtime initialization, acquiring agent.browsers.get("iab"), and reading browser documentation all succeed. The failure occurs when tabs.new() creates and attaches the blank controlled about:blank webview.
The Desktop lifecycle logs show the persisted task route and a temporary client-new-thread:* route diverging. The tab is attached under the temporary route, after which Codex Desktop disappears without a crash dialog.
What steps can reproduce the bug?
- Fully quit and relaunch Codex Desktop.
- Use one persisted root task.
- Do not run collaboration subagents or parallel Browser Use tasks.
- Enable the bundled Browser plugin.
- Initialize the documented Browser runtime and acquire the IAB backend.
- Run:
await iab.nameSession("Built-in browser health check");
const tab = await iab.tabs.new();
await tab.goto("https://example.com/");The app exits during/just after tabs.new(), before navigation completes.
Sanitized lifecycle evidence
The persisted route is captured, but a Browser Use host is created for a temporary draft ID:
IAB_LIFECYCLE captured browser use session route
conversationId=<persisted-id>
IAB_LIFECYCLE created browser use host
conversationId=client-new-thread:<temporary-id>
The first backend-info request can complete, then the repeated request for the persisted task fails:
IAB_LIFECYCLE iab backend info request completed
conversationId=<persisted-id>
IAB_LIFECYCLE iab backend info request failed
conversationId=<persisted-id>
errorMessage="No ChatGPT browser route is available for browser session <persisted-id>"
The new blank tab is mapped under the temporary route:
IAB_LIFECYCLE iab createTab mapped page to tab
conversationId=<persisted-id>
pageKey=1:client-new-thread:<temporary-id>:browser-use:<redacted>
routeKey=1:client-new-thread:<temporary-id>
[mcp-app-sandbox] mcp_app_sandbox.attach_unmatched
guestWebContentsId=2 url=undefined urlProtocol=invalid
The final Desktop log entry shows the IAB webview reaching dom-ready on about:blank. Approximately three seconds later, Windows AppModel records the Codex Desktop AppX container as destroyed.
There is no Codex Application Error/WER entry and no Windows crash or BSOD. Codex simply disappears and must be relaunched.
What is the expected behavior?
- The temporary draft route should be atomically canonicalized to the persisted task ID before
tabs.new(). - The controlled IAB tab should remain attached to the current root task.
- A route-binding failure should return a recoverable Browser error instead of terminating Codex Desktop.
- Navigation to
https://example.com/should complete normally.
Additional information
- Reproduced multiple times after a full Codex restart.
- Reproduced with one root task and no subagents, so concurrency is not required.
- Not website-specific; the controlled tab exits while still on
about:blank. - The same class of draft-to-persisted route divergence is discussed in fix(browser): Browser Use cannot connect to IAB from Node REPL on macOS #20678, but that report is explicitly macOS-focused.
- Codex Desktop: in-app browser tabs are repeatedly disposed/closed and lose Browser Use session ownership #33133 contains the same
attach_unmatched ... url=undefined urlProtocol=invalidsignature on macOS; this report adds a deterministic Windows Codex Desktop AppX-container exit. - The older generic Windows close/disappear report [Windows] Codex desktop app crashes / closes automatically on launch or during use #24998 did not include this Browser/IAB reproduction or route evidence.
Activity
github-actions commentedon Jul 15, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Roseglyph commentedon Jul 15, 2026
Independent reproduction on the same stable build; crash occurs before navigation
I independently reproduced this issue on Windows with the same Codex Desktop and bundled Browser versions. This comment is intentionally sanitized: no usernames, local paths, repository/project names, task/session IDs, account information, or raw logs are included.
Environment
10.0.1904526.707.9981.026.707.72221Trigger
The user asked Codex to open a healthy local development page at
http://127.0.0.1:4173/and describe what was visible. Browser runtime setup, IAB backend selection, and Browser documentation retrieval all completed normally. Codex then executed the equivalent of:The entire Codex app silently exited during
tabs.new(). Navigation, DOM inspection, console-log collection, and screenshot capture did not execute to completion.Sanitized lifecycle sequence
The persisted task ID and temporary draft route diverged, matching this issue's route-binding evidence. The final lifecycle sequence was:
The last log entry occurred less than one second after
about:blankreached DOM-ready. Windows AppModel-Runtime then recorded Event ID 217 destroying the completeOpenAI.Codex_26.707.9981.0Desktop AppX container approximately four seconds later. A new Codex process was created approximately eight seconds after that.This reproduction is not website- or localhost-content-specific: the target URL was never reached, so the local application could not have caused the demonstrated failure. The failure boundary is first visible IAB tab creation/webview attachment while still on
about:blank.Expected behavior / containment request
tabs.new()should safely create and bind an IAB tab to the persisted task route.No raw logs or dumps are attached because they contain local paths, task metadata, and identifiers. Sanitized excerpts can be provided if maintainers request a narrower diagnostic.
kirillsaven commentedon Jul 15, 2026
Additional deterministic Windows x64 evidence (normal link click, static localhost page)
I re-checked this from the local app/package/logs and ruled out the target page and GPU path.
Environment
10.0.26200.865526.707.9981.026.707.72221591.86Second trigger path
This is not limited to
tabs.new(). Clicking a normal link in an existing persisted task caused the right-panel IAB to open:http://127.0.0.1:8766/trajectoryThe response was HTTP 200 and a static 444,102-byte HTML document. The page contains no scripts, iframes/webviews, service worker, WebSocket/EventSource, WebGL, external resources, or navigation code.
The same URL completed successfully in isolated headless Chrome runs both with default GPU settings and with
--disable-gpu(exit 0, expected DOM/title in both cases).Lifecycle immediately before the exit
The renderer owner route in the same sequence was the persisted task route, while the webview conversation was still
client-new-thread:<temporary>, consistent with the route mismatch in this issue.About six seconds after
dom-ready, AppModel-Runtime Event 217 destroyed the complete Codex AppX container.Two consecutive reproductions produced identical Windows Application Error signatures:
The same localhost browser failure was also observed twice on July 11 with an earlier Codex package, so this is not isolated to one installation of the current Store build.
One correction to earlier hypotheses: inspection of the packaged main-process code shows that the primary window intentionally allows non-MCP webviews through the MCP sandbox
will-attach-webviewhandler, while itsdid-attach-webviewlistener still logsattach_unmatched. Therefore that warning is a useful timing marker but is not by itself proof of the root cause.The current x64 build also logs a recoverable
serialport.node“DLL initialization routine failed” error during startup. The app remains alive after that error and exits only after the IAB attach in these reproductions, so I am not claiming causality, but it may be relevant because the WER exception code is also0xc06d007f.Safe local containment
Setting:
prevents the crash path by disabling the built-in browser pane. External Chrome/direct HTTP remain healthy. This is containment, not a fix for the IAB route/native failure.
anny162636-jpg commentedon Jul 16, 2026
Reporting a possible ARM64 variant of this issue — all reproductions in this thread so far are on x64, mine is on ARM64.
Environment:
Package: OpenAI.Codex_26.707.9981.0 — ARM64
Desktop client (app-server log): 26.707.72221
Windows, confirmed latest via Microsoft Store
Tried the in_app_browser = false containment from this thread — it did not fix it.
Confirmed via logs that the setting took effect:
browser_use_availability_resolved available=false browserPane=false reason=browser-pane-disabled
But the app still exits ~7 seconds after launch, and this time without any IAB webview initialization ever occurring — the log just ends after routine startup calls (account/read, config/read, model/list, windowsSandbox/readiness), no error/panic entry, same "hard kill" signature as the browser-pane crashes.
This suggests either a distinct ARM64-specific crash path, or the same underlying native failure triggered by something other than IAB tab creation. Happy to provide sanitized logs if useful for triage.
libai1819787-boop commentedon Aug 22, 2026
I can confirm this is still reproducible on a newer Windows build, with additional Crashpad evidence.
Environment
26.818.3698.026.818.31338Two occurrences
The app exited twice on 2026-08-22, at approximately 01:25 and 16:46 local time (UTC+8), while a task was using the bundled in-app Browser. In both cases, the user had to reopen the app manually.
Both incidents followed the same sanitized sequence:
No ChatGPT browser route is available for browser session <redacted>Cannot find context with specified id.The Crashpad sidecar metadata was identical for both incidents:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}Additional observations:
Expected behavior: a stale/missing Browser Use route or CDP context should fail or recover at the affected tab level, without terminating Codex Desktop.
kdyoung9677-hub commentedon Aug 22, 2026
Current Windows x64 update: repeated all-day exits plus main-process
write EOFThis is a sanitized follow-up from a paid Codex user whose Windows desktop app is now unreliable for sustained work.
Environment
User impact
Sanitized evidence from 2026-08-22 KST
Stopping app-server transport.Received ... for unknown conversation.Git snapshot became stalemessages are also present.Local system checks
This appears to extend the issue beyond first-IAB-tab creation: current builds can exit during ordinary multi-task use, and the app may surface an unhandled main-process pipe write instead of containing the failure to one browser/client transport.
Expected behavior
Please treat this as a high-severity work-continuity issue. Sanitized targeted log excerpts can be provided if maintainers specify what is needed.
lavapapa commentedon Sep 13, 2026
macOS reproduction on current Desktop build (route mismatch without app exit)
I independently reproduced the same temporary-to-persisted Browser Use route divergence on macOS. This report is sanitized: no usernames, local paths, project names, prompts, account details, raw task IDs, or full logs are included.
Environment
What works
This rules out a missing plugin, failed installation, target-site failure, and ordinary network/site-access policy as the primary cause.
Failure boundary
After tab creation/navigation, DOM, accessibility-tree, page-state, and deeper CDP operations time out or fail. The Desktop logs show the same route split described in this issue:
Subsequent requests use the persisted task ID and fail with:
A healthy older persisted task in the same app installation showed the owner route, Browser Use host, and controlled-tab route all using one persisted ID. The broken task is specifically different because its host/page remain keyed by
client-new-thread:*after the task has a durable ID.Troubleshooting already performed
These steps do not repair the route once the temporary and persisted identities diverge.
Requested fix
Please treat the temporary-to-persisted transition as one atomic lifecycle operation before allowing
getInfo,tabs.new(), or CDP/page-state requests:This confirms the route-mismatch class is cross-platform and remains reproducible on the September macOS build. Related macOS ownership reports include #20678 and #33133.