[BUG] Claude Desktop — recurring silent GPU-process crash kills entire app during web research (4-5×/day), no recovery, no crash dump

Preflight Checklist

• [x] I have searched existing issues 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?

Claude Desktop app, version 1.21459.0 (also reproduced on 1.20186.9 before auto-update)
Windows 10 Pro 10.0.19045, MSIX package (Claude_pzs8sxrjxfjjc)
Claude Code 2.1.209
The Electron GPU subprocess crashes and is not recovered by the app — instead of Chromium's normal silent GPU-process respawn, the entire application goes unresponsive for 18-30 minutes, then requires a full cold restart. This happened 4 times in ~2.5 hours in one session (2026-07-15, 11:09:14 / 11:40:41 / 12:28:52 / 13:16:26 local time), and 4-5 times total that day — every occurrence during web-research tasks (both inline browser navigation and delegated research subagents).

Evidence from %APPDATA%\Claude\logs\main.log:
2026-07-15 13:16:26 [info] GPU process gone: {
type: 'GPU',
reason: 'crashed',
exitCode: 101457950, // 0x60C201E, identical across all 4 occurrences
serviceName: 'GPU'
}

main.log

What Should Happen?

The GPU process should crash-and-recover transparently (as Chromium normally does), without taking down the rest of the app. At minimum, the app should never lose an entire session silently — it should either survive the GPU-process death, or clearly notify the user and preserve/resume the in-progress work (tool results, conversation state) instead of going fully unresponsive for 18-30 minutes and requiring a cold restart with all research progress lost.

Error Messages/Logs

2026-07-15 13:16:26 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,   // 0x60C201E, identical across all 4 occurrences
  serviceName: 'GPU'
}

Steps to Reproduce

Steps to Reproduce

Open Claude Desktop and start a session in Claude Code.
Run a web-research task that uses the browser tool — either inline (direct navigate/browser-tool calls in the main thread) or delegated to a research subagent (e.g. tech-researcher) that browses external sites.
Continue normal browsing/navigation activity (multiple page loads) for a few minutes.
At an unpredictable point (observed after anywhere from a few minutes up to ~45 minutes of active browsing), the app becomes fully unresponsive — no further output, no error shown to the user.
Check %APPDATA%\Claude\logs\main.log — a GPU process gone: { reason: 'crashed', exitCode: 101457950 } entry appears at the exact moment the session died.
The app stays silent for 18-30 minutes, then auto-restarts (Starting app in the log). All in-progress work/session state from before the crash is lost.
Reproduced 4 times in one afternoon (2026-07-15, at 11:09, 11:40, 12:28, 13:16 local), each time during web-research activity, same exit code every time. Not consistently tied to one specific site or one specific tool call — happens across different research tasks, both inline and subagent-delegated.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown / not determined. The crash was reproduced on both app version 1.20186.9 and 1.21459.0 (auto-updated mid-session) — the update did not resolve it, so I cannot confirm any version where this issue was absent. This may not be a regression from a specific version; it could be an ongoing issue that simply wasn't triggered before because browser-tool-heavy research sessions weren't run as frequently.

Claude Code Version

Claude Code 2.1.209

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Full main.log excerpts (GPU-crash entries + surrounding [process-memory] telemetry) available on request — happy to attach a trimmed excerpt if a maintainer needs it (didn't paste full logs here to avoid noise/potential unrelated local paths).
Ruled out before filing: Windows TDR/driver-timeout events (EventID 4101 — none found), WER Application Error events (EventID 1000 — none found), Crashpad .dmp files (folder empty — no native crash dump captured for any of the 4 occurrences), and OOM/memory pressure (1.1-2.1 GB free at crash time, not critical).
The identical exit code (101457950 / 0x60C201E) across all 4 occurrences suggests a specific, reproducible internal fault rather than random corruption.
Impact note: each occurrence burns tokens on conversation context plus the research/search tool calls themselves, with zero usable output since the session dies before results are saved — this happened 4-5 times in one day. Requesting that Anthropic support review token compensation for these sessions given the reproducible, app-side nature of the failure (not user error).
Happy to provide session IDs / exact timestamps of all affected sessions if useful for correlating with server-side telemetry.