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

[alex-sc7]

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:

1. await browser.tabs.finalize({keep:[]});
2. await browser.tabs.finalize({});

In both cases the tool call itself returned successfully before the desktop process disappeared.

Steps to reproduce

1. Start Codex Desktop on Windows.
2. Run a task that uses the bundled in-app Browser Use backend.
3. Optionally keep another task running in a different project (this makes the cross-task impact visible).
4. At the end of Browser Use, run:

await viewport.reset();
await browser.tabs.finalize({});

5. 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 interrupted with 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.

[github-actions]

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

• [Windows desktop] Closing in-app Browser tab silently terminates Codex during WebView teardown #34239

Powered by Codex Action

[Paxmark]

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]

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.

[User1122113]

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.