Repository navigation
[Windows][26.901.5280/6511] Closing the last in-app Browser Use tab crashes the desktop app #43347
Description
Summary
On Windows, closing or finalizing the last active in-app Browser Use tab can terminate the entire Codex desktop application.
This was reproduced twice on the same machine across two Codex Desktop builds, including after a Microsoft Store update:
26.901.5280.026.901.6511.0
The app restarted normally after each crash, but all active tasks were interrupted.
Environment
- Windows 11 x64
- OS build:
26200 - Microsoft Store / MSIX installation
No user names, project names, local paths, conversation identifiers, task content, or raw session logs are included in this public report.
Reproduction pattern
- Start a Codex task that invokes the in-app Browser.
- Allow the Browser Use tab to open and operate normally.
- Close or finalize the last Browser Use tab while the browser session is active or has just completed.
- The browser WebView teardown sequence begins.
- The entire Codex desktop application exits.
- Restarting the app succeeds.
The close may be initiated by the Browser Use workflow rather than by a manual click.
Sanitized log sequence
The following sequence appeared immediately before both crashes. Identifiers and local details have been removed:
warning [browser-use-pip] Failed to upsert Browser Use PiP content
info [browser-use-iab-api] IAB_LIFECYCLE unregistered debugger listener reason=target-close
info [browser-sidebar-manager] IAB_LIFECYCLE syncing browser use active state isActive=false
info [electron-message-handler] IAB_LIFECYCLE renderer disposed browser sidebar webview
warning [browser-session-registry] IAB_LIFECYCLE browser sidebar guest torn down
info [electron-message-handler] IAB_LIFECYCLE renderer removed browser sidebar webview
info [browser-session-registry] IAB_LIFECYCLE closed browser sidebar page
In one reproduction, this also appeared shortly before teardown:
warning [browser-use-iab-api] IAB backend request failed:
Cannot find context with specified id
request=executeCdp:Runtime.evaluate
The desktop log ends immediately after the teardown sequence.
Crashpad evidence
Both crashes produced the same generic Crashpad sidecar:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}A Crashpad record was created within approximately one second of the Browser Use WebView teardown. No local minidump was retained, so a native stack trace is not available.
Crash report identifiers are intentionally omitted from this public issue but can be supplied through a private support channel if useful.
System checks
- No matching Windows Application or System error was recorded in the one-minute window around either crash.
- No resource-exhaustion event was recorded at either crash time.
- No display-driver reset or GPU error was recorded at either crash time.
- The same failure occurred before and after the Store update.
Expected behavior
Closing or finalizing a Browser Use tab should cleanly dispose of the WebView. A stale CDP context or Browser/PiP state should fail the individual browser operation without terminating the desktop application.
Actual behavior
The Electron browser/main process crashes, terminating the complete Codex desktop app and interrupting active tasks.
Related issues
- Windows desktop app crashes when in-app Browser route is torn down (5 reproducible crashes) #42006 — Windows desktop app crashes when in-app Browser route is torn down
- [Windows][26.825.6671.0] Built-in Browser crashes entire app in both ChatGPT and Codex modes #41854 — Built-in Browser crashes the entire app on Windows
This report adds a reproduction on two later 26.901 builds and shows the same crash surviving an app update.
Submitted by Codex at the user's explicit request after local log review. All public evidence was manually minimized and sanitized; full raw logs are not attached because they contain private project and session information.
Activity
github-actions commentedon Sep 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Phr3dTheRipper commentedon Sep 7, 2026
Additional independent reproduction on Windows with Codex desktop app 26.901.6511.0.
Observed twice on the same machine:
In both cases, a Crashpad sidecar was created within about one second of the in-app Browser Use teardown sequence and contained:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}Crash report IDs:
bea52d6e-8c8c-4e44-8de3-e198af12d1a4c7fea412-1b5f-46ee-b548-f89461b38370For the second crash, the desktop log sequence at approximately
14:56:00Zrecorded Browser Use becoming inactive, the browser-use activity ending, the debugger listener being unregistered, the browser-sidebar guest being torn down, and the browser-sidebar page closing. The Crashpad sidecar was then created at14:56:00.877Z.No matching Windows Application Error or Windows Error Reporting event was present. The Codex task itself continued in the backend and completed, but the complete desktop UI disappeared and had to be restarted.
I am not attaching the raw app log because it contains private project and session data, but sanitized excerpts can be provided if useful.
diegomane commentedon Sep 7, 2026
Additional independent report, submitted with the affected user's explicit authorization after reviewing local logs.
Environment: Windows x64, Microsoft Store/MSIX package OpenAI.Codex version 26.901.6511.0.
The user reports that the entire desktop app exits unexpectedly and must be reopened. Three crashes on 2026-09-07 match the last in-app Browser Use tab teardown pattern:
All three Crashpad sidecars contain:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}The logs repeatedly end after the webview disposal / guest teardown / last-tab closure sequence. Before the 12:21 crash, there are also
Failed to upsert Browser Use PiP contentwarnings.This is a temporal correlation found in existing logs, not a controlled reproduction or proof of the underlying native cause. No native stack trace is available in the inspected reports. The previous checks found no matching Codex Application Error/Hang event or System resource-exhaustion/display-reset event in the queried period.
Expected: finishing or closing a Browser Use tab should not terminate the desktop app or interrupt other active tasks.
Only minimized diagnostic evidence is included here; no private task content, local user paths, session identifiers, or raw logs are attached.
poddenart commentedon Sep 7, 2026
Additional independent evidence from two unexpected desktop exits on Windows 11 Home x64, build 26200, on 2026-09-07. Submitted with the affected user's authorization.
Installed MSIX at inspection:
OpenAI.Codex 26.901.6511.0; the desktop shell executable isChatGPT.exe. A targeted Microsoft Store update check returned no newer package.Both sidecars contain:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}Crash report IDs for correlation:
0fce4de5-6d90-415e-9d9f-f0e01977b386e4165ae4-de9d-4331-a3b1-ce49fb6e1c73In the second incident, a browser automation call explicitly closed an in-app tab. The desktop log then recorded
unregistered debugger listener reason=target-close, sidebar webview disposal, guest teardown, webview removal, page closure, and finallyFailed to upsert Browser Use PiP content. The browser-process crash marker followed about half a second later.The first incident followed end-of-session browser cleanup with the same disposal sequence. No explicit tab-close call was found in the inspected final two minutes of that session. We have not established that it was the last tab in either incident.
Repeated
ResizeObserver loop completed with undelivered notificationserrors also occurred, but they do not establish the cause of the native crash. No matching display-reset or resource-exhaustion event was found in the inspected Windows System events. No matching shell Application Error event was found; Crashpad independently records both crashes.No native minidump or symbolicated stack was available locally. This is retrospective timing correlation, not a controlled reproduction or proof of a specific lifecycle race. Expected behavior: finishing or closing an embedded browser session should not terminate the desktop shell.
Only minimized technical evidence is posted. Private prompts, project URLs, local user paths, session transcripts and full raw logs are omitted.
Update: third incident at 23:05:31 UTC
A third browser-process crash occurred on the same machine on 2026-09-07 at
23:05:31.635Z(19:05:31 EDT), again on MSIX26.901.6511.0. Crashpad ID:7cf94b78-fdd0-4038-9043-74e00eea58f4; sidecar again reportscapture_kind=crash,ptype=browser,osarch=x86_64.The final log sequence was:
This distinction may help reproduce it: two ordinary in-app tabs remained, but the last Browser Use tab had been removed. A post-closure CDP request and PiP metadata update then encountered missing tab/route state. These observations narrow the lifecycle sequence but still do not prove the native failure mechanism without a dump/stack. The desktop application was restarted shortly afterward. No matching Windows Application fault or System critical/error event was found in the inspected preceding 12 minutes.
czwaxm commentedon Sep 8, 2026
Another similar incident observed on Windows x64 with Codex Desktop MSIX build
26.901.6511.0on September 8, 2026.The application exited during an in-app Browser workflow viewing a local development preview. It subsequently relaunched successfully. Local desktop logs and the tool-call transcript show the following timeline (UTC; local time is UTC+8):
03:45:11.969:IAB_LIFECYCLE iab rejected tab for route, withtabRouteKey=null; a subsequent request reported that the tab was not part of the current browser session.03:45:12.055and03:45:24.976:Failed to upsert Browser Use PiP content.03:46:01.779: the agent invoked a browser operation to close the existing in-app tab and then create another in-app tab for the same local preview.03:46:15.038: the old desktop process's final log entry wasIAB_LIFECYCLE unregistered debugger listener ... reason=target-close ... webContentsDestroyed=false.03:46:23.448: a new desktop log recordedLaunching app.There were also
Conversation state not found/ unknown-conversation event errors before the exit. Their causal relationship is unknown.No matching Codex Application Error / Windows Error Reporting / Application Hang event was found in the inspected Application log, and no matching new minidump was found in the inspected local crash directories. We do not have a native stack trace or a confirmed Crashpad report for this incident.
This is a single observed incident, not a controlled reproduction. The build and close/teardown timing closely match this issue, but we have not established that it was the last active browser tab or that the native root cause is identical. We also cannot tell from the retained log whether the subsequent create-tab operation began.
Identifiers, usernames, local project paths, and raw session content have been omitted. Posting this sanitized evidence at the affected user's request.
anaranjo-panaca commentedon Sep 10, 2026
Additional confirmed reproduction on an older Windows Store build.
Environment:
26.820.9563.026200Observed twice on 2026-09-10 (America/Bogota):
In both incidents, Browser Use operated normally until the controlled in-app tab was closed. The desktop log then ended with the same teardown sequence:
A Crashpad record followed in under one second each time:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}No matching Windows Application Error, GPU reset, or resource-exhaustion event was present. Restarting Codex restored the task state. In these reproductions, closing was initiated by the Browser Use workflow rather than a manual click.
Raw logs are not attached because they contain private project/session details. This comment was submitted by Codex at the user's explicit request after local log review.
Unbitjorge commentedon Sep 11, 2026
Additional anonymized reproduction confirming that this issue persists in a later Windows build.
Environment
26.903.9818.0Crashpad signature
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}Sanitized sequence immediately before the crash
The Crashpad sidecar was created at approximately
14:11:02Z, less than one second after the WebView teardown sequence. The complete desktop application exited. The filtered log tail contained no out-of-memory, GPU, or Windows fatal-error signature near the crash.This closely matches the teardown/crash sequence reported here and shows that the failure is still reproducible on package version
26.903.9818.0.yarmor58 commentedon Sep 14, 2026
Additional evidence — 10 browser-process crashes on Windows, September 11–14, 2026
A review of this machine's retained desktop logs and Crashpad metadata found 10 browser/main-process crashes, each immediately after closing the final automated Browser Use tab. This adds recent evidence for the lifecycle failure described in this issue.
Environment at inspection:
OpenAI.Codex 26.908.4834.026.908.408340.154.0-alpha.6.226H1, OS build28000.295426.903.71938; the last three occurrences below are in sessions running26.908.40834.Correlated occurrences
All timestamps are UTC. “Crashpad time” is the sidecar file's last-write timestamp, not a native exception timestamp.
Every occurrence records
action=closed isBrowserUseTab=true appBrowserUseTabCount=0. Four occurrences retain ordinary browser tabs. Thus this pattern is specifically associated with the last Browser Use tab, and does not require all browser tabs to be closed.Each matching sidecar contains:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}Latest failure boundary
Shortened log excerpts; private identifiers and page URLs removed:
Expected: ending a browser automation session should dispose of its guest without terminating the desktop main process.
Evidence limits
This is a retrospective correlation across ten crash records, not a measured failure rate across all tab closures or a controlled minimal reproduction. No native dump remains locally, so the exception code and faulting module for these main-process crashes are unknown. No matching Codex/ChatGPT Application Error, Hang, or WER event (1000/1001/1002) was found in the preceding seven days. Absence of those Windows events does not negate the Crashpad records.
A separate IAB renderer crash was found on September 13 and is excluded from the ten main-process events. No assertion is made that these native failure paths are identical.
Submitted at the affected user's request. Only minimized technical evidence is posted; raw logs, prompts, task IDs, user paths, private URLs, and memory dumps are omitted. Crashpad sidecars alone do not confirm automatic upload receipt.
diegomane commentedon Sep 14, 2026
Follow-up to #43347 (comment): another full desktop-app crash occurred on 2026-09-14, now on Windows x64 / MSIX OpenAI.Codex 26.908.4834.0.
The user reported an unexpected exit of the Windows app. Local logs and Crashpad metadata show the following sequence (UTC; local time UTC-03:00):
appBrowserTabCount=1,appBrowserUseTabCount=0. This time one browser tab remained, but the last Browser Use tab was gone.Crashpad sidecar:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}The final minute also contained 33
ResizeObserver loop completed with undelivered notifications.errors. Their causal relevance is unknown.No native minidump or stack trace was present in the inspected Crashpad directory, and no matching Application Error/Hang event was found in the queried Windows Application event window. This is another temporal correlation with Browser Use teardown, not a controlled reproduction or confirmation of the underlying native cause. It demonstrates recurrence on 26.908.4834.0 after the earlier report on 26.901.6511.0.
Posted with the affected user's authorization. Evidence is minimized: no private task content, URLs visited, local user paths, session identifiers, or raw logs are attached.
Clownking99 commentedon Sep 20, 2026
Adding two further occurrences on a newer Windows desktop package.
Environment
OpenAI.Codex 26.915.4065.0buildNumber=992210.0.26200Observed reproduction
await tab.close()during cleanup.This happened on 2026-09-19 at 13:54:30 UTC and 14:15:59 UTC (21:54:30 and 22:15:59 UTC+8). No additional destructive reproduction was attempted.
Minimized log excerpts
Identifiers, task content, usernames, project names, local paths and URLs are omitted. Ellipses indicate removed fields.
First occurrence:
Second occurrence:
Scope of the evidence
appBrowserUseTabCountfell to zero.Expected: closing a managed browser tab should dispose of that tab while leaving the desktop app and active tasks alive. Please investigate the Browser Use WebView teardown/ownership path on this newer build.
Submitted by Codex with the user's explicit authorization; the report intentionally separates observations from the still-unconfirmed underlying cause.
abduhman-star commentedon Sep 21, 2026
Additional evidence on Windows with MSIX package OpenAI.Codex 26.915.4065.0 and bundled ChatGPT.exe 153.0.8010.48, on Windows 11 x64, OS build 26200.
The entire desktop app repeatedly closes unexpectedly. Retrospective review found six browser/main-process crash records, each immediately following an in-app Browser Use tab teardown. This is not a deliberately reproduced minimal test, and some earlier tab closures succeeded.
This may extend the issue beyond closing the last Browser Use tab: in two of the six incidents, the final tab-close analytics still reported one or two Browser Use tabs remaining.
These intervals compare the logged tab-close timestamp against the sidecar file's last-write time; they are not precise native exception timings. Tab counts are values reported by the app's analytics, not independently verified live state.
All six sidecars contain:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}The recurring final log sequence is below. Timestamps and identifying fields have been removed;
...denotes omitted fields.The desktop logs stop at that boundary or after a few subsequent sidebar-owner/rebind or routine response records. No normal shutdown marker was found in these six matching log files.
Expected: closing or finalizing a Browser Use tab should dispose of that tab without terminating the desktop app.
Limitations: only the sidecar metadata remains in the inspected Crashpad reports directory. No native stack trace or faulting exception code is available, so browser-tab cleanup is a strong temporal association rather than a confirmed defective function. No corresponding display-driver reset or system resource-exhaustion event was found in the inspected Windows System log period; that does not rule out every possible native failure mechanism. External-browser use is a proposed workaround, not a verified fix.
Please investigate the Browser Use teardown/ownership path on this build, including cases where other Browser Use tabs remain, and advise what minimal diagnostics would identify the native fault.
This report contains only minimized technical evidence. Personal details, location/time zone, usernames, local paths, project names, visited URLs, task/conversation identifiers, crash UUIDs, screenshots, and raw logs are omitted.
juexingdemiao commentedon Sep 22, 2026
Additional independent evidence on Windows x64, MSIX package OpenAI.Codex 26.915.4065.0, app-server 0.155.0-alpha.9.2, OS version 10.0.26200. Submitted with the affected user's explicit authorization after reviewing local desktop logs, browser-tool calls, and Crashpad metadata.
Three unexpected desktop exits were recorded on 2026-09-22 UTC. Each was immediately preceded by a browser-tool call containing
await tab.close(), followed by the in-app Browser Use WebView teardown sequence.The third tool call also performed a page interaction, accessibility read, and viewport reset before closing the tab. The first two calls contained only the tab-close operation. Variable names and private page details are omitted.
All three sidecars contain:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}This is not limited to closing the last app browser tab. At the three tab-close boundaries, analytics reported:
For event 3, the log then showed activation of another Browser Use tab, debugger-listener registration, and PiP metadata before stopping. Thus one Browser Use tab was still reported as remaining at the crash boundary.
The common sequence, with identifying fields omitted, was:
Other tab closures succeeded, so this is intermittent. These are retrospective observations, not a deliberately reproduced minimal test. The sidecar timestamps indicate file writes, not exact native exception times. No local minidump/native stack remains in the inspected Crashpad reports directory, so the underlying native defect is not established.
No matching Codex/ChatGPT Application Error/Hang/WER event was found in the inspected period. Proxy logs contained no warning/error in the three crash minutes, and the inspected desktop logs contained no
ERR_CONNECTION_CLOSEDor explicit out-of-memory/heap-limit message. These negative checks do not rule out every native failure mechanism.Expected: closing a Browser Use tab should dispose of that tab while keeping the desktop application running. Please investigate the tab/WebView teardown and subsequent active-tab/PiP handoff, including cases with another Browser Use tab remaining.
Only minimized technical evidence is posted; no raw logs, project content, page URLs, local user paths, conversation IDs, or crash UUIDs are included.
Horitz commentedon Sep 23, 2026
Additional evidence from Windows x64 on 2026-09-23: the entire desktop application repeatedly disappears during normal task execution and must be reopened manually.
Versions observed
Crash evidence
Read-only inspection found nine Crashpad sidecar records that day, each containing:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}Their file last-write times, converted to UTC and shown to the second, were:
03:10:16, 03:31:29, 04:02:40, 05:07:22, 06:49:34, 07:31:42, 09:04:45, 10:02:36, and 10:18:01.
For the five later incidents (06:49 through 10:18 UTC), each corresponding desktop log ends at or shortly after the same in-app Browser Use tab-close/WebView-teardown sequence, associated with the same task.
Latest inspected incident
The task transcript shows that an in-app test page was created using
cua.createBrowserTab('iab', ... , {visible:false}). After interacting with the page, the final browser-tool call canceled an unsubmitted dialog, read the accessibility state, and explicitly calledawait accountTab.close().The matching desktop log ends with the following sequence (identifying fields omitted; all timestamps UTC on 2026-09-23):
The crash sidecar was written at approximately 10:18:01 UTC. In the preceding incident, the log ended at 10:02:36.187 UTC after tab closure, with
appBrowserTabCount=3andappBrowserUseTabCount=0; its crash sidecar was written during the same second. These analytics indicate that ordinary app browser tabs remained while the Browser Use tab count reached zero.Impact and limitations
ResizeObserver loop completed with undelivered notificationserrors do not establish the native crash cause.Expected: closing or cleaning up an in-app Browser Use page should leave the desktop application running.
Please investigate this teardown/PiP lifecycle on the newer 26.917 build and advise whether a fix or supported diagnostic procedure is available.
Submitted by Codex with the affected user's explicit authorization. Only minimized diagnostic evidence is included; no private project content, credentials, local usernames/paths, conversation identifiers, crash UUIDs, screenshots, or full raw logs are attached.
keivan-b commentedon Sep 27, 2026
Windows ChatGPT Desktop repeatedly crashes during Local Work.
Desktop release: 26.924.22138
MSIX package: OpenAI.Codex_26.924.2738.0_x64
Windows x64, OS release 10.0.26200
Crashpad repeatedly reports:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}
Pet is disabled.
Task Manager shows no abnormal resource usage.
Reliability Monitor and Event Viewer do not record a corresponding ChatGPT crash.
On 2026-09-27, two crashes occurred:
For the second crash, the desktop log shows:
21:44:55.456Z IAB_LIFECYCLE ended browser use session activity
The browser/main process then crashed approximately 11.5 seconds later.
The app was restarted afterward, and Browser Use/IAB initialized again.
The issue reproduces during Local Work and interrupts active tasks.
BenBwall commentedon Sep 28, 2026
Additional occurrence on desktop release 26.924.22138 / MSIX 26.924.2738.0, recorded on 2026-09-28. Submitted at the affected user's explicit request after reviewing local logs and Windows events.
The user reports repeated full-app closures, including while agents are running, resulting in interrupted work and lost productivity. The latest captured occurrence matches this issue's Browser Use teardown boundary.
Environment
26.924.22138, verified from installedowl-app.ini.OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0.ChatGPT.exe, Chromium/file version154.0.8037.57.26200.9550.buildFlavor=prod.Latest captured sequence
All timestamps below are UTC on 2026-09-28 (local time is UTC+03:00). Identifiers and page/project details are omitted. Browser counts are values recorded by the app.
The Crashpad sidecar contains exactly:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}The crash marker was written approximately 0.680 seconds after the last browser tab closed. No native
.dmpremained in the inspected Codex crash directories, so the native exception code, faulting module, and symbolicated stack are unavailable.Interpretation and impact
This establishes a browser/main-process crash immediately following two embedded Browser Use webviews being disposed, including the last Browser Use tab. The precise native defect has not been proven, and this is retrospective evidence rather than a deliberately induced reproduction. It demonstrates that the previously reported failure boundary persists on release
26.924.22138.A separate Windows Error Reporting
RADAR_PRE_LEAK_64event forChatGPT.exewas recorded at06:40:24Z. The app log continued for approximately another 2.5 minutes. That warning is included as context only; it does not establish memory exhaustion or the cause of this crash. No matching System resource-exhaustion or display-reset event was found in the inspected preceding seven days, and no Codex package deployment event was found in the inspected launch/crash interval.Expected: browser session cleanup should close only the browser tabs, while the desktop app and other active agents remain available. Native browser cleanup failures should be recoverable without terminating the complete application.
No raw logs, conversation content, visited URLs, local user/project paths, account details, or session identifiers are attached. The crash-report identifier and local source inventory are retained privately for OpenAI support if needed.
eastbend commentedon Oct 1, 2026
Additional occurrence on Windows with Codex package 26.917.6896.0.
Three crashes on October 1, 2026 (Asia/Tokyo):
All three desktop logs end around in-app browser webview/route teardown. Each incident produced a Crashpad sidecar indicating capture_kind=crash, osarch=x86_64, ptype=browser.
The 19:45 incident includes target closed while handling command during Page.captureScreenshot, debugger cleanup, disposeRoute, and browserWebviewDestroyed.
Current installed package: 26.928.3736.0. No native dump was retained. This establishes temporal correlation, not a proven native root cause. The newer package has not been verified to fix this issue.
A separate 21:42 Windows Update reboot and a user-confirmed 21:55 deliberate close are excluded.
Requested investigation: Investigate native browser/main-process failure during IAB teardown; identify a fixed Windows build or supported app-side workaround that preserves browser functionality.
No usernames, project names, conversation IDs, credentials, browsing history, or raw session logs are included.
Posted by Codex with the user's explicit approval after local log review.
mtdsxc commentedon Oct 2, 2026
Additional evidence on Codex desktop 26.930.21537 (build 12776, prod): five full-application crashes on 2026-10-02, immediately following in-app Browser Use tab closure. This appears to match the failure boundary reported here on earlier builds.
Environment
10.0.26200.26.930.21537, build12776, channelprod, reported by the app's update-check tool.26.930.2377.0(different version numbering from the desktop release).up_to_date.32.0.16.1088; a GameViewer Virtual Display Adapter is also installed.Observed behavior and workflow
The entire Codex window abruptly disappears and must be reopened. Other active project work is interrupted.
The affected workflow uses
cua.createBrowserTab('iab', <local test page>, {visible:false}), performs normal page interactions, and closes the temporary tab after verification. The final browser-tool call in each of the two most recent affected task turns was:The corresponding desktop logs end at or immediately after the IAB debugger-detach/WebView teardown sequence. These are repeated observations from ordinary local development, not a fresh-install minimal reproduction. We did not deliberately trigger additional crashes after recognizing the pattern.
Five native main-process crash records
All five retained Crashpad sidecars contain:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}Here
browseridentifies the Electron browser/main process, rather than just a failed webpage or renderer reload.All times below are UTC, 2026-10-02:
Sidecar file modification times are evidence of crash capture, not exact native exception timestamps. All five session tails contain the same tab-close/teardown pattern.
The latest incident's minimized log sequence is:
Identifiers, paths, page URLs, and task details have been removed. The final
tabID=undefinedfield is not itself evidence of the cause; it can represent an absent optional screenshot/tab field.Checks, limitations, and temporary mitigation
RADAR_PRE_LEAK_64warning forcodex.exe; neither establishes the cause of these five desktop main-process crashes.iabtab.close()and automatic tab cleanup. Other work continues. This is a temporary workaround, not a verified permanent fix.Expected: closing a temporary Browser Use tab should close that tab while leaving Codex and other active tasks running.
Please investigate this same teardown failure on 26.930.21537, and advise whether a fixed Windows build or supported workaround/diagnostic procedure is available.
Submitted by Codex at the affected user's explicit request. This comment contains only minimized technical evidence; no credentials, account details, project content, local user paths, conversation IDs, crash UUIDs, screenshots, or full raw logs are attached.
VN-Levie commentedon Oct 4, 2026
Additional report: three main-process crashes on Windows with Codex Desktop MSIX 26.930.3930.0 (x86_64).
All timestamps below are UTC+7:
All three Crashpad sidecars record capture_kind=crash and ptype=browser. This was a full application crash, interrupting long-running work, rather than only a tab or renderer failure.
The common pattern is Browser Use webview teardown immediately before the crash:
Debugger detached with reason=manual → browser sidebar guest torn down → session had zero tabs → ResizeObserver warning → final hooks/list entry. Crash recorded approximately 0.48 seconds after the last application log entry. “manual” in this log does not establish that I manually closed the tab.
Tab closed with reason=target-close → 15 getInfo failures reporting “No ChatGPT browser route is available for browser session” → a new about:blank webview with hostKind=hidden-browser-use → debugger attached to tab 3. Crash followed the last log entry by approximately 0.56 seconds.
In the same browser session as incident 2, tabs 3, 4 and 2 were closed, leaving zero tabs. A subsequent getCommittedTabUrl still referenced tab 3 and failed with “Tab 3 is not part of browser session”. The logs then included tabRouteKey=null and PiP metadata with tabID=undefined. Crash followed the last log entry by approximately 0.76 seconds.
Windows AppModel-Runtime/Admin Event 217 follows each incident. I understand this confirms application-container termination, not its root cause.
The app had been updated from MSIX 26.930.3748.0 to 26.930.3930.0 at 14:18 on Oct 3, before the first of these three recorded incidents. This timing alone does not establish a regression in that update.
No corresponding .dmp files remain available, so I cannot provide a native stack, exception code or faulting address. I have not established deterministic reproduction steps. The available evidence strongly correlates the crashes with browser teardown/stale-tab routing, but does not prove the underlying native cause.
Could the team confirm whether this pattern is covered by this issue, whether a fixed Desktop build is available, and which diagnostics would be most useful for a future occurrence?
augety121 commentedon Oct 4, 2026
Additional independent report from Windows 10 Pro x64 (10.0.19045): four full-application crashes immediately following an agent's explicit in-app Browser Use tab
.close()call.The user did not manually close Codex or the browser tabs; the close operations were performed by a running task. The entire desktop application disappeared, interrupting work.
Versions
Correlated observations
All timestamps below are Asia/Shanghai (UTC+08:00). Task call timestamps and desktop log timestamps were converted from UTC. Crashpad timestamps are filesystem last-write times, not exact native exception timestamps. Private identifiers and variable names are omitted.
All four retained sidecars contain:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}The corresponding task transcript contains an explicit
await <tab>.close()at each boundary. These are retrospective observations from normal work, not deliberate crash-inducing tests.Latest incident
The most recent desktop log ends with this sequence:
reason=target-close,webContentsDestroyed=false.tabType=closed.action=closed appBrowserTabCount=3 appBrowserUseTabCount=1 threadBrowserTabCount=2 threadBrowserUseTabCount=1.Thus this occurrence was not limited to closing the final Browser Use tab: another Browser Use tab was reported as remaining. The Crashpad sidecar was written approximately 0.795 seconds after the final desktop log entry. The agent's close call itself returned a tool result before the main process crashed.
Checks and limitations
ResizeObservererrors are present but are not established as the native cause.Please investigate the in-app Browser Use guest/WebView teardown and active-tab handoff on Windows, including cases where another Browser Use tab remains. Is there a fixed desktop build or a supported workaround and native-crash diagnostic procedure?
Posted with the affected user's explicit authorization. This comment contains only minimized technical evidence, not raw logs, project or conversation content, local user paths, server addresses, credentials, screenshots, or crash-report UUIDs.
davidvicr commentedon Oct 4, 2026
Six confirmed Windows main-process crashes after agent-initiated Browser Use tab closure
I am adding evidence to this issue because my Windows desktop app has repeatedly terminated during unattended work immediately after the agent explicitly closed an embedded Browser Use tab. The six confirmed incidents occurred between October 2 and October 4, 2026. The latest was on October 4 at 00:16 CEST, and the latest three incident logs identify package version 26.930.3930.0. This is a consolidated first report; I have not previously posted these observations as separate comments.
This appears consistent with the browser-teardown failure described here and may also be relevant to #46767. I cannot establish whether the native root cause is identical.
User impact
The entire desktop app disappears while the agent is working, interrupting the task. I have encountered this while away from the laptop and only discovered the interruption later. I did not intentionally quit the app at these times. This makes unattended work unreliable and initially looked like an idle timeout or loss of remote connectivity.
The evidence below indicates a local process crash rather than merely an unavailable remote connection or a failed web request.
Environment
Observed workflow
await tab.close()orawait memberTab.close()through its browser JavaScript tool.browserprocess crash within approximately 0.65-0.87 seconds of the last log entry.This is an observed sequence, not a claim that calling
close()in an otherwise empty app deterministically reproduces the crash. No deliberate crash reproduction was performed during diagnosis, and the total number of successful tab closures is not known.Expected behavior
Closing a Browser Use tab should dispose of that tab and its sidebar state without terminating the desktop app or interrupting the agent's task. Requests that race with tab disposal should fail safely.
Actual behavior
The main/browser process crashes following the close/teardown sequence. Only Crashpad metadata sidecars remain in the inspected crash report directory; no matching native minidump or native exception stack was available there.
Six confirmed incidents
All timestamps in this table are local CEST (UTC+02:00).
The sidecar time is a filesystem timestamp, not the native exception timestamp. The close time is the recorded agent tool invocation, not an instrumented timestamp of entry into native tab destruction. These distinctions matter when interpreting the timing.
All six sidecars contain:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}Here
ptype=browseridentifies the Chromium browser/main process, rather than an individual tab renderer. The crash evidence therefore does not rely only on the desktop log stopping.Important distinction: last Browser Use tab versus last browser tab overall
The close events report
appBrowserUseTabCount=0for all six incidents. However, the total app browser tab counts after closure differ:Thus, four of six incidents occurred while other app browser tabs were still counted. The recurring boundary is closure of the last Browser Use tab; it is not necessarily closure of every browser tab in the app.
October 3, 17:51 CEST: selected sanitized log excerpts
At 2026-10-03T15:51:35.269Z, the agent's browser JavaScript tool call included a final explicit:
The following desktop log excerpts are in UTC. Conversation/page/route identifiers are redacted. The long JavaScript error stack and nonessential fields are omitted; these are selected excerpts, not a complete raw log.
The next relevant artifact is the Crashpad sidecar with filesystem time 2026-10-03T15:51:37.539Z and the crash metadata shown above.
The missing-tab
getCommittedTabUrlerror occurs during teardown. It may be useful for investigating lifecycle ordering, but it is a handled JavaScript error in the log, not a native crash stack and not proof of the defective native function.Latest incident: October 4, 00:16 CEST
The latest close tool invocation is recorded at 2026-10-03T22:16:20.658Z. The following selected desktop log excerpts are in UTC; this incident is October 4 in local CEST. Identifiers and nonessential fields are omitted or redacted.
The sidecar filesystem timestamp is 2026-10-03T22:16:21.464Z, approximately 661 ms after the final log entry and 806 ms after the close tool invocation. Its metadata again identifies a browser/main-process crash.
The preceding incident, October 3 at 20:01 CEST, follows the same teardown sequence. Its UTC close tool invocation is 18:01:39.483Z, final log entry 18:01:39.582Z, and crash sidecar timestamp 18:01:40.265Z. Its final tab counts are appBrowserTabCount=2 and appBrowserUseTabCount=0.
Both of these incident tails contain additional
ResizeObserver loop completed with undelivered notifications.errors, including one during teardown. I include this as context only: these UI layout errors do not establish the native crash cause.Cross-checks and alternative explanations
Read-only inspection of the relevant Windows, application and recovery-launcher logs found:
0x80073D02because the app was still running. The record says it was not forced, and the app continued logging until the 20:02 browser-close sequence.update_resume_state_saved. That update-related ending is distinct from the 17:51 crash reported here.For the October 3 20:01 and October 4 00:16 incidents, additional checks within five minutes either side of each crash found no matching sleep/wake, shutdown/reboot, display reset Event 4101, System resource-exhaustion Event 2004, Application Error/Windows Error Reporting/Application Hang record, or OpenAI.Codex deployment record. The inspected recovery-launcher audit file contains no action after 2026-10-03T17:30:00Z, so neither incident coincides with a recorded launcher restart.
These checks make browser teardown the strongest observed association, but do not prove that other factors are impossible. Missing Windows events are not a guarantee that every driver, memory or external-process explanation has been excluded.
Diagnostic limits and request
This report is based on desktop logs, selected agent tool-call records, Crashpad sidecar metadata, Windows events and recovery-launcher action logs. I have not obtained a native crash dump, established the exception code, or isolated a minimal public reproduction. Private page content, company URLs, local user/project paths, credentials and conversation identifiers are intentionally omitted.
Could the Windows desktop team investigate the lifecycle of the last Browser Use tab on 26.930.3930.0, particularly concurrent URL/metadata requests during sidebar disposal? Please also advise how to retain or collect the relevant native dump through a supported diagnostic channel if the existing crash telemetry is insufficient.
Using an external browser instead of the embedded browser, or avoiding explicit closure of its final Browser Use tab when an external browser is unavailable, has been suggested as a workaround to evaluate. Neither has been verified as a fix. Automatic app restart would not itself guarantee continuation of an interrupted task. No crash was deliberately reproduced and no app/network/authentication settings were changed during this diagnosis. No raw logs or sessions have been uploaded as part of this report preparation.
LeiterConsulting commentedon Oct 4, 2026
Adding another report of matching symptoms on Windows with desktop client 26.930.3930.0 and bundled backend 0.160.0.
Local diagnostics identified three browser/main-process crashes:
All times are EDT (UTC−04:00). Each crash record followed closure of the last Browser Use tab and the same WebView cleanup sequence by approximately 0.5 seconds. This appears consistent with the symptom pattern described in this issue.
No accessible native minidump was available, so the exact exception, faulting module and native stack remain unknown. These are observations from retained diagnostics, rather than a controlled reproduction or confirmation of a shared root cause.
A relevant caveat: system commit usage was separately observed at approximately 95%. It dropped after an unrelated high-commit application was stopped. That measurement was not established for each crash time, and memory pressure has not been excluded as a contributing factor.
Closing a Browser Use tab should leave the desktop app running. Could the team investigate whether these newer-build occurrences match the last-tab teardown issue?
GitMcLovin commentedon Oct 9, 2026
High-priority investigation requested: repeated workflow-interrupting crashes on Windows package 26.1002.7124.0
Adding independent evidence at the affected user's explicit request. The user reports frequent full-app exits during normal work. Two retained incidents from October 8-9 show Browser Use tab teardown immediately followed by a Crashpad browser/main-process crash. Please prioritize investigation: these exits interrupt unattended work, active agent tasks, and local tool processes, requiring manual relaunch and recovery.
Environment at inspection:
Correlated incidents
All times below are UTC. Crashpad times are sidecar filesystem last-write timestamps, not instrumented native exception times.
Both retained sidecars contain:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}On October 9, the recorded browser tool call at 06:45:18.276Z saved the final screenshot, closed an inspected page menu, and then explicitly invoked:
The tool returned before termination. The desktop log then ended during sidebar/tab lifecycle cleanup; a crash sidecar was written roughly half a second after its last record. The application was relaunched at approximately 06:53:57Z. The interrupted review retained screenshots and a technical report, but required recovery to complete.
Selected October 9 desktop-log excerpts, with identifiers and nonessential fields removed:
The October 8 log similarly records webview disposal, guest teardown, tab closure, and immediate re-registration as an ordinary browser tab before ending. That occurrence left other ordinary tabs open; the association is with Browser Use teardown, rather than necessarily closing all app browser tabs.
Power-management cross-check
The user initially suspected screen-off after 10-15 minutes. Read-only checks found:
These checks do not prove screen-off or every driver/resource factor is irrelevant. They provide no evidence of a sleep/hibernate transition at the current crash. Browser teardown is the strongest retained timing association.
Limits and request
This is retrospective evidence from normal work, not a deterministic minimal reproduction. No deliberate crash reproduction was attempted. Only sidecar metadata remains; no native dump, exception code, or symbolicated stack was available. A shared native root cause across installations is therefore not established.
Expected: finishing or closing a Browser Use tab must preserve the desktop host and active tasks.
Please escalate this recurring reliability problem to the Windows desktop/browser team and advise:
The proposed external-browser / avoid-close workaround in this issue has not been validated on this installation. No app, power, authentication, or network settings were changed during diagnosis.
Only minimized diagnostic evidence is posted. Private project names, website URLs, usernames/local paths, conversation IDs/content, crash UUIDs, credentials, raw logs, databases, and dumps are omitted. This is a request for high-priority triage, not an assertion that OpenAI has already assigned that priority.
Historical review addendum (October 9): three confirmed crashes and four additional suspect terminations
At the user's request, the retained desktop main logs dating back to September 25 were reviewed for additional evidence. This increases the confirmed count from two to three, with four additional suspect log endings that must not be counted as confirmed native crashes. The user reports more frequent unexpected exits than this retained evidence can establish.
Third Crashpad-confirmed incident: October 7, 22:31 UTC / October 8, 00:31 CEST
Selected minimized timeline, all UTC on October 7:
The missing-tab error is a handled JavaScript diagnostic, not a native crash stack. Its causal role remains unknown.
Four older suspect endings, without retained matching crash artifacts
Each of these process log series ends immediately after Browser Use webview/guest teardown. No corresponding native crash sidecar or dump is currently retained for these times, so a log ending alone does not prove a native crash or establish the same root cause.
October 1 running package is identified in its log as 26.928.3736.0. October 2's process log reports 26.928.3736.0; the October 3 files belong to that same process log series. October 5 reports 26.930.4958.0. These older cases are circumstantial evidence across earlier builds, rather than four additional confirmed crashes.
The October 3 tail records sequential closure of four Browser Use tabs, reducing the Browser Use count from three to zero. The October 5 next process log starts approximately 84 seconds after the suspect ending. Neither observation establishes the native exception.
Targeted Windows System checks within one minute either side of these four endings and the third confirmed incident found no event IDs 41/42/107/506/507/6006/6008/1074/2004/4101 (unexpected restart, sleep/resume, shutdown, resource exhaustion, or display reset categories). Absence of these events is not conclusive exclusion of all external causes.
Ordinary log rotation was excluded: for example, a September 27 file also ends after tab teardown but continues in the next numbered file under the same process identity. Update-related endings carrying update_resume_state_saved were also excluded. Not every restart, connection error, or truncated log is being called a crash.
This additional evidence strengthens the recurring browser-teardown association and broadens it beyond the final Browser Use tab. Please include it in high-priority Windows/browser lifecycle triage and advise on a fixed build or supported diagnostic collection procedure. No raw logs, private session content, or dumps are attached.
mjameson-creator commentedon Oct 10, 2026
Additional evidence: intermittent Windows main-process crashes after IAB teardown, including package 26.1007.2314.0
Posted with the affected user's explicit authorization after local log review. The user reports recurring complete desktop exits that interrupt normal work, but browser tasks often succeed. This is intermittent, not a claim that every Browser Use operation or every tab closure crashes.
The user has not identified the exact trigger or backend for every reported exit. The four retained incidents below specifically correlate with in-app Browser (IAB) teardown. We have no confirmed Edge-related crash evidence from this investigation. A successful short test of either backend does not establish long-term reliability.
Environment
26.1007.21434, build13901, production channel.OpenAI.Codex 26.1007.2314.0; package status OK.0.162.0-alpha.17.2.26300.up_to_dateon October 10.26.1002.7124.0; the latest ran26.1007.2314.0. The observed pattern therefore survived an update.Four retained incidents
All times are UTC. Crashpad times are sidecar filesystem last-write timestamps, not instrumented native exception times.
All four retained sidecars contain:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}Every incident follows IAB WebView disposal/guest teardown. Three corresponding agent transcripts contain explicit
tab.close()invocations immediately before termination. The remaining incident follows the assistant's final answer and browser cleanup; no explicit browser-close call was found in that transcript's preceding three minutes. This is consistent with automatic end-of-turn cleanup, but its exact initiator has not been established.reason=manualdoes not establish a human click.Latest incident: a non-final Browser Use tab was closed
Sanitized sequence on October 10, UTC:
Another Browser Use tab remained open. The October 8 incident likewise left
appBrowserTabCount=7andappBrowserUseTabCount=2. This broadens the observed teardown association beyond closing the final Browser Use tab.The October 9 21:38 incident additionally shows missing-browser-route errors, closure of an old WebView, and immediate creation of a new hidden browser host before termination.
Checks and limits
RADAR_PRE_LEAK_64warning does not establish the cause of these incidents..dmpfiles were retained, so there is no verified native exception code or symbolicated stack.Mitigation and request
The agent now avoids discretionary IAB
tab.close()and close/create cleanup cycles, reuses suitable tabs, and preserves result tabs to avoid automatic closure at turn end. This keeps the integrated browser enabled. It is a behavioral mitigation, not a native fix or a reliability guarantee.Please investigate IAB debugger detachment, WebView/guest disposal, PiP metadata updates, and tab handoff on these current Windows builds, including closure of a non-final Browser Use tab. Please advise on a verified fixed build or supported mitigation preserving IAB functionality, and a supported private procedure to retain the next native Crashpad dump.
Only minimized technical evidence is included. No private chat content, project names, local user paths, browsing history, session identifiers, crash UUIDs, credentials, screenshots, or raw logs are attached.
RobotQv commentedon Oct 10, 2026
Additional independently observed occurrences on Windows package 26.1007.2314.0, on 2026-10-10. Two retained Crashpad sidecars confirm browser/main-process crashes immediately after in-app Browser Use tab teardown. The entire desktop window disappeared and unrelated active local tasks were interrupted.
Environment
OpenAI.Codex, 26.1007.2314.0, package status normal.ChatGPT.exefile/Chromium version: 155.0.8059.40.codex-cli 0.162.0-alpha.17.2.Observed timeline (all times UTC, October 10)
Both sidecars contain:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}The final lifecycle sequence includes
reason=target-close, browser-use active-state synchronization, renderer webview disposal,browser sidebar guest torn down, tab removal, andclosed browser sidebar page.await tab.close(); counters changed to 3 total tabs / 0 Browser Use tabs. The old desktop log ends at the PiP metadata entry above, and the main-process crash sidecar follows about 0.68 seconds later.Interpretation and diagnostic limits
tabID=undefinedin the PiP message is not independently evidence of corruption: the installed bundle permits an optional screenshot and logsscreenshot?.tabId. In the reviewed October 8–10 logs, 241 of 552 such metadata entries lacked that screenshot tab ID, and most did not immediately precede a crash. Native macOS PiP helpers are platform-guarded; a Windows native-PiP failure is not established..dmpor WER native stack was available. Consequently there is no exception code, faulting module, or call stack to compare with other reports.Impact and request
Ordinary browser verification cleanup can coincide with termination of the entire host, interrupting work in other conversations. Please investigate the in-app guest/webview destruction and Browser Use state-cleanup paths, and provide a supported way to retain native crash diagnostics and submit them privately if needed.
Related broader teardown report: #51560.
Submitted at the owner's request after local read-only review. This public comment contains minimized diagnostic facts only; no usernames/local paths, project or website names, conversation/session/crash identifiers, credentials, raw logs, transcripts, screenshots, or memory dumps are attached.