Repository navigation
Windows desktop app crashes when in-app Browser route is torn down (5 reproducible crashes) #42006
Description
Summary
The Codex desktop app for Windows repeatedly crashes when an in-app Browser / browser-use session is closed after its route becomes unavailable.
Five app-level crashes occurred on the same day. Every Crashpad sidecar reports:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}Environment
- Codex desktop app:
26.825.6671.0 - OS: Windows x64
- Time zone: Asia/Shanghai
Crash times
- 2026-09-01 11:41:47
- 2026-09-01 12:06:28
- 2026-09-01 15:22:35
- 2026-09-01 15:38:42
- 2026-09-01 16:01:13
The app restarted successfully after each crash. Windows Application/System event logs did not show a system restart or a separate OS-level failure.
Repeated log sequence
Immediately before the crashes, the desktop logs repeatedly show:
No ChatGPT browser route is available for browser session <conversation-id>
IAB_LIFECYCLE unregistered debugger listener ... reason=target-close
IAB_LIFECYCLE browser sidebar guest torn down
IAB_LIFECYCLE renderer removed browser sidebar webview
IAB_LIFECYCLE closed browser sidebar page
IAB_LIFECYCLE iab rejected tab for route ... tabRouteKey=null
The Crashpad report is then created within roughly one second of the browser target/webview teardown.
Reproduction pattern
- Run a Codex task that uses the in-app Browser for visual verification or a web form.
- Let the task create/open an in-app browser-use page.
- The app reports that no ChatGPT browser route is available.
- When the browser target closes and the webview is torn down, the desktop app crashes.
- After restarting Codex, resuming a browser-using task can reproduce the issue.
The issue appeared more frequently when two tasks were using the in-app Browser concurrently, but one particular long-running browser-using task was present immediately before all five crashes.
Expected behavior
A missing/stale browser route or browser tab teardown should fail the tool call or close the tab without terminating the desktop app.
Actual behavior
The Codex desktop browser process crashes and all active tasks are interrupted.
Additional information
The full local logs and affected session transcripts may contain sensitive project information, so they are not attached publicly. They can be shared privately with OpenAI if needed.
Activity
kingballyy commentedon Sep 1, 2026
Related reports found after submission:
browser.tabs.finalize()silently terminates the entire app #35210 —browser.tabs.finalize()can terminate the entire Windows desktop appThis report adds a newer affected build (
26.825.6671.0), five Crashpad-confirmedptype=browsercrashes in one day, and a repeated stale-route sequence ending iniab rejected tab for route ... tabRouteKey=null.github-actions commentedon Sep 1, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
84dnnvbdvp-debug commentedon Sep 1, 2026
One older teardown report may materially narrow this without treating
ptype=browseras a root-cause marker. In #34239, a later occurrence of the sameiab rejected tab for route ... tabRouteKey=nullteardown family produced a native dump from the main/browserChatGPT.exe:0xC0000005read at0xFFFFFFFFFFFFFFFF, faulting inchrome.dll+0xEC1491E, with register poison patterns consistent with a lifecycle/use-after-free class failure. That occurrence involved tearing down the active Browser Use guest while an orphan guest remained, forcing a route/tab switch.That does not prove the five #42006 crashes share the exact native fault. But if one of the retained Crashpad events can be reduced privately or publicly to just exception code + faulting module/offset, comparing it with #34239 would distinguish this IAB teardown/switch family from unrelated
ptype=browsercrashes. A focused regression matrix could then cover explicitfinalize, automatic end-of-task teardown, stale-route/active-tab-to-orphan switching, and concurrent tasks, with the invariant that Browser cleanup may fail or close a tab but must not terminate the desktop main process.dhnova commentedon Sep 10, 2026
Additional reproduction from newer 26.903 builds, with a deterministic final trigger and post-crash persistence evidence.
Environment
10.0.26200.9445x64 (25H2)26.903.8094.0and26.903.9818.00.153.4UTC-06:00)Four additional browser-process crashes
The same long-running task produced four Crashpad sidecars:
26.903.8094.026.903.8094.026.903.8094.026.903.9818.0Every sidecar contains exactly:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}For all four incidents, the sidecar timestamp is approximately 0.6–0.8 seconds after the desktop log ends during IAB target/webview teardown. This reproduces across the two listed package builds. Only the four 60-byte sidecars were retained; there are no
.dmpfiles in the reports directory.Latest trigger captured in the durable rollout
The final tool request was:
The tool result itself was recorded as
completed(not an error), took about 16 ms, and reportedopenTabIds: []. The desktop log then ended with:The Crashpad sidecar was written at
16:23:18.455Z. This suggests the crash occurs after the logical close reports success, during or immediately after native/browser-process cleanup.Possible route-identity correlation
In the same run,
getInforequests were attributed to the persisted task ID and failed with:However, the active browser sidebar guest and its route key were registered under a different identity shaped like:
The target that subsequently closed also used that
client-new-thread:<uuid>route. I cannot establish causality from the logs alone, but the persisted-thread/browser-route identity split may help narrow the stale-route teardown path.Post-restart history rollback
The crash also exposed a second failure mode:
turn_abortedwith reasoninterruptedafter 5.173 seconds.30,204,861bytes, 44 user-role records), including the messages absent from the UI.state_5.sqlite,goals_1.sqlite, andlogs_2.sqlitereturnedok; the goal remained present but paused.This looks like a browser teardown crash followed by a stale task projection/recovery problem, rather than deletion of the underlying rollout or workspace data. Closely related reports:
0.153.4task projection cursor falls behind durable rollout ordinalsThe affected IDs and redacted desktop logs/rollout excerpts can be provided privately if maintainers need them. No project source, prompt content, credentials, or full rollout is attached publicly.
olinkluzz1v commentedon Sep 11, 2026
I’m seeing a closely matching crash on Windows x64 with Codex desktop version 26.903.9818.0.
Submitted feedback ID: 01a090bc-af91-7fc1-8126-f5a329ffff7a
Codex closed completely twice today. The latest confirmed crash was September 11, 2026, at 15:11:33 UTC / 17:11:33 CEST.
Immediately before that crash, logs show embedded-browser teardown and repeated “No ChatGPT browser route is available for browser session” errors. A Crashpad sidecar created in the same second contains:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}
The agent had attempted to switch browsers after “Browser is not available: chrome”, then the next tool call reported “Transport closed”.
The exact cause is unconfirmed, but this appears closely related to the sequence described here. I submitted the incident through /feedback; please use the ID above to correlate the report.
Additional detail: before the Chrome-unavailable and Transport-closed errors, the browser tool reported “Node is detached from document” while inspecting the weekly-export controls.
The agent then refreshed the controls and continued through several browser actions before the later crash. Including this for chronology; I don’t know whether it contributed to the crash.
entigit commentedon Oct 4, 2026
I can reproduce what appears to be the same Browser Use teardown crash on a substantially newer Windows build.
Environment
26.930.3173026.930.3930.001a0cebb-0c14-7db0-b4d9-b23544757a8bf968d0f4-a065-44e3-86ba-6e8407b7d68a2026-10-03T12:08:30ZCrashpad
The matching Crashpad sidecar contains:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}Browser Use teardown immediately before the crash
Immediately before the Crashpad report was created, the Codex desktop log shows:
The Crashpad sidecar was created at approximately
2026-10-03T12:08:30Z, effectively immediately after this teardown sequence.Errors shortly before the crash
There were also repeated renderer/conversation-state errors shortly beforehand, including:
The desktop log also recorded a pubsub transport close/reconnect and repeated:
I am not assuming these are the root cause, but they occurred shortly before the Browser Use teardown and Crashpad event.
Restart
The next Codex desktop startup log begins at:
This is approximately 11 minutes after the Crashpad event.
The restart log shows a fresh
codex.exeprocess and fresh app-server / Browser Use initialization. The earlierunknown conversationerrors are not present in the first 30 startup lines.This appears to show that the same browser-process crash pattern is still reproducible on:
26.930.3173026.930.3930.0I have the full crash-adjacent desktop log and session transcript locally and can provide a specific sanitized range if useful.
adrianonna commentedon Oct 4, 2026
Additional report of the same Windows desktop crash pattern.
Environment:
Four Crashpad sidecar records were found:
All times above are America/Fortaleza (UTC-03:00) and represent the sidecar files' LastWriteTime, not independently measured exception timestamps. The incidents span an app update on October 3; the current package version is verified for the latest incident and is not asserted for every earlier incident.
Each sidecar contains:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}
For all four incidents, the matching local task records show an awaited tab.close() immediately beforehand, after UI checks of a local web application. The tool calls returned successfully; the final browser-cleanup log was followed approximately 0.74-0.80 seconds later by a crash sidecar. This is intermittent: some other tab closures succeeded.
Latest incident, UTC:
The app was reopened at about 10:41:57 UTC with the same package version.
No app deployment, Windows sleep or system restart was found in the inspected interval around the latest incident. Only crash metadata remained locally; no native dump or exception stack was available. The repeated timing strongly points to browser-tab teardown, but the internal root cause has not been established. No deliberate crash reproduction was performed.
Expected: closing a temporary Browser Use tab should leave the desktop app and other chats running. Please investigate webview cleanup and PiP state updates when an automated tab closes.
This report omits project names, local user paths, credentials, conversation identifiers and full transcripts.
olinkluzz1v commentedon Oct 9, 2026
Happened again today, same scenario, ne need to even write down the details.
z595484296-dev commentedon Oct 17, 2026
Additional evidence: three Windows main/browser-process crashes on October 16-17, including package 26.1013.4894.0
The affected user explicitly requested that this issue be reported. The entire ChatGPT desktop window disappears unexpectedly, interrupting normal work. This is distinct from an individual response stopping or a WebSocket disconnect.
Environment verified locally on October 17, 2026:
Retained Crashpad evidence
The timestamps below are sidecar filesystem last-write times, not decoded native exception timestamps. IDs are local Crashpad report IDs, not verified server-side Sentry IDs.
All three sidecars contain exactly:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}Selected desktop-log chronology
Below, conversation IDs, tab UUIDs, local paths and page URLs are omitted. Lifecycle messages are abridged; original UTC timestamps are retained.
Incident 1: the process log identifies package 26.1013.3656.0. Its final entries include browser-route rejection and a handled missing-tab error:
The matching crash sidecar was written 0.720 seconds after the final log entry. The missing-tab diagnostic is not a native crash stack.
Incident 2: a Browser Use tab closes, followed by repeated owner synchronization/rebinding for another tab:
The crash sidecar follows the final log entry by 0.878 seconds. Another Browser Use tab remained according to the counters.
Incident 3: package 26.1013.4894.0; two Browser Use tabs are torn down immediately before the main log ends:
The matching crash sidecar follows the final entry by 0.672 seconds. This occurrence did not require closing the application's last Browser Use tab.
Checks and limitations
Please investigate the Windows IAB guest/webview destruction and owner/route synchronization path, including concurrent browser sessions and closure of a non-final Browser Use tab. Please advise on a verified fixed build or supported mitigation, and a supported private method to retain the next native crash dump.
Only minimized technical evidence is included. No raw logs, chat/session transcripts, project source, user filesystem paths, credentials, screenshots, or native memory dumps are attached.
YiQian128 commentedon Oct 17, 2026
Additional Windows evidence on 26.1013.40934 (build 20770), MSIX 26.1013.4894.0, Chromium 155.0.8059.80.
Three more whole-app crashes occurred on October 17 after a separate plugin-marketplace source conflict had been repaired. The selected pre-crash logs contain zero primary_runtime_restore_failed entries. Avoiding explicit tab close calls did not prevent automatic task-end cleanup.
UTC chronology (crash times are sidecar last-write times, not decoded exception timestamps):
All sidecars classify the process as browser, x86_64, capture_kind=crash. No explicit Browser Use close/finalize was found in these turns; the latest turn contains 39 Browser Use calls. Native exception code, native stack, and delivery of these local Crashpad report IDs to OpenAI are not established.
Read-only inspection of the current packaged main bundle confirms that turnEnded performs asynchronous per-tab debugger cleanup and closes unmarked temporary tabs. Current finalizeThreadTeardown delegates to disposePage, which disposes observers before conditionally calling native webContents.close(). This differs from the older close-before-dispose hypothesis; changing that ordering alone is not a justified current fix. Native guest ownership/reentrancy and overlapping cleanup remain candidates, not proven causes.
Please investigate the automatic turn-end path as well as explicit close, and provide a verified signed fix or supported diagnostic build/private capture method. Regression coverage should include one and multiple tabs, non-final-tab closure, automatic completion, interrupted turns, and retained handoff tabs, with the main process and other tasks surviving.
The affected user needs the built-in browser and preservation of chat data/cache and concurrent work. No raw logs, transcripts, project source, local paths, screenshots, credentials or dumps are included here. This follow-up does not claim a proven use-after-free or a completed local repair.
z595484296-dev commentedon Oct 18, 2026
Follow-up to my October 17 evidence: a fourth confirmed main/browser-process crash on October 18, after IAB teardown followed immediately by route recovery and new guest attachment
The affected user reports that the entire desktop application disappeared again. This adds a combined teardown/recreation sequence to my previous report, without isolating which lifecycle operation caused the native failure.
Environment rechecked: MSIX OpenAI.Codex 26.1013.4894.0, Windows x64. The built-in updater still reports installedVersion 26.1013.40934, build 20770, production channel, up_to_date.
New local Crashpad evidence:
Selected redacted/abridged sequence, all UTC:
The failed getInfo calls reference a persisted conversation identity, while the new host/page is registered under a client-new-thread: route. Actual identifiers are omitted. Whether this identity difference or the sandbox diagnostic contributes to the native crash is unknown; neither is a native exception stack.
This occurrence adds missing-route recovery and guest creation/attachment immediately after teardown to the sequence requiring investigation. It does not prove that tab creation alone crashes the app, or exclude delayed failure from the preceding teardown. No deterministic reproduction or specific native root cause is claimed.
No matching ChatGPT/Codex Application Error, WER, or hang event was found in Application events 1000/1001/1002 between 10:30 and 10:35 local time. No System events 2004/4101/41/6008 were returned for the same interval. The inspected Crashpad directory still retains sidecars without matching native dumps; native exception code and stack remain unavailable. Absence of these Windows events does not rule out all resource/driver involvement. Server-side receipt of the local Crashpad ID is unverified.
Please investigate this occurrence alongside the prior three, including stale-route recovery, persisted-conversation versus client-new-thread ownership, and guest attachment/reentrancy. Please provide a signed fixed build or supported mitigation and a private native-dump capture procedure. This is a new occurrence on the same affected installation, not a claim of four independent users.
No private chat contents, project names, page history, user paths, credentials, raw logs, screenshots or dumps are included.
ljh006008-blip commentedon Oct 18, 2026
Additional occurrence on Windows with MSIX package version
26.1013.4894.0(identified from the installed app path recorded in desktop logs; About-dialog version not independently checked).Environment:
Microsoft Windows NT 10.0.19045.0 x64.Two desktop-app crashes were recorded on 2026-10-18:
Both local Crashpad sidecars contain exactly:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}The second crash occurred while a coding task was cleaning up its in-app browser verification tab. The previous desktop log ends at 11:13:48.468Z with this sequence (identifiers and private paths omitted):
The Crashpad sidecar was last written at 11:13:49Z, and a new desktop process log starts at 11:13:56Z after the app was reopened.
This appears consistent with the browser-route/tab-teardown failure described in this issue. It is a temporal correlation, not a confirmed native root cause. Only the second crash's teardown sequence was checked in detail.
Impact: the desktop app exits during ongoing work and the user must reopen it to continue. This is not merely a tool-call failure.
No matching Application Error / Windows Error Reporting / Application Hang events (1000/1001/1002) were found in the Windows Application log during the inspected eight-hour window. No .dmp files remain in the inspected app Crashpad directory, so an exception code/native stack is unavailable. There is no established evidence here that OOM, a GPU fault, or an automatic update caused these crashes.
Expected: closing a verification tab or encountering a stale browser-route association should not terminate the desktop app.
This report was posted at the affected user's explicit request. Raw session transcripts, project content, local usernames/paths, and conversation IDs have been omitted.
qiu7824 commentedon Oct 21, 2026
Additional occurrence on Windows with MSIX package 26.1016.6573.0: two more whole-app crashes on October 21, 2026, including both IAB tab creation/attachment and explicit tab teardown.
Environment
10.0.26300.OpenAI.Codex_26.1016.6573.0_x64; executable:ChatGPT.exe. Package version is verified from the process path and matching desktop logs, not the About dialog.buildNumber=21161.ChatGPT.exefile/product version:155.0.8059.80(reported separately from the MSIX version).cua_replto verify a local web application.Windows reliability history records a successful Codex package update at 13:35:41 UTC+8 that day. Both incidents occurred afterward, but this chronology alone does not establish an update regression.
Crashpad evidence
These are sidecar filesystem creation/last-write timestamps, not decoded native exception timestamps. The report IDs below are local Crashpad IDs; server-side receipt has not been verified.
380fe115-670f-4c94-a4a8-acfedc31ffbd8e697ce9-8359-4256-9dec-e1fefa3ce3b9Both sidecars contain exactly:
{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}The desktop app disappeared on both occasions. The corresponding task turns are recorded as
interrupted. The application was reopened afterward.Incident 1: creation/attachment immediately before the crash
Selected desktop-log entries below retain UTC timestamps; identifiers and unrelated fields are omitted:
The process log ends there. The matching sidecar appears approximately 0.575 seconds later. This incident adds a creation/attachment observation; it does not prove that debugger attachment itself caused the native crash.
Incident 2: successful explicit close followed by main-process crash
The final browser tool call was an awaited
tab.close()(variable name normalized), recorded as completed in 40 ms. Immediately afterward, the desktop log ends with:The matching sidecar appears approximately 0.629 seconds after the final log entry. A new main process started at 09:26:00Z.
Diagnostic limits and expected behavior
The second sequence closely matches this issue's teardown pattern. The shared native root cause remains unconfirmed. Creating or closing an automated browser tab, or rejecting a stale tab/session association, should not terminate the desktop app or interrupt the task. Please include both guest attachment and last-tab teardown/PiP cleanup in investigation and regression coverage.
Project names, local user paths, conversation IDs, page contents, credentials, and full transcripts are omitted from this public report.