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

What version of the Codex App are you using?

• Microsoft Store package: OpenAI.Codex 26.818.5229.0
• Previous package immediately before the update: 26.818.2441.0

What platform are you using?

Windows 11 x64, OS build 10.0.26100.6584.

What issue are you seeing?

Codex Desktop has repeatedly terminated over several days. The most clearly diagnosed occurrence is a real Electron main/browser-process crash shortly after an existing task restored two persisted in-app-browser sidebar tabs.

The whole desktop app disappeared without a crash dialog, interrupted active work, and had to be relaunched.

Crashpad recorded:

capture_kind=crash
ptype=browser
osarch=x86_64
local_report_uuid=8df12fb5-3221-4673-9b55-53de63445d56

A separate earlier exit during the same session was caused by the Microsoft Store/MSIX update path using ForceTargetApplicationShutdownOption. That update-driven exit is distinguished from the later Crashpad crash below.

Sanitized timeline

Local time (UTC+08:00), 2026-08-23:

17:31:37  AppX destroys the old 26.818.2441.0 container with
          ForceTargetApplicationShutdownOption.
17:31:45  Package update registers 26.818.5229.0.
17:31:47  Updated app relaunches.

17:40:47  Existing task restores two persisted in-app-browser sidebar tabs;
          both webviews attach and become DOM-ready.
17:41:12  Main desktop log stops.
17:41:28  Crashpad records capture_kind=crash, ptype=browser.
17:41:29  AppX container is destroyed.
17:43:35  App is manually relaunched.

There was no second package deployment/update at 17:41, so the later termination was not another forced-update shutdown.

What steps can reproduce the bug?

This is intermittent, but the observed sequence was:

1. Launch or relaunch Codex Desktop on Windows with one or more tasks active.
2. Open an existing task that has two persisted in-app-browser sidebar tabs.
3. Allow both browser webviews to restore, attach, and become DOM-ready.
4. Continue working or leave the task active.
5. Roughly 40 seconds later, the entire Codex Desktop process exits.

Immediately before the crash, the desktop logs showed the two browser sidebar guests attaching and repeated mcp_app_sandbox.attach_unmatched warnings. The timing suggests an in-app-browser restore/lifecycle regression, but the available evidence does not prove the faulting native module.

What is the expected behavior?

• Restoring persisted in-app-browser tabs should not crash the Electron browser/main process.
• A stale or failed webview should be isolated and recoverable while the desktop host remains alive.
• App updates should warn about and coordinate shutdown when active tasks are running.
• Active turns should resume cleanly after an update or crash.

Additional diagnostics

• No matching Windows Application Error, WER, or .NET Runtime event was recorded for the Crashpad occurrence.
• No Resource Exhaustion Detector event was present.
• Approximately 24.6 GB of 39.6 GB physical memory was free.
• No GPU reset, WHEA, or Kernel-Power signal occurred in the same window.
• Session JSONL remained parseable after restart; task state was not corrupted.
• An older renderer Crashpad record also exists from the preceding day, consistent with repeated desktop instability rather than a single update event.
• Raw logs and dumps are intentionally not attached publicly because they can contain local paths, browsing history, prompts, and project data. Sanitized excerpts can be provided if maintainers request them.

Potentially related, but not exact duplicates:

• #33827 — restoring an in-app browser silently closes Codex in a Goal Mode lifecycle case
• #33202 — browser creation with multiple active tasks
• #38175 — in-app browser crash during localhost navigation

Start by reproducing the Windows relaunch sequence with two persisted in-app-browser sidebar tabs, then inspect desktop logs around webview attachment and repeated mcp_app_sandbox.attach_unmatched warnings. Compare the behavior with related issues #33827, #33202, and #38175; done means persisted tabs no longer terminate the host and a failed webview remains recoverable.