[Windows Desktop 26.818.5229.0] Repeated browser/main crashes when reopening oversized browser-heavy tasks

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

• #40062

Powered by Codex Action

Follow-up: complete 7-day scan and two newer crashes

The original report understated the frequency because only two events had been correlated at that point. A complete scan of Crashpad, desktop logs, AppModel/AppX events, and the affected session files found 8 Crashpad captures from 2026-08-22 through 2026-08-24:

• 1 embedded-browser renderer crash with an explicit reason=oom
• 1 browser-process capture caused by the already-documented forced MSIX update shutdown
• 6 genuine Electron browser/main-process crashes with no concurrent update

Sanitized list of the six main-process crashes (local time UTC+08:00):

2026-08-23 17:41:28  8df12fb5-3221-4673-9b55-53de63445d56
2026-08-23 17:58:22  b7e0b975-aebb-4b17-b082-6b7a8e3def81
2026-08-23 18:52:14  5581e86d-e1d4-4af4-b9a8-814698f1c216
2026-08-23 18:54:10  8f9e3067-89be-40e0-90a4-b1f9ce630508
2026-08-24 15:07:52  b769022c-4f00-4785-b8ec-da8d60dd1101
2026-08-24 15:21:10  6ee1d8b8-13b6-4a6f-a588-1fca3606fe0f

Every one has capture_kind=crash, ptype=browser, and osarch=x86_64.

AppModel confirms container destruction immediately after the two newest captures and automatic relaunch about three seconds later:

15:07:52 Crashpad capture
15:07:53 AppX container destroyed
15:07:56 new desktop container/process created

15:21:10 Crashpad capture
15:21:11 AppX container destroyed
15:21:14 new desktop container/process created

New high-confidence trigger: oversized browser-heavy session state

The repeatedly affected task has a rollout JSONL of approximately:

1,874.32 MiB
135,376 lines
5,004 lines larger than 100 KiB
34 lines larger than 1 MiB
largest line: 4,099,080 characters (image/tool payload)

A second browser-heavy task involved in the 17:58 crash is:

626.77 MiB
74,130 lines
1,541 lines larger than 100 KiB
23 lines larger than 1 MiB
largest line: 4,099,080 characters (image/tool payload)

When the 1.87 GiB task is opened, the desktop logs show two concurrent thread/read requests taking 20–29 seconds. The requests complete shortly before the main-process crash. The task also restores persisted in-app-browser state.

The two newest reproductions were nearly identical:

1. Switch to the oversized existing task.
2. Restore one persisted in-app-browser sidebar tab.
3. Log mcp_app_sandbox.attach_unmatched.
4. The browser sidebar becomes DOM-ready.
5. Duplicate thread/read calls take approximately 27–29 seconds.
6. Roughly 50 seconds after the task/browser restore begins, Crashpad records ptype=browser and the whole AppX container is destroyed.

The earlier renderer capture at 2026-08-22 04:00:41 is especially relevant:

browser sidebar render process gone
exitCode=-536870904
reason=oom

During that long browser-heavy session, the desktop reached a maximum of 19 in-app-browser tabs and emitted 62 attach_unmatched warnings. The 17:58 main-process crash session reached 16 browser tabs and emitted 17 attach_unmatched warnings.

The two newest main-process sessions also produced large bursts of ResizeObserver loop completed with undelivered notifications (365 occurrences before the 15:07 crash and 77 before the 15:21 crash). This may be a symptom of renderer/UI churn rather than the native root cause.

Updated assessment

The strongest evidence now points to an interaction between:

1. unbounded retention of large image/tool outputs in long-lived rollout JSONL,
2. expensive and duplicated thread/read processing when reopening a very large task,
3. persisted in-app-browser/webview restoration and unmatched sandbox attachments, and
4. insufficient isolation when a renderer or Electron browser/main process reaches a per-process resource or lifecycle failure.

There was no Windows Resource Exhaustion Detector event and no system-wide low-memory condition, so the explicit renderer reason=oom is more consistent with a Chromium/Electron renderer or V8/process-level limit than exhaustion of all physical RAM.

Suggested product-side protections:

• compact or externalize large image/tool payloads instead of retaining them inline indefinitely;
• avoid duplicate full task reads during resume;
• lazily/page-load large task history;
• cap or garbage-collect stale persisted browser tabs;
• discard invalid/unmatched webview routes during restore;
• isolate a webview/renderer OOM so it cannot terminate the desktop main process.

Raw files are not attached because they contain prompts, local paths, browsing history, and project data. The sizes, counts, timings, UUIDs, and warning names above are sanitized.

Adding a second, independent Windows reproduction with the same current build.

Sanitized evidence

• Codex Desktop package: 26.818.5229.0
• Platform: Windows 11 x64
• Crashpad retained nine reports over roughly three days, all with:

``text
capture_kind=crash
ptype=browser
osarch=x86_64
``

• Seven reports occurred on 26.818.5229.0. Two earlier reports had the same lifecycle signature on 26.818.2872.0 and 26.818.3698.0, so the current update appears to increase frequency rather than introduce the entire bug.

Every crash report correlated with a main desktop log that stopped less than one second earlier. All nine logs ended during the same in-app-browser teardown sequence:

unregistered debugger listener reason=target-close
renderer disposed browser sidebar webview
browser sidebar guest torn down
browser tab lifecycle action=closed
(optional) created browser use host
browser-use PiP metadata received with tabID=undefined
<browser/main process terminates>

Shortly before teardown, the logs repeatedly contained:

Cannot find context with specified id
iab rejected tab for route
Failed to upsert Browser Use PiP content

Persisted browser-tab state grew across restarts: the app-level count observed at crash time increased from 6 to 10. The next restart restored 11 browser tabs across two tasks and spawned 21 desktop subprocesses. The machine still had ample free memory, with no matching Windows Application Error, resource-exhaustion event, or system instability, so this does not look like system-wide memory pressure.

The persistence behavior suggests the app crashes before committing tab removal, then restores the stale route on the next launch. A targeted workaround is to fully quit Codex, back up the global state file, and remove only the affected thread-tab-routes-v1:* entries.

No raw logs, session transcripts, task IDs, report UUIDs, local paths, URLs, prompts, repository names, or account information are included here because those artifacts may contain private data.

Follow-up (2026-08-24): another crash occurred with the same capture_kind=crash, ptype=browser signature. Immediately before exit, the desktop log shows 12 restored in-app browser tabs, repeated "No ChatGPT browser route is available for browser session" warnings, and then "iab rejected tab for route" with tabRouteKey=null followed by webview teardown. No raw logs or user data are attached.

Important correction: the previously attempted local persisted-tab reset did not actually apply, so this recurrence should not be treated as evidence that the workaround failed.

Adding another independent Windows reproduction with the same Crashpad main/browser-process signature.

Sanitized evidence

• Codex Desktop builds affected:
• 26.818.5229.0: 3 crash records
• 26.818.8289.0: 5 crash records
• 26.820.7780.0: 2 crash records after reinstall
• Ten Crashpad sidecar records were observed on 2026-08-25.
• All ten contain exactly:
• capture_kind=crash
• ptype=browser
• osarch=x86_64
• Eight occurred before reinstalling Codex.
• The reinstall completed at approximately 22:47:23 local time (UTC+02:00). The same crash signature recurred at 22:47:37 and again at 23:16:06 on 26.820.7780.0.
• The entire Codex desktop window closes and must be relaunched.

The first post-reinstall crash occurred about 14 seconds after reinstall completion, before any intentional use of Google Chrome or the in-app Browser. Therefore, although the Crashpad signature matches this issue, I cannot confirm restored browser tabs or browser navigation as the trigger. Here, ptype=browser identifies the Electron/Chromium main process and does not by itself establish the root cause.

No native stack or minidump is available. The two post-reinstall sidecars are still present; the eight earlier sidecars were removed by the uninstall, but their timestamps, versions, and signatures were preserved in sanitized diagnostic notes.

No raw logs, local paths, project names, task/conversation IDs, browsing data, or report UUIDs are included publicly. I can provide targeted sanitized excerpts if maintainers indicate what would be useful.