Claude Desktop (Windows): heavy ad-stack page in in-app Claude Browser pane crashes entire app, no crash dump, kills all hosted sessions

Adding a second data point — possibly the same underlying failure via a different entry point.

I hit the same signature (whole app dies, zero Crashpad dump, no Application Error event) twice on Windows, but through the Claude for Chrome extension (native host bridge reading page content into a Claude Code Desktop session), not the in-app Claude Browser pane / preview_start/navigate.

• 2026-08-13, 16:05 local: last logged activity was a tool_result returning page content from a content-heavy page (ahrefs.com) via the Chrome extension. chrome-native-host.log stops one second later. The only Windows Event Log entry at that time is informational — Claude VM Service stopped (Id 1) — no Error-level event, no .dmp anywhere on the system.
• 2026-08-12, ~00:27–00:28 local: three separate session .jsonl files were rewritten within a 45-second window — consistent with your "kills every hosted session on the machine" observation, just via a different trigger (large text payload from a file read, not a webpage).

Claude Code version: 2.1.227 (bundled), claude-desktop entrypoint. chrome-native-host.log also shows a recurring Chrome disconnected (EOF received) pattern across several days prior — might be relevant if the extension bridge and the in-app browser pane share underlying process/IPC handling.

Not sure if this is the exact same code path as the in-app browser pane or a sibling one, but the shared signature (whole-process death, zero crash artifact, multi-session kill) seemed worth linking here.

Update — reproduced on a second entry point, and found a workaround.

Second vector: besides the Chrome extension, I also hit the identical crash through the in-app Claude Browser MCP pane. Last logged action before one crash was mcp__Claude_Browser__computer ("action":"wait"), model claude-sonnet-5, so both the Chrome extension bridge and the internal Claude Browser MCP server trigger the same whole-app death. Same signature each time (no Application Error event, no Crashpad dump).

Root cause is GPU process init, not page content. When I launched with --disable-gpu to test, I caught the failure live in stdout:

GPU process exited unexpectedly: exit_code=101457950
GPU process launch failed: error_code=18 (repeated 5×)
FATAL:content\browser\gpu\gpu_data_manager_impl_private.cc:418] GPU process isn't usable. Goodbye.

So the crash is a fatal GPU-process launch failure (error_code=18), not anything about the page being loaded. This lines up with the GPU-compositing crash class in #80468 / #80444 / #83028.

Environment: AMD Radeon RX 7800 XT (discrete) + Ryzen iGPU — a dual-GPU Windows setup, the same configuration flagged as a known failure class in those issues. Setting a per-app GPU preference (Settings → Display → Graphics → Claude → High Performance) did not stop the crashes on its own.

Workaround that works for me: --disable-gpu alone was not enough — it still tried to spawn the GPU process and failed (Failed to create shared context for virtualization). The app only launches stably with the full set of flags: --disable-gpu --disable-gpu-compositing --disable-software-rasterizer --disable-gpu-sandbox. With all four, the app starts and the browser pane no longer takes down the whole process. Tradeoff is a slightly less smooth UI, but it's stable.

Claude Code version: 2.1.227 (bundled), claude-desktop entrypoint. Desktop package Claude_1.28929.0.0_x64.

Follow-up with the mechanism, pinned down on a second machine: the in-app browser's HTTP request interception (webrequest:before-send-headers) appears to run on the app's UI thread. A page generating high request volume - a busy dev server, or worst case an ad-stack page firing hundreds of prebid/identity-sync/GAM requests - blocks that thread (we observed stalls up to ~11 s) until the app dies without Crashpad ever firing. Hardware-independent, reproduces across machines, and consistent with the evidence above: death mid-ad-stack activity, no dump, and one crash with 6.4 GB free RAM (so not OOM). Suggested focus: take the interception handling off the UI thread / make it async, and watchdog the pane.

I hit what looks like the same root cause today (Windows Store package Claude_1.30096.1.0_x64__pzs8sxrjxfjjc, Windows 11 Pro 10.0.26200): the whole desktop app died 4 times in about 30 minutes during a single Claude Code session. No crash dialog appeared — the app just disappeared and had to be relaunched.

The two most recent crashes both happened right after opening the in-app Browser pane (preview_start → navigate) on a URL that serves a Cloudflare interactive bot-check/challenge page (https://www.amiami.jp/top/page/c/gundam.html?page=rt_ctg), so it seems like it's not only heavy ad-stacks (as in this issue) but any sufficiently complex/interactive JS in the Browser pane that can take the whole app down.

One extra data point that might help narrow this down: the Windows Application event log + C:\ProgramData\Claude\Logs\cowork-service.log show CoworkVMService repeatedly stopping and restarting at timestamps matching the crashes, e.g.:

2026/08/14 17:12:09.130121 [IdleCheck] Session ...: starting idle timer now
2026/08/14 17:13:17.094176 [Server] Persistent RPC: connection ended: failed to read length: EOF
2026/08/14 17:13:17.094176 [Server] Session ... has no active connections, idle timeout starts
2026/08/14 17:14:14.767700 Starting CoworkVMService as Windows service
2026/08/14 17:14:14.795955 Claude VM Service starting...
2026/08/14 17:14:14.797013 Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.

The "failed to configure recovery actions: open service: Access is denied" warning appears on every service start. Not sure if it's related to the crash itself or a separate pre-existing permissions issue, but it stood out since it's specifically about the VM service's ability to recover.

Same underlying pattern as described here: no crash dump captured, no process isolation between the Browser pane and the main app, so a single problematic page kills the whole session (and silently drops any in-progress background shell tasks with no completion record).