Repository navigation
[Windows] Repeated main-process crashes immediately after Browser Use tab cleanup (26.930.7945.0) #51560
Description
What version of the Codex App are you using?
Affected Windows package version 26.930.7945.0, verified from package paths in the desktop log for the October 7 incident. This is the package version, not an independently verified About-dialog display version. Older incidents should not be assumed to use this version.
What subscription do you have?
Not collected for this report.
What platform is your computer?
Windows desktop, x64. Read-only OS metadata at diagnosis: Windows 10 Pro, version 21H2, build 19044.1645 (CIM/runtime build 19044; registry UBR 1645).
What issue are you seeing?
The desktop application has unexpectedly closed several times and interrupted active work. At least two locally documented occurrences show embedded Browser Use tab/webview teardown immediately before a Crashpad browser/main-process crash.
The latest occurrence was October 7, 2026, at approximately 02:54:34 UTC / 10:54:34 UTC+08:00. The app had just closed a completed background browser test tab. This was not simply a failed webpage or an interrupted model response: the desktop app disappeared and had to be relaunched.
The retained 60-byte Crashpad sidecar contains:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}Its last-write timestamp is 2026-10-07T02:54:34.157842Z. This is an artifact timestamp, not a precisely measured native exception time.
Sanitized final desktop-log timeline
All times below are UTC on October 7:
02:54:33.269 unregistered debugger listener; reason=target-close
02:54:33.272 syncing browser use active state; isActive=false
02:54:33.273 renderer synced browser use webview state; isBrowserUseActive=false
02:54:33.295 renderer disposed browser sidebar webview
02:54:33.306 browser sidebar guest torn down
02:54:33.316 renderer removed browser sidebar webview; tabType=closed
02:54:33.317 closed browser sidebar page
02:54:33.318 tab lifecycle action=closed; appBrowserTabCount=4; appBrowserUseTabCount=1
02:54:33.349 Received Browser Use PiP metadata; backend=iab; browserID=2; tabID=11
02:54:34.157 Crashpad sidecar last-write time; capture_kind=crash; ptype=browser
02:56:43 new desktop main log begins after relaunch
The old desktop log ends at the PiP entry above. This was not the final embedded browser tab: four app tabs and one Browser Use tab were still reported after closure.
Earlier locally documented occurrences
These are separate preserved local diagnostic records, not an assertion that the same native exception occurred four times:
| Date (UTC+08:00) | Recorded evidence | Relationship to browser cleanup |
|---|---|---|
| September 11, 04:00:44 | Crashpad sidecar: crash/browser/x86_64 | Exact triggering action not established |
| September 11, 11:13:03 | Crashpad sidecar: crash/browser/x86_64; desktop relaunch logged at 11:15:41 | Browser routing errors were observed; causation not established |
| September 16, 11:07:36 | Crashpad sidecar: crash/browser/x86_64 | Previous desktop log ended at 11:07:35 while closing a Browser Use test tab |
| October 7, 10:54:34 | Current retained Crashpad sidecar and final lifecycle sequence above | Browser webview/debugger/guest cleanup immediately preceded main-process termination |
A separate October 3 unexpected exit was investigated, but no matching current Crashpad dump or exception was available, so it is not counted as another verified browser-process crash. Repository-diff scanning timeouts were separately reproduced and reduced by excluding generated dependency/build directories from Git scanning; that did not establish a cause for the app exit.
What steps can reproduce the bug?
No deterministic minimal reproduction has been established, and deliberate crash reproduction has not been attempted.
Observed latest workflow:
- Use the Windows desktop app for a local development task.
- Open a background in-app Browser Use tab to verify a website.
- Finish verification and close that test tab while other in-app tabs remain open.
- The desktop process exits immediately after tab/webview cleanup in the recorded occurrence.
- Relaunch the app to resume work.
What is the expected behavior?
Closing or disposing an embedded browser tab should leave the desktop host and active conversations running. A failed guest/webview should be recoverable without terminating unrelated work.
Diagnostic limits and related reports
- No native dump remains for the October 7 occurrence. There is no exception code, faulting module/offset, register state, or stack trace to compare.
- Targeted Windows Application event IDs 1000/1001/1002 found no matching app crash record for the latest incident; System event 2004 found no memory-exhaustion event. This does not rule out resource involvement.
- Memory figures collected after relaunch are not treated as measurements at crash time.
- Browser cleanup is a temporal correlation, not a proven root cause.
- Related existing report: Windows desktop app crashes with access violation in chrome.dll during embedded browser cleanup #50799, including other users' Browser Use cleanup/main-process crash observations. This report adds an independently documented installation and history; it cannot confirm the same chrome.dll access-violation signature without a native dump.
Please investigate the Electron/Chromium guest destruction, debugger target-close disposal, and Browser Use PiP/sidebar lifecycle paths. Please also provide a supported way to retain useful native diagnostics and a private upload channel if engineering needs more evidence. This recurring termination is materially interrupting ordinary development work.
Only sanitized event text is included. Project names, website URLs, host addresses, local usernames/paths, conversation/session IDs, credentials, source/data files, full logs, and memory dumps are omitted.
Activity
github-actions commentedon Oct 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
buaziz commentedon Oct 10, 2026
Additional occurrence on Windows 11 Pro x64, build 26300, with installed OpenAI.Codex package 26.1007.2314.0 (verified via Get-AppxPackage; About-dialog version not separately captured).
The user reports that closing in-app browser tabs and the desktop app unexpectedly exiting has happened multiple times. One occurrence was independently investigated on October 10, 2026 at 07:25:56 UTC / 10:25:56 Kuwait time (UTC+3). No deterministic minimal reproduction or repeated controlled crash test has been performed.
Sanitized final desktop-log timeline (UTC):
The previous main log ends abruptly at the PiP entry. Crashpad sidecar content:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}Here
browseridentifies the Electron main/browser process. This was not closure of the last embedded tab: three app browser tabs and one Browser Use tab remained according to the final analytics entry.No .dmp remains in the inspected Crashpad reports/attachments, so there is no exception code, native stack, or faulting module to compare. No corresponding Windows Application Error/WER crash entry, Windows restart, resource-exhaustion event, or Codex package deployment was found in the targeted shutdown interval. These negative checks do not prove that resource involvement is impossible.
Browser tab teardown immediately preceded the confirmed main-process crash; causation and a shared native signature with other reports remain unconfirmed. The recurrence is interrupting active work and requires relaunching the desktop app.
Please investigate the webview/guest destruction and Browser Use PiP/sidebar lifecycle, and provide a supported way to retain native crash diagnostics or submit them privately. An older October 7 sidecar on this machine records a renderer crash; it is not counted here as a second verified main-process teardown crash.
Only sanitized diagnostic event text is included. Usernames, local paths, project names, website destinations, conversation/session identifiers, full logs, credentials, and memory dumps are omitted. Codex assisted with the investigation; the user requested reporting this recurring issue to OpenAI.
buaziz commentedon Oct 10, 2026
A second independently confirmed main/browser-process crash on the same installation today, after the previous comment. Installed package remains 26.1007.2314.0, Windows 11 Pro x64 build 26300.
Latest occurrence: 2026-10-10 09:06:55–56 UTC / 12:06:55–56 Kuwait time (UTC+3). Relaunch began at 09:30:20 UTC.
Sanitized final desktop-log entries:
The main log ends at the PiP metadata entry. The new sidecar again contains:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}Comparison with the earlier 07:25:56 UTC crash:
tabID=undefined, abrupt main-log termination, a browser-process crash sidecar approximately 0.5 seconds after the final log entry, and container destruction.appBrowserTabCount=3,appBrowserUseTabCount=1.appBrowserTabCount=2,appBrowserUseTabCount=0: the last Browser Use tab closed, but two other browser tabs remained.created browser use hostentry appeared in the earlier final sequence but is absent from the latest one. Both end at undefined-tab PiP metadata.This repeat provides stronger evidence of an association with browser cleanup, without proving the exact failing operation or native exception. Native .dmp files are still absent from Crashpad reports/attachments and no new Codex dump was found in the default CrashDumps folder. Targeted Windows Application/System/resource-exhaustion/package-deployment queries found no additional diagnostic event in the latest interval beyond AppModel container destruction.
The crash evidence has been preserved locally. No app configuration changes or deliberate crash reproduction were performed. Private conversation identifiers, paths, project/website details, full logs, and credentials are omitted from this comment.