[BUG] GPU process repeatedly crashes (UnknownVizError) when using the in-app browser preview panel

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

Environment
Claude Desktop version: 1.40609.1 (MSIX / Windows Store package, family Claude_pzs8sxrjxfjjc)
Bundled Claude Code engine (CCD): 2.1.255
Node: 24.18.1
OS: Windows 11 Home, build 10.0.26200
GPU: NVIDIA GeForce RTX 2060 (driver 32.0.16.1656, 2026-08-20) + Intel UHD Graphics (driver 31.0.101.2141, 2026-03-30) — hybrid graphics laptop
Per-app GPU preference for Claude explicitly set to "High performance" (NVIDIA) via Windows Graphics Settings
Description
The GPU process crashes reliably whenever the in-app browser preview panel (browser-live-preview / cu-live-preview) loads content. The crash kills the whole app (not just the preview pane) and also severs the named-pipe connection to the "Claude VM Service" (Cowork helper), so the entire session becomes unusable and requires a full app restart. This happened 6 times in one day.

I initially suspected an outdated/hybrid-GPU driver issue and updated both the Intel and NVIDIA drivers, and forced the app to run on the discrete NVIDIA GPU. The crash persisted identically after both fixes, with the same error signature before and after — pointing to an app-level bug rather than a driver issue.

Steps to reproduce
Open Claude Desktop, start a local coding session.
Open/use the in-app browser preview panel to load a page.
Within 0-3 seconds of the preview loading a resource, the GPU process crashes and the app becomes unresponsive.
Actual behavior (log evidence, %LOCALAPPDATA%\Claude\logs\main.log)
Occurrence 1:

2026-09-01 20:10:05 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
2026-09-01 20:10:06 [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost
2026-09-01 20:10:06 [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost
2026-09-01 20:10:06 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
2026-09-01 20:10:06 [warn] [Preview] capturePreviewScreenshotIfChanged failed: {
error: [Error: UnknownVizError] { message: 'UnknownVizError' }
}
Occurrence 2 (identical pattern, ~1.5h later, after GPU driver update + forcing discrete GPU):

2026-09-01 21:51:49 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
2026-09-01 21:51:50 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
2026-09-01 21:51:50 [warn] [Preview] capturePreviewScreenshotIfChanged failed: {
error: [Error: UnknownVizError] { message: 'UnknownVizError' }
}
Two more occurrences same day with a different exit code but the same WarmLifecycle:preview correlation:

2026-09-01 20:53:53 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 34, serviceName: 'GPU' }
2026-09-01 21:32:06 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 34, serviceName: 'GPU' }
Downstream effect visible in %ProgramData%\Claude\Logs\cowork-service.log at the exact same timestamps:

[Server] Persistent RPC: connection ended: failed to read length: EOF
Expected behavior
The browser preview panel should not be able to crash the entire app's GPU process. At minimum, a Viz/GPU crash in the preview compositor should be recoverable without killing the whole application and the Cowork VM service connection.

Additional context
Already ruled out: outdated GPU driver (updated both Intel and NVIDIA to latest), GPU switching (forced discrete NVIDIA GPU via Windows per-app graphics settings), low disk space (117GB free), low RAM (4+ GB free consistently).
No Windows-level TDR/display-driver-timeout events logged around the crashes, and no Windows Error Reporting entries for Claude.exe — the crash appears to originate inside Chromium's Viz process itself, not a driver-level fault.
Workaround found: avoiding the browser preview panel avoids the crash.

### What Should Happen?

The browser preview panel should not be able to crash the entire app's GPU process. At minimum, a Viz/GPU crash in the preview compositor should be recoverable without killing the whole application and the Cowork VM service connection.

### Error Messages/Logs

```shell
2026-09-01 20:10:05 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
2026-09-01 20:10:06 [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost
2026-09-01 20:10:06 [warn] WebGL: CONTEXT_LOST_WEBGL: loseContext: context lost
2026-09-01 20:10:06 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
2026-09-01 20:10:06 [warn] [Preview] capturePreviewScreenshotIfChanged failed: {
error: [Error: UnknownVizError] { message: 'UnknownVizError' }
}

Repeated ~1.5h later with identical pattern (after GPU driver update + forcing discrete GPU):
2026-09-01 21:51:49 [warn] [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
2026-09-01 21:51:50 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
2026-09-01 21:51:50 [warn] [Preview] capturePreviewScreenshotIfChanged failed: UnknownVizError

Two more same-day occurrences with a different exit code, same WarmLifecycle:preview correlation:
2026-09-01 20:53:53 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 34, serviceName: 'GPU' }
2026-09-01 21:32:06 [info] GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 34, serviceName: 'GPU' }

Downstream effect at matching timestamps in cowork-service.log:
[Server] Persistent RPC: connection ended: failed to read length: EOF
```

### Steps to Reproduce

1. Open Claude Desktop, start a local coding session.
2. Open/use the in-app browser preview panel to load a page.
3. Within 0-3 seconds of the preview loading a resource, the GPU process crashes and the app becomes unresponsive.

### Claude Model

Sonnet (default)

### Is this a regression?

I don't know

### Last Working Version

_No response_

### Claude Code Version

1.40609.1

### Platform

Anthropic API

### Operating System

Windows

### Terminal/Shell

Windows Terminal

### Additional Information

_No response_

Start by reproducing the crash with the in-app browser preview panel and inspect %LOCALAPPDATA%\Claude\logs\main.log alongside %ProgramData%\Claude\Logs\cowork-service.log. Trace the PreviewContext, capturePreviewScreenshotIfChanged, and WarmLifecycle:preview entries. Done means preview loading no longer crashes the GPU process or makes the app and Cowork VM service unusable.

索引モデルが issue の本文から書いたものです。