›_ Codex Issues
Codex Issues / #33332

[Windows] Codex Desktop exits when Browser Use creates first IAB tab after route mismatch

Open 💬 6 comments Opened Jul 15, 2026 by S0L0RIEN
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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?

  1. Fully quit and relaunch Codex Desktop.
  2. Use one persisted root task.
  3. Do not run collaboration subagents or parallel Browser Use tasks.
  4. Enable the bundled Browser plugin.
  5. Initialize the documented Browser runtime and acquire the IAB backend.
  6. 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 #20678, but that report is explicitly macOS-focused.
  • #33133 contains the same attach_unmatched ... url=undefined urlProtocol=invalid signature on macOS; this report adds a deterministic Windows Codex Desktop AppX-container exit.
  • The older generic Windows close/disappear report #24998 did not include this Browser/IAB reproduction or route evidence.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #32885
  • #32683
  • #32438
  • #32334

Powered by Codex Action

Roseglyph · 1 month ago

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
  • Windows 10 x64, build 10.0.19045
  • Codex Desktop AppX: 26.707.9981.0
  • Bundled Browser/IAB release: 26.707.72221
  • Native Windows task (not WSL)
Trigger

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:

await visibility.set(true);
const tab = await browser.tabs.new();
await tab.goto("http://127.0.0.1:4173/");

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:

IAB_LIFECYCLE created browser use host
conversationId=client-new-thread:<redacted>

IAB_TAB_ANALYTICS browser tab lifecycle action=opened
IAB_LIFECYCLE opening route page ... hasStartingUrl=true
IAB_LIFECYCLE created browser sidebar page state
IAB_LIFECYCLE waiting for browser sidebar webview attachment
IAB_LIFECYCLE renderer created browser sidebar webview ... initialUrl=about:blank

[mcp-app-sandbox] mcp_app_sandbox.attach_unmatched
guestWebContentsId=<redacted> url=undefined urlProtocol=invalid

IAB_LIFECYCLE runtime attached browser sidebar webview
browser sidebar dom-ready ... url=about:blank
IAB_LIFECYCLE iab createTab mapped page to tab
conversationId=<persisted-id-redacted>
pageKey=1:client-new-thread:<redacted>:browser-use:<redacted>
routeKey=1:client-new-thread:<redacted>
<desktop log ends abruptly>

The last log entry occurred less than one second after about:blank reached DOM-ready. Windows AppModel-Runtime then recorded Event ID 217 destroying the complete OpenAI.Codex_26.707.9981.0 Desktop 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.
  • A temporary-to-persisted route mismatch or unmatched sandbox attachment should produce a recoverable Browser error, not terminate the Codex AppX container.
  • Until the native failure is fixed, consider preventing the visible IAB path from opening on affected Windows builds or falling back to an external browser backend.

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 · 1 month ago

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

  • Windows x64 10.0.26200.8655
  • Codex Desktop AppX 26.707.9981.0
  • Browser/IAB release 26.707.72221
  • NVIDIA RTX 3050, driver 591.86

Second 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/trajectory

The 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

IAB_LIFECYCLE renderer created browser sidebar webview
conversationId=client-new-thread:<temporary>
hostKind=right-panel
initialUrl=http://127.0.0.1:8766/trajectory

IAB_LIFECYCLE browser sidebar will attach webview
IAB_LIFECYCLE requested browser sidebar webview attachment
IAB_LIFECYCLE queued browser sidebar webview route
[mcp-app-sandbox] mcp_app_sandbox.attach_unmatched ... url=undefined urlProtocol=invalid
IAB_LIFECYCLE did attach browser sidebar webview
IAB_LIFECYCLE runtime attached browser sidebar webview
browser sidebar dom-ready ... url=http://127.0.0.1:8766/trajectory

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:

process: ChatGPT.exe
faulting module: unknown
exception: 0xc06d007f
offset: 0x00007ff8f4da1b6a
WER bucket/hash: fe840c3ed30ba850ddeac7488b0e9f2e

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-webview handler, while its did-attach-webview listener still logs attach_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 also 0xc06d007f.

Safe local containment

Setting:

[features]
in_app_browser = false

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 · 1 month ago

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 · 6 days ago

I can confirm this is still reproducible on a newer Windows build, with additional Crashpad evidence.

Environment

  • Windows 11 Pro x64
  • Codex Desktop (Microsoft Store/MSIX): 26.818.3698.0
  • Bundled Browser plugin release shown in logs: 26.818.31338

Two 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:

  1. No ChatGPT browser route is available for browser session <redacted>
  2. A Browser Use tab was opened/attached.
  3. CDP evaluation failed with Cannot find context with specified id.
  4. The target/webview was closed and torn down.
  5. Within about one second, Crashpad recorded a browser-process crash and the whole desktop app exited.

The Crashpad sidecar metadata was identical for both incidents:

{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}

Additional observations:

  • AppServer/config requests were succeeding immediately before both crashes.
  • Windows recorded no network disconnect, sleep, restart, or relevant Application Error/WER event at either time.
  • The second incident reproduced the same route/context-loss sequence as the first.
  • Full logs are not attached because they contain local paths, prompts, and task/session identifiers; targeted sanitized excerpts can be provided if needed.

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 · 6 days ago

Current Windows x64 update: repeated all-day exits plus main-process write EOF

This is a sanitized follow-up from a paid Codex user whose Windows desktop app is now unreliable for sustained work.

Environment

  • Windows 11 Home x64, build 26200
  • Current Codex Desktop MSIX: 26.818.5229.0
  • Recurrence observed across 26.818.2441.0, 26.818.3698.0, 26.818.4152.0, and 26.818.5229.0

User impact

  • The whole app exits several times per day.
  • A modal blocks all input:

``text
A JavaScript error occurred in the main process
Uncaught Exception:
Error: write EOF
at WriteWrap.onWriteComplete [as oncomplete]
(node:internal/stream_base_commons:87:19)
``

  • Running tasks become inaccessible or appear stuck until the app is relaunched.
  • Repeated app restarts and Windows reboots do not prevent recurrence.

Sanitized evidence from 2026-08-22 KST

  • 09:38 and 11:44: Store update download completed, followed by Stopping app-server transport.
  • 10:28, 11:38, 12:15, and 14:02: the main log ended abruptly without a normal quit/update record.
  • After the 12:15 exit, a new instance appeared about seven seconds later.
  • Today's logs contain 1,094 state-desynchronization messages such as Received ... for unknown conversation.
  • Repeated Git snapshot became stale messages are also present.
  • On an older build, the exact failure was logged as:

``text
[IpcRouter] Socket error errorCode=EPIPE errorMessage="write EPIPE"
``
followed by client unregistration / IPC connection reset / transport shutdown.

Local system checks

  • No Codex Application Error, Windows Error Reporting entry, or Codex crash dump.
  • No Defender, AppLocker, or Code Integrity block.
  • No GPU/display crash event.
  • Adequate RAM and disk space.
  • Windows itself remains stable; the Codex app/container is what disappears.

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

  • EOF/EPIPE after child/browser/client teardown must be handled and must never be uncaught in the Electron main process.
  • App updates should defer until active tasks are idle and must not terminate active work.
  • Renderer/app-server conversation state should recover or resynchronize instead of producing thousands of unknown-conversation events.
  • A single browser/client failure must not terminate the entire desktop app.

Please treat this as a high-severity work-continuity issue. Sanitized targeted log excerpts can be provided if maintainers specify what is needed.