[Windows] Finalizing the last in-app Browser Use tab closes/restarts Codex Desktop

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

• #36645

Powered by Codex Action

I can confirm the same failure on two newer Codex Desktop builds.

• At least 10 abnormal app exits during the past week.
• Four surviving Crashpad sidecars explicitly classify the failures as Electron browser-process crashes.
• Three crashes occurred on 26.814.5517.0; the latest occurred on 26.818.3698.0, so the update did not resolve it.
• The latest two crashes share the same final sequence: failed PiP updates and stale CDP contexts, reason=target-close, browser guest teardown, route rejection with tabRouteKey=null, Browser Use tab count reaching zero, immediate browser-host recreation, undefined PiP tab metadata, then a Crashpad browser-process crash within about one second.
• codex doctor passed the relevant checks, and Windows System, Defender, Code Integrity, AppLocker, and Resource Exhaustion logs contained no matching event.
• The sandbox ACL state was valid after the latest crash, so that was not the trigger.

I have attached a privacy-reviewed evidence bundle containing the full report, two targeted log excerpts, four 60-byte Crashpad sidecars, and SHA-256 checksums. It excludes full logs, transcripts, prompts, responses, credentials, configuration, and browser-profile data.

codex-desktop-crash-20260821.zip

I can confirm this is still reproducible on a newer Windows build, and I was able to narrow the lifecycle condition with a controlled A/B test.

Environment

• Microsoft Store package: OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0
• Electron/Chromium executable version: 151.0.7922.170
• Windows x64
• Built-in managed Browser Use / IAB backend

Reproduction: last managed Browser Use tab

A realistic localhost Browser Use workflow completed successfully:

• login/authentication;
• multiple GET/POST interactions;
• several pages/navigations;
• DOM/state observations;
• no download;
• no print.

Immediately before closing the only managed Browser Use tab, an external marker was persisted:

22:37:50.833 REALISTIC_NO_DOWNLOAD_WORKFLOW_CONFIRMED
22:37:51.814 BEFORE_TAB_CLOSE

There was no AFTER_TAB_CLOSE.

Desktop lifecycle logging then showed:

IAB_LIFECYCLE unregistered debugger listener ... reason=target-close
IAB_LIFECYCLE syncing browser use active state ... isActive=false
IAB_LIFECYCLE iab rejected tab for route ... tabRouteKey=null
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=1
    appBrowserUseTabCount=0

A normal/non-Browser-Use app-browser tab was still present (appBrowserTabCount=1), so merely keeping an ordinary sidebar browser tab alive did not prevent the crash.

Approximately one second later the Codex AppX container was destroyed.

Crash evidence

This reproduction preserved a Crashpad minidump rather than only the usual 60-byte sidecar.

Crashpad sidecar:

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

Minidump:

thread:       CrBrowserMain
exception:    0xC0000005 ACCESS_VIOLATION
operation:    READ
module:       chrome.dll
version:      151.0.7922.170
RAX:          0xEFEFEFEFEFEFEFEF

The faulting instruction dereferenced the poisoned-looking RAX value. This is consistent with a dangling/use-after-free style native teardown failure.

Windows did not create a corresponding Application Error / WER crash record, but AppModel-Runtime recorded destruction of the OpenAI.Codex desktop AppX container immediately afterward.

Important control: 2 -> 1 managed tabs

I then ran a separate control designed specifically to distinguish:

• closing an arbitrary stateful managed Browser Use tab; from
• closing the last managed Browser Use tab.

Sequence:

1. Create managed TAB_A.
2. Run the complete realistic localhost workflow in TAB_A.
3. Create a second managed TAB_B sentinel on about:blank.
4. Confirm managed Browser Use count = 2.
5. Close TAB_A by its exact ID while TAB_B remains.
6. Confirm managed Browser Use count = 1.
7. Keep TAB_B open.
8. Stop all Browser Use calls.
9. Wait 30 seconds and complete the task normally.

Result:

2 managed Browser Use tabs
-> close stateful TAB_A
-> 1 managed Browser Use tab remains
-> PASS

Relevant persistent markers:

PRE_CLOSE_TWO_MANAGED_TABS_CONFIRMED
BEFORE_CLOSE_TAB_A
AFTER_CLOSE_TAB_A
MANAGED_COUNT_2_TO_1_CONFIRMED
SENTINEL_TAB_B_SURVIVED
BROWSER_TOOL_USE_FINISHED
POST_BROWSER_WAIT_END
BEFORE_FINAL_REPLY

The desktop lifecycle log also recorded the close with:

appBrowserUseTabCount=2
...
reason=target-close tabId=1
...
action=closed appBrowserUseTabCount=1

PiP metadata subsequently referenced the surviving managed tab (tabID=2).

The app remained healthy and the task reached its normal final response.

Current conclusion

The strongest supported boundary is therefore:

managed Browser Use count 1 -> 0 : CRASH
managed Browser Use count 2 -> 1 : PASS

This also shows that:

• downloads are not required to reproduce the crash;
• closing a realistic/stateful managed tab is not by itself sufficient;
• an ordinary non-Browser-Use sidebar tab is not an adequate survivor;
• preserving at least one managed Browser Use tab avoids the reproduced failure.

Current workaround on this build is to never finalize/close the final managed Browser Use tab.

If cleanup is needed, individual managed tabs can be closed while at least one other managed Browser Use tab is intentionally left alive.

I can corroborate this on the same current Windows build, with a variant that does not require an explicit tabs.finalize({ keep: [] }) call.

Environment

• Microsoft Store package: OpenAI.Codex_26.818.5229.0_x64__2p2nqsd0c76g0
• Desktop/browser runtime release in logs: 26.818.41509
• Windows x64
• Built-in managed Browser Use / IAB backend
• Microsoft Store reports no newer package available

Three browser-process crashes

Three separate failures occurred within one night:

2026-08-23 22:29:56.474 +08:00  fcb8bb14-02a2-478d-95b5-1784de46f0e5
2026-08-24 00:23:14.359 +08:00  d4fc5eb7-4bd1-4a2f-8146-a7ffba80b79b
2026-08-24 07:27:24.870 +08:00  2839c966-c787-4abc-8a6b-87a9c1523350

All three retained sidecars are identical:

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

Windows AppModel-Runtime event 217 destroyed the OpenAI.Codex AppX container immediately after each crash. There was no matching Application Error/WER event.

New reproduction boundary: automatic cleanup at a long-running goal transition

In all three cases, a long-running goal turn completed and Codex automatically started the next goal turn. The app automatically ended the managed Browser Use session at that boundary; the user did not manually close/finalize the tab.

Sanitized timeline from the third reproduction:

07:27:24.087 AgentMessage completed
07:27:24.139 task_complete
07:27:24.143 IAB ended Browser Use session activity
07:27:24.174 task_started (automatic long-running goal continuation)
07:27:24.219 renderer disposed Browser sidebar webview
07:27:24.224 Browser sidebar guest torn down
07:27:24.230 Browser Use tab closed
             appBrowserTabCount=3
             appBrowserUseTabCount=0
07:27:24.870 Crashpad browser-process crash

The two earlier crashes show the same ordering, with the Crashpad sidecar created about 0.5–1.7 seconds after the final managed Browser Use tab teardown.

The lifecycle records also show a persisted task id for ended browser use session activity, while the page/route key is under a client-new-thread:<redacted> draft route.

This extends the reproduction beyond a manual finalization call:

long-running goal task_complete
+ automatic next task_started
+ automatic managed Browser Use count 1 -> 0
= browser-process crash

Ordinary app-browser tabs do not protect against it; the third crash still had appBrowserTabCount=3 when managed Browser Use reached zero.

Impact on other active tasks

Because the Electron browser/main process exits, unrelated active local tasks are interrupted too. In one affected long-running task:

• the raw rollout remained on disk (50.36 MB / 10,154 events);
• it had 13 compaction records;
• three active turns interrupted by these crashes had no task_complete;
• after restart, a new goal turn was started from compacted goal context;
• the app thread API exposed only the original in-progress turn (63 items), while the raw rollout contained 25 user and 213 assistant messages.

So the failure can cause both lost in-flight context and incomplete UI/thread rehydration even when the raw JSONL survives. This appears adjacent to #25779, but in this case the deterministic initiating event is the final managed IAB teardown.

Ruled out / workaround

• No Windows reboot at the crash times.
• Store update checks returned hasUpdate=false / NoUpdates.
• No resource-exhaustion event.
• One crash occurred during Modern Standby, but two occurred while awake, so standby is not the common cause.

Current reliable workaround is to disable/avoid the bundled in-app Browser plugin and use external Chrome or shell/Playwright-based validation. Preserving a managed IAB sentinel tab should also avoid the 1 -> 0 transition, consistent with the controlled A/B result already reported above.

Full logs and transcripts are not attached because they contain local project paths and task metadata; targeted sanitized excerpts can be provided if maintainers request them.

I can confirm this still reproduces on a substantially newer Windows desktop build.

Environment

• Codex Desktop package: OpenAI.Codex_26.825.3734.0_x64
• Windows: Microsoft Windows NT 10.0.26200.0, x64
• Time zone: UTC+08:00

Reproductions on 2026-08-28

The app produced browser-process Crashpad reports at:

• 10:42:30 local time
• 11:14:36 local time
• 12:00:36 local time

All three Crashpad sidecars contain:

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

In each occurrence, the desktop log ends at the in-app Browser Use teardown boundary. The common sanitized sequence is:

IAB_LIFECYCLE unregistered debugger listener ... reason=target-close
IAB_LIFECYCLE syncing browser use active state ... isActive=false
IAB_LIFECYCLE renderer synced browser use webview state ... isBrowserUseActive=false
IAB_LIFECYCLE iab rejected tab for route ... tabRouteKey=null
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

For the 12:00 occurrence, the final lifecycle record was written at 12:00:35.900; Crashpad recorded the ptype=browser crash at 12:00:36.

The log also reports Cannot find context with specified id and repeated Failed to upsert Browser Use PiP content messages during Browser Use before teardown. I found no OOM or GPU-process failure at these three boundaries.

Older-version evidence

On 2026-08-25, package 26.818.5229.0 also produced repeated codex.exe crashes. Windows Event Viewer recorded exception 0xc0000409 at the same fault offset across several events, and Windows generated multiple crash dumps. This older evidence is not enough to prove the exact same native fault, but it shows that repeated desktop crashes persisted across the update to 26.825.3734.0.

I am not attaching raw logs or dumps publicly because they contain local paths, browsing history, project URLs, and session metadata. Sanitized excerpts or specific artifacts can be provided if maintainers request them.

The practical workaround remains avoiding finalization/closure of the last in-app Browser Use tab and using external Chrome for browser QA.