[Windows][Codex Desktop][IAB] `browser.tabs.finalize()` silently terminates the entire app

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

• #34239

Powered by Codex Action

I can reproduce this on the exact same Windows Codex build:

Codex Desktop: 26.721.3996.0

Bundled Browser Use: 26.721.31836

Windows 11 x64

Microsoft Store / MSIX package

The entire Codex app repeatedly disappeared while using the bundled IAB. There was no normal Application Error/WER crash report. After relaunch, the task transcript remained available.

The package then entered a Microsoft Store Get/Restore cycle. AppXDeploymentServer recorded error 0x80073CF2 and failed StageUserDataAsync operations for:

OpenAI.Codex_26.721.3996.0_x64__2p2nqsd0c76g0

A separate clean-chat test, unrelated to any project or local files, also failed during IAB bootstrap with:

CreateProcessWithLogonW failed: 5

Reinstalling the Store package did not resolve the problem. Winget reports no newer version is available.

I will avoid browser.tabs.finalize() on this build and leave IAB tabs open as the workaround described in this issue.

Independent same-build occurrence with a within-process counterexample

I observed another silent whole-host termination with the following environment:

• Codex Desktop AppX: 26.721.4979.0 x64
• Browser plugin: 26.721.41059
• Windows 11 25H2, build 26200.8875
• Browser backend: multi-tab IAB

Incident timeline

All timestamps below are from 2026-07-28 UTC:

• 21:26:07.785 — browser.tabs.finalize({ keep: [] }) was invoked
• 21:26:07.826 — the call returned successfully with sessionEnded:true
• 21:26:07.871, .888, and .903 — three IAB tabs closed sequentially; the app tab count changed from 2 -> 1 -> 0
• 21:26:07.908 — the desktop log stopped without a graceful-shutdown, fatal-error, or process-exit marker
• Windows subsequently recorded destruction of the Codex AppX container
• A new application instance started approximately 13 seconds later

I found no corresponding:

• Application Error event
• Windows Error Reporting report
• standard crash dump
• Crashpad report
• Code Integrity or Defender event
• OOM or resource-exhaustion event
• GPU, display-driver, or relevant system error

These checks only show that no standard crash or policy-termination evidence was found; they do not establish that the process exited normally.

Counterexample from the same process

The exact same call had completed successfully earlier in the same task, using the same IAB browser ID and desktop process:

• 19:51:51.683 — identical browser.tabs.finalize({ keep: [] })
• the call returned successfully with sessionEnded:true
• one IAB tab closed and the tab count was reduced to zero
• the same desktop process remained alive for approximately 94 additional minutes

The main observed differences were:

• surviving occurrence: one tab closed; main window focused
• terminating occurrence: three tabs closed sequentially; main window not focused

Both occurrences used the same temporary client-new-thread route.

The counterexample shows that browser.tabs.finalize({ keep: [] }) alone was not sufficient to trigger the failure. In the terminating occurrence, however, the call was tightly associated in time and lifecycle sequence with the termination boundary.

The strongest differentiator currently observed is single-tab versus multi-tab teardown. A teardown race, shared-state issue, or overlap with turn-end cleanup may be involved, but I have not established a deterministic reproduction or proven the underlying mechanism.

This appears closely related to #35425 and the last-tab teardown failure family described in #34239. It appears distinct from the webview creation/navigation access violation reported in #32334 and #30178.

Newer-build reproduction: browser.tabs.finalize() / IAB teardown still terminates the app on 26.721.11231.0

I reproduced this close-path failure twice on a newer Microsoft Store/MSIX package. The observed lifecycle sequence closely matches this issue: Browser Use finalization completed the IAB teardown, then the entire Codex AppX container disappeared about half a second later.

This also appears closely related to #34239, which tracks the direct tab-close/WebView-teardown path and now includes a native main-process access-violation dump consistent with a lifecycle/use-after-free class failure. I am not claiming that the exact native fault is proven identical here because these two occurrences produced no dump.

Environment

• Codex Desktop/MSIX: OpenAI.Codex_26.721.11231.0_x64__2p2nqsd0c76g0
• Windows x64 build: 26200.8973
• Reproductions: 2 occurrences during one investigation
• Time zone below: KST (UTC+09:00)

Trigger

1. Invoke Browser Use with the Codex in-app Browser (iab).
2. Let the agent finish and finalize/close its Browser Use tab.
3. The Browser sidebar teardown logs complete normally.
4. The entire Codex desktop application disappears about half a second later, without an application error dialog.

This was observed twice during the investigation. It was not a clean-profile soak test, so I am not claiming a universal 100% reproduction rate.

Correlated sequence

Occurrence 1:

09:01:37.528  debugger listener unregistered; webContentsDestroyed=false
09:01:37.565  renderer disposed browser sidebar webview
09:01:37.569  browser sidebar guest torn down
09:01:37.575  renderer removed browser sidebar webview; tabType=closed
09:01:37.575  closed browser sidebar page
09:01:37.575  browser tab lifecycle action=closed
09:01:37.578  final Codex log entry; owner renderer window was still visible
09:01:38.080  AppModel-Runtime Event 217 destroyed the Codex Desktop AppX container

Time from the final Codex log entry to AppX container destruction: approximately 0.502 s.

Occurrence 2:

09:16:15.692  debugger listener unregistered; webContentsDestroyed=false
09:16:15.740  renderer disposed browser sidebar webview
09:16:15.745  browser sidebar guest torn down
09:16:15.751  renderer removed browser sidebar webview; tabType=closed
09:16:15.752  closed browser sidebar page
09:16:15.752  browser tab lifecycle action=closed
09:16:15.757  final Codex log entry; owner renderer window was still visible
09:16:16.315  AppModel-Runtime Event 217 destroyed the Codex Desktop AppX container

Time from the final Codex log entry to AppX container destruction: approximately 0.558 s.

Conversation IDs, Browser Use tab IDs, request IDs, and local paths are intentionally omitted.

Negative evidence

• No Recoverable Chromium child process gone entry.
• No processType=GPU crash/relaunch-failure entry.
• No NeedsRemediation entry in either terminal desktop log.
• No matching Windows Application Error, WER, or Application Hang event.
• No matching resource-exhaustion event.
• No new Crashpad dump was found.
• The MSIX package currently reports Status: Ok.

Installed-package close-path inspection

Static inspection of the installed package shows the Browser Use cleanup path is two-stage:

1. Browser Use finalization closes unkept agent tabs through closeTab() / closePageForBrowserUse().
2. The main process requests renderer teardown.
3. The renderer disposes the <webview> and reports that destruction back to the main process.
4. Final main-process teardown checks the guest webContents and closes it if it is not already destroyed.

I did not find an explicit app.quit(), app.exit(), or process.exit() in this Browser Use close path. The Windows window-all-closed handler also does not intentionally quit the application. Together with rendererWindowVisible=true in the final logs, the observed full-app exit does not look like an intended result of closing one Browser Use tab.

Assessment

The evidence strongly places the failure boundary in the same IAB finalization/WebView teardown family tracked here and in #34239. A two-stage guest-webContents teardown race is a plausible interpretation, but the exact terminating instruction remains unconfirmed without a dump or exit code from these occurrences.

Closing or finalizing an IAB tab should be idempotent and isolated. A guest WebView teardown failure should surface as a recoverable Browser Use error and must not terminate the owner renderer or the full desktop AppX container.

As a temporary safety measure, I am avoiding the Codex in-app Browser and using external Chrome instead.

Newer-build delayed whole-host disappearance (possible related occurrence)

I observed another silent whole-app termination on a newer Windows build. This occurrence is not as tightly coupled to browser.tabs.finalize() as the earlier reproductions, so I am reporting it as correlation evidence rather than claiming direct causality.

Environment

• Codex Desktop/MSIX: OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0
• Bundled Browser release: 26.727.51351
• Windows 11 x64, build 26200
• Browser backend: IAB
• Date below: 2026-08-02 UTC

Timeline

• 09:43:35.056 — browser.tabs.finalize({ keep: [] }) invoked.
• 09:43:35.252 — call returned successfully with sessionEnded:true and openTabIds:[].
• By approximately 09:43:40 — the controlled IAB guest/tab teardown had completed normally.
• 09:46:28 — the agent turn wrote its final response and task_complete; no further agent tool calls occurred.
• 09:48:21 — desktop/app-server logs show a fresh Codex Desktop client initialization/reconnect sequence (auth/account/config/skills RPCs); the IAB backend/native pipe also reported ready. This sequence was initiated by the desktop client, not by an agent tool call.
• 09:48:24.666 — old app-server's final entry was an ordinary config-loader DEBUG record.
• 09:48:30.117 — old desktop host's final log entry was normal initialization/configuration activity, with no fatal, shutdown, or relaunch marker.
• 09:48:30.692 — Windows AppModel-Runtime Event 217 recorded destruction of the complete Codex AppX container.
• 09:48:34.190 — a new Codex AppX container was created through Explorer/Shell activation.

The AppX destruction occurred about 4 minutes 55 seconds after finalization and about 2 minutes after turn completion. This is materially different from the sub-second finalization boundary in the primary report.

Negative evidence

I found no corresponding:

• Stop-Process, taskkill, quit, relaunch, or shutdown request in the task transcript or app logs;
• Codex ERROR, panic, fatal, renderer-gone, or graceful-shutdown entry;
• Application Error, Application Hang, WER report, or Crashpad dump;
• OOM/resource-exhaustion, GPU/display/WHEA, power/sleep/logoff, Defender, or MSIX update event.

The exact same browser.tabs.finalize({ keep: [] }) call had also succeeded twice earlier in the same long-lived desktop process without terminating it, reinforcing that finalization alone is not sufficient.

Assessment

This occurrence shares the same externally visible signature—silent destruction of the entire AppX process tree with no standard crash artifact—but the delayed boundary means I cannot prove that browser.tabs.finalize() caused it. The fresh desktop renderer/client initialization immediately before termination may indicate a delayed or re-entrant lifecycle-state problem; an unrelated unreported host termination remains possible.

I am retaining the original logs and transcript and can provide targeted sanitized excerpts if maintainers want to correlate this newer build.

OpenAI-side correlation identifier: thread/session 019fad20-7141-7302-b8a4-a69691284942.

Additional reproduction on 26.727.6591.0: dialog-handling failures immediately before automatic IAB teardown

I observed another silent whole-app termination on the current Windows Store/MSIX build. This occurrence closely matches the teardown boundary reported here, with an additional sequence of Browser Use dialog/input errors immediately before the final WebView cleanup.

Environment

• Codex Desktop/MSIX: OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0
• Bundled Browser plugin: 26.727.51351
• Bundled Chromium/desktop runtime: 150.0.7871.182
• Windows 11 x64, version 25H2, build 26200.8875
• GPU: NVIDIA GeForce RTX 3090, driver 595.79
• Time zone: JST (UTC+09:00)

Failure sequence

Codex timestamps below are UTC on 2026-08-02:

11:55:28.549  Browser Use CDP input failed:
              Timed out translating "Input.dispatchMouseEvent" for tab 1

11:56:45.383  executeCdp:Page.handleJavaScriptDialog failed:
              "No dialog is showing"

11:57:08.377  executeCdp:Page.handleJavaScriptDialog failed again:
              "No dialog is showing"

11:57:29.808  executeCdp:Page.handleJavaScriptDialog failed a third time:
              "No dialog is showing"

11:57:42.324  debugger listener unregistered; reason=manual;
              webContentsDestroyed=false
11:57:42.325  Browser Use active state changed to false
11:57:42.360  renderer synced Browser Use WebView state
11:57:42.361  renderer disposed browser sidebar WebView
11:57:42.369  browser sidebar guest torn down
11:57:42.383  renderer removed browser sidebar WebView; tabType=closed
11:57:42.384  browser sidebar page closed
11:57:42.385  browser lifecycle action=closed; appBrowserUseTabCount=0
11:57:42.389  final desktop log entry (ordinary account/read response)
<end of log>

Windows AppModel-Runtime Event 217 records destruction of the complete Codex AppX container at 2026-08-02 20:57:42 JST, the same second as the final teardown entries. The application was launched again through normal Shell activation at 20:59:27 JST.

Negative evidence

There was no corresponding:

• Windows Application Error, Application Hang, or WER event;
• display-driver reset/TDR, GPU, or relevant System-log error;
• render process gone, Codex CLI process exited, fatal-error, OOM, or heap error in the desktop log;
• crash dump or queued Sentry crash payload found for this occurrence.

The log contains 44 Browser Use PiP events/failures and 17 IAB API lifecycle entries during the session. The key distinction from earlier reports is that this failure followed repeated attempts to handle a JavaScript dialog that was no longer present, then the normal-looking automatic/manual-reason teardown sequence. The user also reports that similar disappearances often happen during the agent's final verification step, which is consistent with Browser Use cleanup/finalization being the trigger boundary.

I am not claiming the dialog errors alone cause the termination. They may leave stale Browser Use state that makes the subsequent guest-WebContents teardown unsafe. The exact termination remains silent, but the temporal correlation with the teardown is precise.

Direct reproduction on 26.727.6591.0: successful empty finalization followed by same-second whole-host termination

I observed another occurrence on the current Windows Store/MSIX build. This one is tightly coupled to an explicit browser.tabs.finalize({keep:[]}) call and closely matches the primary report.

Environment

• Codex Desktop/MSIX: OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0
• Bundled Browser release: 26.727.51351
• Bundled Chromium/desktop runtime: 150.0.7871.182
• Windows x64, build 22631
• GPU: NVIDIA GeForce RTX 4080 SUPER, driver 32.0.15.9186
• Browser backend: Codex in-app Browser (IAB)

Failure-boundary timeline

Codex timestamps below are UTC on 2026-08-03:

16:20:53.189  browser.tabs.finalize({keep:[]}) invoked
16:20:53.221  IAB debugger listener unregistered; reason=manual;
              webContentsDestroyed=false
16:20:53.222  Browser Use active state changed to false
16:20:53.223  finalization tool item marked completed
16:20:53.233  renderer synced Browser Use WebView state
16:20:53.233  renderer disposed browser sidebar WebView
16:20:53.235  successful tool output persisted
16:20:53.237  browser sidebar guest torn down
16:20:53.239  renderer removed browser sidebar WebView; tabType=closed
16:20:53.240  browser sidebar page closed
16:20:53.240  browser lifecycle action=closed;
              appBrowserTabCount=6; appBrowserUseTabCount=0
16:20:53.692  final app-server log entry during an otherwise active turn
<desktop/app-server logs stop abruptly>

Windows AppModel-Runtime then recorded Event 217 destroying the complete Codex AppX container at approximately 16:20:54 UTC. A local watchdog relaunched the package 45 seconds later.

The main Codex window was focused and visible during teardown. Six non-Browser-Use app browser tabs remained according to the final analytics event, so this was not a normal last-window/last-app-tab exit.

Lifecycle clue

As in the original report, the closed IAB tab was still logged under a temporary client-new-thread:<redacted> conversation owner while the active Browser Use turn belonged to the real persisted thread. This may be relevant to a stale route/owner alias or double-teardown race.

Negative evidence

I found no corresponding:

• graceful shutdown, quit, relaunch, cancellation, fatal, panic, renderer-gone, or OOM marker;
• Windows Application Error, Application Hang, Reliability Monitor, WER, System warning/error, GPU reset, or resource-exhaustion event;
• Crashpad dump or queued crash report;
• package update or remediation event.

The package remained healthy and the version was unchanged. The active task transcript and working data survived, but the running turn was interrupted with the rest of the desktop-owned process tree.

This is a new same-build reproduction distinct from the delayed occurrence already reported above: the AppX container disappeared in the same second as the successful finalization/WebView teardown. Full local logs are retained but not attached publicly because they contain prompts, paths, and session metadata. Targeted sanitized excerpts can be provided if maintainers request them.

Second direct reproduction on 26.727.6591.0: closed IAB tab was immediately re-registered before whole-host termination

I observed another occurrence on the same Windows Store/MSIX build as my previous reproduction. This time the final lifecycle sequence contains a stronger re-entrancy/state-race clue: the Browser Use sidebar tab was torn down and logged as closed, then the same browser tab was immediately registered/opened again under the temporary client-new-thread:<redacted> owner just before the entire AppX container disappeared.

Environment

• Codex Desktop/MSIX: OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0
• Bundled Browser release: 26.727.51351
• Windows x64, build 22631
• Browser backend: Codex in-app Browser (IAB)

Failure-boundary timeline

Codex timestamps below are UTC on 2026-08-04:

15:42:24.594  browser.tabs.finalize({ keep: [] }) invoked
15:42:24.625  debugger listener unregistered; reason=manual;
              webContentsDestroyed=false
15:42:24.627  Browser Use active state changed to false
15:42:24.633  renderer synced Browser Use WebView state
15:42:24.654  registry rebound browser sidebar window
15:42:24.661  renderer backgrounded and disposed browser sidebar WebView
15:42:24.665  browser sidebar guest torn down
15:42:24.674  renderer removed sidebar WebView; page closed
15:42:24.674  lifecycle action=closed;
              appBrowserTabCount=2; appBrowserUseTabCount=0;
              owner=client-new-thread:<redacted>

15:42:24.685  registry rebound browser sidebar window
15:42:24.685  same browser sidebar tab registered again;
              owner=client-new-thread:<redacted>
15:42:24.685  lifecycle action=opened;
              appBrowserTabCount=3; appBrowserUseTabCount=0;
              isBrowserUseTab=false; threadBrowserTabCount=1
15:42:24.697  successful finalization output persisted
15:42:24.707  owner sync changed route to the real persisted thread
15:42:24.717  registry rebound browser sidebar window
<desktop log stops abruptly>

Windows AppModel-Runtime Event 217 recorded destruction of the complete Codex AppX container at approximately 15:42:25 UTC. A watchdog started a new instance at 15:42:42 UTC, 17 seconds later. The package version was unchanged.

The main window was visible but not focused. Two other app-browser tabs still existed when the IAB tab was logged as closed, so this was not a normal last-window or last-app-tab exit.

Negative evidence

As with the previous occurrence, I found no corresponding:

• graceful shutdown, quit, relaunch, fatal, panic, renderer-gone, or OOM marker;
• Windows Application Error, Application Hang, or WER event;
• Crashpad report or standard crash dump;
• package update or remediation event.

The close-then-immediate-reopen sequence, using the same browser tab identity while changing it from Browser Use state to a non-Browser-Use registration and then synchronizing ownership to the real thread, appears consistent with a re-entrant teardown, stale owner alias, or double-registration race. I cannot prove the native root cause, but this transition occurs within 43 ms of the explicit finalization call and immediately precedes whole-host termination.

Newer-build reproduction: automatic session-activity-ended teardown also crashes the browser process

Adding a newer-build reproduction and an important scope correction: this failure is not limited to an explicit browser.tabs.finalize(...) call.

Environment

• Codex Desktop/MSIX: OpenAI.Codex_26.803.5235.0_x64
• Browser Use release: 26.803.41515
• App server: 0.147.0-alpha.6.5
• Windows: 10.0.26200.8875, x64

Key finding

In the latest occurrence, the affected IAB activity began at 14:16:17Z. From that point until the crash, there were zero live browser.tabs.finalize calls. The actual cleanup reason recorded by the desktop log was session-activity-ended.

Any textual occurrences of browser.tabs.finalize in this app session were inside historical task-response payloads loaded earlier, not calls executed during the affected browser-use session.

Sanitized failure-boundary timeline (UTC, 2026-08-07):

14:21:12.876  [browser-use-iab-api] debugger listener unregistered
              reason=session-activity-ended
              webContentsDestroyed=false
14:21:12.879  [browser-session-registry] browser-use session activity ended
              disposeAfterSessionActivity=false
14:21:13.170  turn-complete notification emitted
14:21:13.250  renderer disposed browser sidebar webview
14:21:13.260  browser sidebar guest torn down
14:21:13.282  renderer removed browser sidebar webview
14:21:13.283  browser sidebar page closed
              appBrowserTabCount=0
14:21:13.291  final desktop log entry
14:21:13.789  Crashpad sidecar created

The same-second Crashpad sidecar contains:

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

I currently have seven retained Crashpad sidecars from August 4–7. Every one reports capture_kind=crash and ptype=browser. Earlier correlated occurrences also ended immediately after IAB/webview teardown, some through explicit finalization; this occurrence shows that normal end-of-turn cleanup reaches the same failing path.

One suspicious lifecycle detail is that the registry records disposeAfterSessionActivity=false, but the renderer disposes the webview about 371 ms later anyway. Immediately before the crash window, the desktop log also contains repeated unknown conversation / conversation state not found events while other task events were still arriving.

This is consistent with, but does not by itself prove, a lifecycle/ownership or re-entrant cleanup race along:

browser-use-iab-api → browser-session-registry → renderer / guest WebContents teardown

Impact

The Electron browser/main process crashes, the entire Codex Desktop app exits, and unrelated active tasks are interrupted. There is no normal task-level error or graceful shutdown.

Expected behavior

Automatic Browser Use session cleanup should release the IAB webview without terminating Codex Desktop or interrupting unrelated tasks.

Current workaround

Avoid Codex IAB/Browser Use entirely. Merely avoiding explicit browser.tabs.finalize is not sufficient on this build.

Full logs are retained locally. I have not attached raw logs because they contain local paths, prompts, and conversation identifiers, but I can provide targeted sanitized excerpts if maintainers request them.

Additional recurrence on 26.803.10989.0 with a main/browser Crashpad record

I reproduced this failure on a substantially newer Windows Store/MSIX build. This machine has now produced three whole-app crashes with the same Browser Use teardown correlation, including two on the current package.

Environment

• ChatGPT/Codex Desktop MSIX: OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0
• ChatGPT.exe file/product version: 151.0.7922.76
• Windows 11 Pro 25H2, x64, build 26200.8875
• Browser backend: bundled in-app Browser (iab)

Crash records

Local Crashpad created three sidecars:

• 2026-08-12 12:24:27 MYT
• 2026-08-13 00:13:19 MYT
• 2026-08-13 03:10:25 MYT

All three contain:

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

The first occurrence was on package 26.803.5235.0. The latter two occurred after updating to 26.803.10989.0, so the update did not remove the failure.

Latest failure boundary

The latest desktop log used UTC timestamps. Two Browser Use tabs were torn down together:

2026-08-12T19:10:24.430Z IAB_LIFECYCLE unregistered debugger listener ... tabId=1 ... webContentsDestroyed=false
2026-08-12T19:10:24.431Z IAB_LIFECYCLE unregistered debugger listener ... tabId=2 ... webContentsDestroyed=false
2026-08-12T19:10:24.434Z IAB_LIFECYCLE syncing browser use active state ... isActive=false  [both tabs]
2026-08-12T19:10:24.434Z IAB_LIFECYCLE renderer disposed browser sidebar webview
2026-08-12T19:10:24.441Z IAB_LIFECYCLE browser sidebar guest torn down ... guestWebContentsId=4
2026-08-12T19:10:24.451Z IAB_LIFECYCLE renderer disposed browser sidebar webview
2026-08-12T19:10:24.455Z IAB_LIFECYCLE browser sidebar guest torn down ... guestWebContentsId=5
2026-08-12T19:10:24.462Z IAB_LIFECYCLE renderer removed browser sidebar webview ... tabType=closed
2026-08-12T19:10:24.463Z IAB_LIFECYCLE closed browser sidebar page
2026-08-12T19:10:24.463Z IAB_TAB_ANALYTICS ... appBrowserUseTabCount=0
<end of desktop log>

Crashpad wrote the ptype=browser sidecar about one second later. There is no graceful-shutdown, fatal, panic, or OOM marker at the failure boundary.

During that session, the desktop log also contained:

• 9 instances of Cannot find context with specified id from browser-use-iab-api
• 52 instances of Failed to upsert Browser Use PiP content

Those warnings may be lifecycle clues, but I am not claiming they are independently causal.

Windows/AppX state

This does not appear to be an AppX activation failure. The package launches successfully, and AppModel Runtime records normal creation of the OpenAI.Codex Desktop AppX container after relaunch. No 0x80070020 or equivalent launch/configuration error occurred at these failure boundaries.

The strongest differentiator in the latest occurrence is multi-tab Browser Use teardown: two IAB guests were disposed nearly simultaneously, immediately before the browser main process crash.

Raw desktop logs and local artifacts are retained, but are not attached publicly because they contain project URLs, local paths, and conversation identifiers. Targeted sanitized excerpts can be provided if maintainers request them.

Installed-package static analysis: likely re-entrant guest WebContents close during multi-tab teardown

I inspected the packaged Electron application from the latest occurrence. This adds a concrete code-level hypothesis to the crash evidence previously reported here.

Environment inspected

• Windows MSIX: OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0
• Packaged app bundle version: 26.803.81509 (build 6415)
• Electron: 42.3.0
• Chromium/file version: 151.0.7922.76
• Crashpad sidecar for this occurrence: capture_kind=crash, ptype=browser, osarch=x86_64

The public openai/codex source tree does not contain these desktop IAB modules, but the installed app.asar preserves the relevant class and method names.

Verified packaged-code path

The Browser Use finalization path in the packaged main-process bundle is:

1. browser-use-iab-api.finalizeTabs()
2. Snapshot all session tabs and process them using Promise.allSettled(tabs.map(...))
3. For each unkept agent tab:

• cleanupDebuggerForTabBestEffort(tab, "finalize-tabs")
• closeTab(tab)

1. closeTab() calls closePageForBrowserUse()
2. browser-sidebar-manager calls requestThreadTeardown(..., "closed")
3. The renderer receives browser-sidebar-destroy-webview, disposes/removes the <webview>, and sends browser-sidebar-webview-destroyed
4. The main process handles that acknowledgement through:

• browserSidebarWebviewDestroyed()
• finalizeThreadTeardown()

Suspicious ordering mismatch

Inside finalizeThreadTeardown(), the packaged code effectively performs:

const guest = page?.view.webContents;
if (guest && !guest.isDestroyed()) guest.close();
page.dispose();

However, the same bundle's general disposeBrowserPage() helper uses the opposite order:

const guest = page.view.webContents;
page.dispose();
if (guest && !guest.isDestroyed()) guest.close();

page.dispose() removes the registered destroyed, navigation, load, input, capture, favicon, render-process, and other listeners from that guest.

This means the final-ack path calls guest.close() before detaching the page observers, after the renderer has already removed the embedding <webview>. In contrast, the normal disposal helper removes observers first.

Electron 42.3.0's native source makes this distinction relevant:

• for an attached OOPIF guest, the underlying WebContents is released by the embedder frame;
• webContents.close() directly calls Chromium's synchronous content::WebContents::Close();
• Electron's destroy() path explicitly defers deletion when necessary to avoid destroying a WebContents while it is emitting an event.

Relevant Electron source:
https://github.com/electron/electron/blob/v42.3.0/shell/browser/api/electron_api_web_contents.cc#L1063-L1129

Exact correlation with the latest crash

The final desktop log shows two IAB guests being finalized in the same route:

19:10:24.430  debugger listener unregistered, tab 1, webContentsId=4
19:10:24.431  debugger listener unregistered, tab 2, webContentsId=5
19:10:24.433  browser use active=false, tab 1
19:10:24.434  browser use active=false, tab 2
19:10:24.434  renderer disposed webview, tab 1
19:10:24.441  guest torn down, webContentsId=4
19:10:24.451  renderer disposed webview, tab 2
19:10:24.455  guest torn down, webContentsId=5
19:10:24.463  second page closed; appBrowserUseTabCount=0
<desktop log ends>

Crashpad created a browser/main-process crash sidecar approximately one second later. There is no graceful shutdown, fatal JS exception, panic, or OOM marker at the boundary.

Assessment

Verified:

• finalizeTabs() initiates per-tab cleanup concurrently.
• The renderer removes each embedding <webview> before the main-process final acknowledgement handler runs.
• finalizeThreadTeardown() can then call guest.close() before removing page observers.
• The two guests were torn down within approximately 25 ms, immediately before the browser/main process crashed.

Strong hypothesis, not yet native-symbol proof:

The renderer-driven embedder removal begins guest destruction, but the main-process wrapper can still temporarily report isDestroyed() === false. finalizeThreadTeardown() then synchronously closes that guest again while listeners and another tab teardown are active. Multi-tab Promise.allSettled(...) finalization substantially widens this re-entrant/double-close race.

This is consistent with the 0xC0000005 / freed-memory-pattern native dump reported in #34239, but I am not claiming the exact native faulting function is identical without a full dump from this occurrence.

Suggested fix/test direction

• Make guest teardown a single-owner, idempotent state machine.
• Detach page observers before any explicit webContents.close().
• Do not explicitly close a guest after the renderer confirms removal of its embedding <webview>, unless ownership is still unambiguous.
• Serialize finalization per route, or await each guest's actual destroyed transition before closing the next tab.
• Add a Windows Electron regression test that finalizes 2+ IAB tabs in the same route and asserts the browser process remains alive.

This appears to narrow the trigger from the general Browser Use API to browser-sidebar-manager.finalizeThreadTeardown(), with multi-tab concurrency in browser-use-iab-api.finalizeTabs() acting as the amplifier.

Confirmed recurrence on 26.803.10989.0 / Browser Use 26.803.81509 — native main-process crash after stateful multi-tab finalize

This reproduced again on the current Windows MSIX build. Unlike the July occurrence, no undeclared-variable/orphan-handle mistake was involved: the documented browser.tabs.finalize(...handoff...) API returned success, then the app crashed during deferred multi-WebView teardown.

Environment and native signature

• MSIX: OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0
• Codex / Browser Use release: 26.803.81509 (dist 6415)
• Electron: 42.3.0
• Chromium: 151.0.7922.76
• Main/browser process PID: 6156
• Crash time: 2026-08-13 23:07:02 MSK / 20:07:02Z
• Exception: 0xC0000005 read access violation
• Attempted address: 0xFFFFFFFFFFFFFFFF
• Fault: chrome.dll+0xF3CA304
• Sentry event ID: 12dc8af118a9456c8eeab1b7a100bf56
• Crashpad: capture_kind=crash, ptype=browser, osarch=x86_64

This matches the July native fingerprint in exception class, operation, bad address, process type, and module. The module offset changed with the newer Chromium binary, so identical source function is not claimed without private symbols.

Exact trigger and failure boundary

The active task called:

await browser.tabs.finalize({
  keep: [{ tab: sportradarTab, status: "handoff" }]
});

The call returned successfully in about 35 ms with sessionEnded:true and, unexpectedly for the requested handoff, openTabIds:[].

Immediately afterward:

1. IAB repeatedly rejected stale tab IDs 1, 2, and 3 for the active session; each had tabRouteKey=null.
2. The backend reported Tab 3 is not part of browser session ....
3. Debugger listeners were unregistered for four live Browser Use tabs and the handoff/user tab.
4. The handoff page was released.
5. Four Browser Use WebViews/guest WebContents were disposed nearly concurrently.
6. Browser Use tab count fell 4 -> 3 -> 2 -> 1 -> 0.
7. The desktop log ended on the last close at 20:07:01.986Z; Crashpad captured the browser/main-process crash in the next second.
8. Windows AppModel Runtime Event 217 then destroyed the Codex AppX container.

Sentry breadcrumbs add a strong state-corruption clue: shortly before finalization, IAB had 5 pages / 5 guest WebContents but only 4 session routes. No pages were loading. This was a route/page ownership mismatch before teardown, not a navigation crash.

Important control

After relaunch, the same long-running task reclaimed the handoff tab and invoked the same finalize/handoff pattern again in a fresh process. That call succeeded and the process survived. Therefore finalize() is not universally fatal; the failure is state-dependent and is amplified by stale route mappings plus multi-tab teardown.

Assessment

Confirmed:

• native main/browser-process crash, not a normal quit, renderer-only failure, GPU reset, or JavaScript exception;
• crash immediately follows successful documented IAB finalization;
• stale route/tab state and concurrent teardown were present at the boundary;
• the same native crash class persists across multiple Codex/Chromium releases.

Strong hypothesis (source-level symbol confirmation still needed):

The stateful multi-tab finalization path is hitting the re-entrant guest-WebContents close race described in this issue: renderer-side WebView removal begins guest destruction while the main-process acknowledgement path can still synchronously close the guest, with several tabs finalized concurrently. Stale route/page ownership widens that race.

Requested maintainer action

Please correlate Sentry event 12dc8af118a9456c8eeab1b7a100bf56 with this issue and advise whether a fix is planned or whether a supported non-crashing workaround exists. In particular, a Windows regression test should cover:

• 4+ IAB Browser Use tabs in one long-lived task,
• stale/missing route mappings,
• finalize({keep:[...handoff...]}),
• assertion that the main browser process remains alive and the handoff tab remains open.

Raw envelope, minidump, desktop log, URLs, local paths, and conversation metadata are retained locally and are intentionally not attached publicly.