[BUG] Desktop 1.24012.9 (Windows MSIX): GPU process crash (exitCode 101457950) while the Browser preview pane holds multiple tabs - main process dies with it, app cannot be relaunched

## Summary

On Windows (MSIX/Store build), opening several tabs in the built-in Browser preview pane (Preview / browser-preview-* server, the surface driven by the browser:* MCP tools) drives the Electron GPU process to crash. The crash is logged only at [info] level as GPU process gone: { reason: 'crashed' } — and the main process then stops entirely: its 60-second [process-memory] heartbeat never logs again, and main.log goes silent until the next manual app start.

Two occurrences on consecutive days, both with the identical exit code 101457950 (0x060C201E), so this is a deterministic signature rather than a random OOM (the machine had ~16 GB RAM free in both cases).

After the crash the app cannot be started again — leftover claude.exe processes keep the MSIX single-instance lock, and the only recovery the user found was rebooting Windows and letting Windows repair the package.

Environment

| | |
|---|---|
| Claude Desktop | 1.24012.9 (MSIX, Claude_1.24012.9.0_x64__pzs8sxrjxfjjc) |
| CCD | 2.1.219 |
| Node/Electron | 24.18.0 |
| OS | Windows 11 Home 10.0.26200 |
| CPU / RAM | Intel Core i9-14900HX / 32 GB |
| Active GPU at crash time | Intel UHD Graphics (iGPU), driver 32.0.101.6790 (2025-04-28) |
| Second GPU | NVIDIA GeForce RTX 4070 Laptop, driver 32.0.15.8180 — fully power-gated at crash time (Lenovo Legion "Hybrid Mode: Auto"); enumerated as phantom device Code 45, nvlddmkm stopped |
| Display | 1829×1143 @ 165 Hz, scaleFactor 1.75 |

Important repro condition: both crashes happened while the laptop's discrete GPU was powered off by Lenovo's Hybrid-Auto mode, i.e. all Chromium compositing ran on the Intel iGPU against shared system memory, with a GPU driver ~15 months old. This is the default state of a very large class of Windows gaming/creator laptops on battery or light load, so it is not an exotic configuration.

Steps to reproduce

1. Open a local session and let the assistant use the Browser preview pane (preview_start / navigate).
2. Open 4 tabs in that pane and browse normal public web pages, mixing in javascript_tool / screenshot calls.
3. Within ~2 minutes of the 3rd–4th tab, the GPU process crashes.

Evidence — crash 2 (2026-07-27), from %APPDATA%\Claude\logs\main.log

GPU process RSS climbing as browser tabs are added:

07:34:57 [Preview] Created browser preview { serverId: 'browser-preview-<ts>-0' }
07:35:23 [PreviewContext] Opened preview user tab      (tabId: tab-1)
07:35:28 [PreviewContext] Opened preview user tab      (tabId: tab-2)
07:35:32 [PreviewContext] Opened preview user tab      (tabId: tab-3)
07:35:50 [process-memory] ... electron_gpu:14892:445MB ... sys_free=16623MB/32476MB
07:36:50 [PreviewContext] Opened preview user tab      (tabId: tab-4)
07:36:55 [process-memory] ... electron_gpu:14892:528MB ... sys_free=16330MB/32476MB

(GPU process RSS before the browser pane was opened: 216–271 MB. After 4 tabs: 528 MB.)

Then the crash:

07:37:10 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}
07:37:10 [warn] [Preview] capturePreviewScreenshotIfChanged failed: {
  error: [Error: UnknownVizError] { [message]: 'UnknownVizError' }
}

In the renderer log (claude.ai-web.log), same second on the previous day's crash:

2026-07-26 10:40:18 [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost

After 07:37:10 main.log contains nothing at all — not even the [process-memory] interval line that had been emitted every ~60 s — until:

07:44:11 [info] Starting app { appVersion: '1.24012.9', ... }

i.e. the main process did not survive the GPU child crash, and there was no recovery attempt logged.

Evidence — crash 1 (2026-07-26)

Same pattern, same exit code:

10:30:47 [PreviewContext] Opened preview user tab
10:31:07 [PreviewContext] Opened preview user tab
10:40:18 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
10:40:18 [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost      (renderer log)
11:55:55 [info] Starting app { appVersion: '1.24012.9', ... }             (next entry, 75 min later)

What I think the actual defects are

1. No recovery from gpu-process-gone. Electron surfaces this event; the app logs it at [info] and takes no action. The main process goes down with the GPU child. At minimum the app should restart the GPU process / fall back to software compositing and surface an error, rather than dying silently.
2. No crash artifact is kept. %APPDATA%\Claude\Crashpad\reports and \attachments are both empty after the crash, so there is no minidump to attach here.
3. Nothing is logged between the crash and the next launch, which makes this near-impossible for a user to diagnose — the log simply stops.
4. Unrecoverable relaunch on MSIX. Orphaned claude.exe processes hold the single-instance lock (%APPDATA%\Claude\lockfile); the app then refuses to start and Windows offers only "Repair". Same shape as #49551.
5. The Browser pane raises GPU load substantially (216 MB → 528 MB across 4 tabs) with no visible cap or tab-count guard, on a machine already running an aged iGPU driver.

Related existing issues (none covers the Browser-pane trigger)

• #67459 — GPU process gone: crashed on Windows MSIX, rendering never restored, permanently black window. Closest match, but Browser/preview pane is not named as a trigger; closed as not planned / invalid.
• #49551 — app goes blank, all claude.exe processes must be killed before it can reopen; closed as not planned.
• #45031 — MSIX build ignores ELECTRON_EXTRA_LAUNCH_ARGS, so GPU flags such as --disable-gpu-compositing cannot be applied as a workaround at all; closed as not planned.
• #56805 — Windows flickering/mouse lag, fixed for that reporter by --disable-gpu-compositing (unavailable on MSIX, see above).

Expected behaviour

• The GPU process crashing should not take down the main process.
• The app should relaunch the GPU process or fall back to software compositing, and tell the user what happened.
• A crash report should be written to Crashpad.
• On MSIX, a stale single-instance lock should be detected and cleared on next launch instead of requiring a package repair.

Note on environment (contributing factor, not the trigger)

Both crashes occurred with the discrete GPU power-gated by Lenovo Hybrid-Auto, so compositing ran on the Intel iGPU with a 2025-04-28 driver. In that window nvcontainer.exe also crashed repeatedly (NvBackend64.dll, 0xc0000409 STATUS_STACK_BUFFER_OVERRUN) — six times in the 20 minutes before crash 2, six times before crash 1 — which appears to be the NVIDIA backend reacting to its device disappearing from the bus, i.e. a symptom of the same power-gating rather than an independent fault.

After a reboot the discrete GPU enumerates normally (nvlddmkm running, status OK), which gives a clean A/B for whoever picks this up: the failing configuration is iGPU-only compositing.

That plausibly lowers the threshold for the GPU process to die. It does not explain the actual defect: an app should not lose its main process when its GPU child crashes, and it should leave behind a crash report and a log line when it does. Both are missing here.