Desktop app: GPU process crashes with identical exitCode when opening an external site in the built-in browser (Preview pane)

Summary

Opening an external HTTPS site in the desktop app's built-in browser (Preview / Browser pane) crashes the GPU process. The app becomes unusable; in my case recovery required running the installer's Repair and rebooting the machine — restarting the app alone was not enough. It happened three times in one afternoon, with a byte-identical exit code each time, which suggests a deterministic fault rather than random instability.

Environment

| | |
|---|---|
| Claude Code desktop app | 1.37937.0 (isPackaged: true) |
| OS | Windows 11 Pro 10.0.26200 |
| Platform / arch | win32 / x64 |
| Node | 24.18.1 |

Steps to reproduce

1. Open the Preview / Browser pane against a local dev server (http://localhost:<port>, Vite). This worked fine for roughly an hour — screenshots, DOM reads and JS execution all behaved normally.
2. Point the built-in browser at an external HTTPS site — in my case an internal production React SPA (URL withheld). At that moment one of its screens was rendering ~1,200 list cards, so the page was DOM-heavy.
3. The tool call returned success (navOk: true), but the GPU process crashed immediately afterwards and the app stopped being usable.

Expected: the page opens, or fails with a normal error. A heavy or misbehaving page should not take down the application.

Actual: GPU process crash; app unusable until Repair + reboot.

Log evidence

From %LOCALAPPDATA%\Claude\Logs\main.log:

2026-08-25 18:10:55 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}
2026-08-25 18:14:43 [info] Starting app { appVersion: '1.37937.0', isPackaged: true, platform: 'win32', arch: 'x64', nodeVersion: '24.18.1' }

2026-08-25 18:15:03 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}
2026-08-25 18:15:03 [warn] [Preview] capturePreviewScreenshotIfChanged failed: {
  error: [Error: UnknownVizError] {
    [stack]: [Getter/Setter],
    [message]: 'UnknownVizError'
  }
}
2026-08-25 18:18:28 [info] Starting app { ... }

2026-08-25 18:21:27 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}
2026-08-25 18:23:47 [info] Starting app { ... }

Two details that may help narrow it down:

• The [Preview] capturePreviewScreenshotIfChanged failed: UnknownVizError line lands on the same second as one of the crashes. That points at the Preview pane's screenshot capture specifically, rather than page rendering in general.
• exitCode: 101457950 is identical across all three crashes.

Crash dumps: none written

%APPDATA%\Claude\Crashpad\reports\ is empty, with a directory mtime of 2026-08-25 18:23 — i.e. it was touched at crash time but holds no .dmp. Either the reports were uploaded and cleared, or none were written. Worth checking whether GPU-process crashes are actually being captured, because from the user side there is nothing to attach.

Secondary observation (may be related, may be separate)

Later in the same session, driving the same heavy page through the Claude in Chrome extension (not the built-in browser), a screenshot call failed with:

CDP sendCommand "Page.captureScreenshot" timed out after 30000ms on tab <id>.
The renderer may be frozen or unresponsive.

The app survived that one. Mentioning it only because both failures involve capturing a screenshot of a DOM-heavy page, which might share a cause.

Note on /feedback

I tried /feedback from the CLI first. Two things made it a poor fit, in case that is useful signal:

• It writes a local zip (~/.claude/feedback-bundles/*.zip) rather than submitting anything, which was not obvious from the "Feedback bundle saved to …" wording.
• The crash happened in the desktop app (1.37937.0) while /feedback ran in the CLI (2.1.170), so the bundle captured a fresh 5-message CLI session with errors: [] — none of the crash context. There does not seem to be an equivalent path to report a desktop-app crash with its own logs attached.

Impact

High — the crash costs the running session and required an OS-level reboot to recover. The built-in browser was unusable for the task; I had to switch to the Chrome extension to finish the work.

I still have the full main.log and can share the relevant portions on request.