Repository navigation
[Windows][Codex Desktop][IAB] browser.tabs.finalize() silently terminates the entire app #35210
Description
Environment
- Codex Desktop package:
26.721.3996.0(Microsoft Store / MSIX, x64) - Bundled Browser Use release:
26.721.31836 - OS: Windows 11 x64
- Authentication/subscription: ChatGPT account in Codex Desktop (tier intentionally omitted)
What issue are you seeing?
Calling browser.tabs.finalize(...) from the bundled in-app browser (iab) can silently terminate the entire Codex Desktop AppX process tree, not just close the browser tabs. Any other concurrently running Codex tasks are interrupted at the same time.
There is no crash dialog. Windows does not record an Application Error / WER crash, and no crash dump is produced. The AppModel Runtime log only shows that the Codex AppX container was destroyed.
This has reproduced twice on the same build with two different forms of empty finalization:
await browser.tabs.finalize({keep:[]});await browser.tabs.finalize({});
In both cases the tool call itself returned successfully before the desktop process disappeared.
Steps to reproduce
- Start Codex Desktop on Windows.
- Run a task that uses the bundled in-app Browser Use backend.
- Optionally keep another task running in a different project (this makes the cross-task impact visible).
- At the end of Browser Use, run:
await viewport.reset();
await browser.tabs.finalize({});- Observe that the tool call completes, the IAB guest/webview is torn down, and then the entire Codex Desktop process exits. Other active tasks become
interruptedwith no task-level error.
Deterministic timing evidence
Occurrence A
browser.tabs.finalize({keep:[]})starts- the desktop log stops approximately 156 ms later
- Windows AppModel Runtime then records the Codex AppX container being destroyed
Occurrence B
browser.tabs.finalize({})starts- Browser Use returns successfully
- the function-call output is persisted
- the final desktop log is written approximately 151 ms after the call began
- Windows AppModel Runtime then records the Codex AppX container being destroyed
- Codex relaunches into a new AppX container
Sanitized final lifecycle sequence from occurrence B:
IAB_LIFECYCLE unregistered debugger listener ... reason=manual ... webContentsDestroyed=false
IAB_LIFECYCLE syncing browser use active state ... isActive=false
IAB_LIFECYCLE renderer synced browser use webview state ... isBrowserUseActive=false
IAB_LIFECYCLE renderer disposed browser sidebar webview
IAB_LIFECYCLE browser sidebar guest torn down
IAB_LIFECYCLE renderer removed browser sidebar webview ... tabType=closed
IAB_LIFECYCLE closed browser sidebar page
IAB_TAB_ANALYTICS browser tab lifecycle action=closed ... appBrowserTabCount=2 appBrowserUseTabCount=0
The last call was recorded as completed; no task cancellation, interrupt request, fatal log, OOM event, WER report, or crash dump preceded the container destruction.
Possible lifecycle clue
The IAB registry initially creates/captures a browser route under a temporary client-new-thread:<uuid> conversation ID. After the real thread is created, logs show route reassignment/rebinding between the real thread ID and that temporary client ID. During finalization, the closed browser tab is still logged under the temporary client-new-thread:<uuid> ID while the active Browser Use turn belongs to the real thread.
This may be a stale route/owner alias or teardown bug in the Windows IAB lifecycle path.
Expected behavior
browser.tabs.finalize(...) should close/release only the requested Browser Use tabs. Codex Desktop, app-server, unrelated browser tabs, and other running tasks must remain alive.
Impact
- All concurrent tasks are interrupted.
- Long-running work must be manually resumed.
- The failure looks like a user cancellation even though no cancel/interrupt was requested.
- No diagnostic crash artifact is generated.
Both interrupted task transcripts and repository working trees remained intact after relaunch; SQLite integrity checks passed.
Workaround
A durable local instruction now prevents agents on this build from calling browser.tabs.finalize(...) for the IAB backend and leaves IAB tabs open. Browser Use otherwise remains functional. No further whole-app exit has occurred since applying that workaround.
Related issues
- [Windows] Codex desktop app crashes / closes automatically on launch or during use #24998 — similar Windows silent close after a task finishes, but without this deterministic
browser.tabs.finalize(...)trigger - Codex Desktop Windows: repeated silent app/window closes and sidechat becomes non-interactive after running #23814 — related Windows browser/sidebar lifecycle churn and silent app/session closes
I have retained the original local desktop logs and session transcripts. Full logs are not attached publicly because they may contain local paths, prompts, and environment metadata; targeted sanitized excerpts can be provided if maintainers request them.
Activity
github-actions commentedon Jul 24, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Paxmark commentedon Jul 24, 2026
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.
Nyaruko893 commentedon Jul 28, 2026
Independent same-build occurrence with a within-process counterexample
I observed another silent whole-host termination with the following environment:
26.721.4979.0x6426.721.4105926200.8875Incident timeline
All timestamps below are from
2026-07-28UTC:21:26:07.785—browser.tabs.finalize({ keep: [] })was invoked21:26:07.826— the call returned successfully withsessionEnded:true21:26:07.871,.888, and.903— three IAB tabs closed sequentially; the app tab count changed from2 -> 1 -> 021:26:07.908— the desktop log stopped without a graceful-shutdown, fatal-error, or process-exit markerI found no corresponding:
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— identicalbrowser.tabs.finalize({ keep: [] })sessionEnded:trueThe main observed differences were:
Both occurrences used the same temporary
client-new-threadroute.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.
User1122113 commentedon Jul 30, 2026
Newer-build reproduction:
browser.tabs.finalize()/ IAB teardown still terminates the app on26.721.11231.0I 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
OpenAI.Codex_26.721.11231.0_x64__2p2nqsd0c76g026200.8973UTC+09:00)Trigger
iab).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:
Time from the final Codex log entry to AppX container destruction: approximately
0.502 s.Occurrence 2:
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
Recoverable Chromium child process goneentry.processType=GPUcrash/relaunch-failure entry.NeedsRemediationentry in either terminal desktop log.Application Error, WER, orApplication Hangevent.Status: Ok.Installed-package close-path inspection
Static inspection of the installed package shows the Browser Use cleanup path is two-stage:
closeTab()/closePageForBrowserUse().<webview>and reports that destruction back to the main process.webContentsand closes it if it is not already destroyed.I did not find an explicit
app.quit(),app.exit(), orprocess.exit()in this Browser Use close path. The Windowswindow-all-closedhandler also does not intentionally quit the application. Together withrendererWindowVisible=truein 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-
webContentsteardown 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.
millionart commentedon Aug 2, 2026
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
OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g026.727.5135126200Timeline
09:43:35.056—browser.tabs.finalize({ keep: [] })invoked.09:43:35.252— call returned successfully withsessionEnded:trueandopenTabIds:[].09:43:40— the controlled IAB guest/tab teardown had completed normally.09:46:28— the agent turn wrote its final response andtask_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;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.ponpaku commentedon Aug 2, 2026
Additional reproduction on
26.727.6591.0: dialog-handling failures immediately before automatic IAB teardownI 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
OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g026.727.51351150.0.7871.18225H2, build26200.8875595.79UTC+09:00)Failure sequence
Codex timestamps below are UTC on
2026-08-02: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 at20:59:27 JST.Negative evidence
There was no corresponding:
render process gone,Codex CLI process exited, fatal-error, OOM, or heap error in the desktop log;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.
Jinkx commentedon Aug 3, 2026
Direct reproduction on
26.727.6591.0: successful empty finalization followed by same-second whole-host terminationI 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
OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g026.727.51351150.0.7871.1822263132.0.15.9186Failure-boundary timeline
Codex timestamps below are UTC on 2026-08-03:
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:
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.
Jinkx commentedon Aug 4, 2026
Second direct reproduction on
26.727.6591.0: closed IAB tab was immediately re-registered before whole-host terminationI 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
OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g026.727.5135122631Failure-boundary timeline
Codex timestamps below are UTC on 2026-08-04:
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 at15: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:
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.
Jackeyyyyyyyyyy commentedon Aug 7, 2026
Newer-build reproduction: automatic
session-activity-endedteardown also crashes the browser processAdding a newer-build reproduction and an important scope correction: this failure is not limited to an explicit
browser.tabs.finalize(...)call.Environment
OpenAI.Codex_26.803.5235.0_x6426.803.415150.147.0-alpha.6.510.0.26200.8875, x64Key finding
In the latest occurrence, the affected IAB activity began at
14:16:17Z. From that point until the crash, there were zero livebrowser.tabs.finalizecalls. The actual cleanup reason recorded by the desktop log wassession-activity-ended.Any textual occurrences of
browser.tabs.finalizein 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):
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=crashandptype=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 repeatedunknown conversation/conversation state not foundevents 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 teardownImpact
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.finalizeis 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.
jhchong0405 commentedon Aug 13, 2026
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
OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0ChatGPT.exefile/product version:151.0.7922.7626200.8875iab)Crash records
Local Crashpad created three sidecars:
2026-08-12 12:24:27 MYT2026-08-13 00:13:19 MYT2026-08-13 03:10:25 MYTAll 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 to26.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:
Crashpad wrote the
ptype=browsersidecar 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:
Cannot find context with specified idfrombrowser-use-iab-apiFailed to upsert Browser Use PiP contentThose 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.CodexDesktop AppX container after relaunch. No0x80070020or 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.
jhchong0405 commentedon Aug 13, 2026
Installed-package static analysis: likely re-entrant guest
WebContentsclose during multi-tab teardownI 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
OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g026.803.81509(build6415)42.3.0151.0.7922.76capture_kind=crash,ptype=browser,osarch=x86_64The public
openai/codexsource tree does not contain these desktop IAB modules, but the installedapp.asarpreserves the relevant class and method names.Verified packaged-code path
The Browser Use finalization path in the packaged main-process bundle is:
browser-use-iab-api.finalizeTabs()Promise.allSettled(tabs.map(...))cleanupDebuggerForTabBestEffort(tab, "finalize-tabs")closeTab(tab)closeTab()callsclosePageForBrowserUse()browser-sidebar-managercallsrequestThreadTeardown(..., "closed")browser-sidebar-destroy-webview, disposes/removes the<webview>, and sendsbrowser-sidebar-webview-destroyedbrowserSidebarWebviewDestroyed()finalizeThreadTeardown()Suspicious ordering mismatch
Inside
finalizeThreadTeardown(), the packaged code effectively performs:However, the same bundle's general
disposeBrowserPage()helper uses the opposite order:page.dispose()removes the registereddestroyed, 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:
WebContentsis released by the embedder frame;webContents.close()directly calls Chromium's synchronouscontent::WebContents::Close();destroy()path explicitly defers deletion when necessary to avoid destroying aWebContentswhile 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:
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.<webview>before the main-process final acknowledgement handler runs.finalizeThreadTeardown()can then callguest.close()before removing page observers.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-tabPromise.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
webContents.close().<webview>, unless ownership is still unambiguous.destroyedtransition before closing the next tab.This appears to narrow the trigger from the general Browser Use API to
browser-sidebar-manager.finalizeThreadTeardown(), with multi-tab concurrency inbrowser-use-iab-api.finalizeTabs()acting as the amplifier.Cataphract450 commentedon Aug 13, 2026
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
OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g026.803.81509(dist6415)42.3.0151.0.7922.7661562026-08-13 23:07:02 MSK/20:07:02Z0xC0000005read access violation0xFFFFFFFFFFFFFFFFchrome.dll+0xF3CA30412dc8af118a9456c8eeab1b7a100bf56capture_kind=crash,ptype=browser,osarch=x86_64This 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:
The call returned successfully in about 35 ms with
sessionEnded:trueand, unexpectedly for the requested handoff,openTabIds:[].Immediately afterward:
1,2, and3for the active session; each hadtabRouteKey=null.Tab 3 is not part of browser session ....4 -> 3 -> 2 -> 1 -> 0.20:07:01.986Z; Crashpad captured the browser/main-process crash in the next second.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:
Strong hypothesis (source-level symbol confirmation still needed):
The stateful multi-tab finalization path is hitting the re-entrant guest-
WebContentsclose 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
12dc8af118a9456c8eeab1b7a100bf56with 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:finalize({keep:[...handoff...]}),Raw envelope, minidump, desktop log, URLs, local paths, and conversation metadata are retained locally and are intentionally not attached publicly.
Cataphract450 commentedon Aug 29, 2026
Update: third native Browser Use teardown crash on 26.825 (2026-08-29)
A third whole-app crash occurred on 2026-08-29 02:34:48.671 MSK (2026-08-28 23:34:48.671 UTC), following the previously reported July 29 and August 13 crashes.
New crash identifiers
b8db58cc-eb29-4c8e-909e-7b03ce74d11a4ac84c08e01f49679ca33ecb8410da4dbrowser(PID 22484)capture_kind=crash,level=fatal,platform=native,exit.reason=crashedOpenAI.Codex_26.825.4187.0_x6426.825.32147(dist 7345)151.0.7922.174What changed in this reproduction
This occurrence did not involve the July orphan-tab sequence and did not call
browser.tabs.finalize()or an explicit tabclose(). There was exactly one Browser Use tab.On task completion, Codex automatically performed this sequence:
Browser Use active=false→ session activity ended → debugger listener unregistered (tabId=2, guestWebContentsId=7,destroyed=false) → renderer disposed the Browser WebView → guest torn down → tab removed/closed (1 → 0).The main-process log then ended abruptly, and Crashpad recorded the browser-process crash approximately 0.9 seconds later.
Earlier in the same session, internal routing/context errors included
tabRouteKey=null, “No ChatGPT browser route is available”, and “Cannot find context”.Across all three occurrences, the common invariant is now the Browser Use guest-WebContents teardown/session-route lifecycle. Multiple tabs, an orphan tab, explicit
close(), andbrowser.tabs.finalize()are not required conditions.The two earlier crashes were native
0xC0000005reads at0xFFFFFFFFFFFFFFFFinchrome.dll. The August 29 minidump was not retained, so I cannot claim that its exact exception or stack is identical. Please correlate the Sentry event internally.No Windows WHEA, display/GPU-reset, OOM, disk, or NTFS errors were recorded around this crash.
After restart, the installed MSIX is
26.825.5331.0. No newer crash has been observed yet, but this does not establish that the defect is fixed.Could the Codex Desktop / Browser Use team please investigate guest-WebContents teardown and stale route/session state, and correlate Sentry event
4ac84c08e01f49679ca33ecb8410da4dwith the two earlier reports?