[BUG] Claude Desktop — recurring GPU process crash tied to Preview feature, corrupts MSIX package

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?

App: Claude Desktop (Windows, MSIX), version 1.26832.0.0
Hardware: Laptop with hybrid GPU — NVIDIA GeForce RTX 4060 Laptop GPU + AMD Radeon 780M integrated. NVIDIA driver updated 2026-07-21 (~2 weeks before crashes began).

Timeline:

• 2026-08-06: crashes began, app failing to start with a Windows "try to repair" dialog.
• Confirmed crash timestamps: 2026-08-06 19:53, 2026-08-07 12:11, 2026-08-07 12:35, 2026-08-08 11:52.
• Recurring daily since, including after a clean reinstall.

Core symptom:
main.log shows the Electron GPU process dying every time:
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
Every single occurrence (4/4) is associated with the Preview feature (embedded live preview of a local dev server) — either [Preview] capturePreviewScreenshot or [Preview] navigatePreview immediately precedes the crash. It has never happened during general app use outside of Preview.

Secondary bug — package corruption: each time the GPU process crashes, the MSIX package registration becomes corrupted. Get-AppxPackage Claude reports Status: Modified, NeedsRemediation. In this state, Windows blocks relaunch with its own "try to repair" dialog, and the in-app Settings → repair/reset options do not resolve it (they can't fix a NeedsRemediation state). The only working recovery found is Remove-AppxPackage followed by a fresh install — which restores the app until the next Preview-triggered GPU crash repeats the cycle.

Troubleshooting already done (none resolved it at the root):

1. Windows Graphics Settings → forced power-saving mode (AMD iGPU only) — no effect.
2. Updated AMD Radeon 780M driver — no effect.
3. Cleared Electron GPU caches (GPUCache, DawnGraphiteCache, DawnWebGPUCache) — no effect.
4. Windows Graphics Settings → forced high-performance mode (NVIDIA dGPU only) — no effect.
5. Disabled hardware acceleration via the hidden native menu toggle (isHardwareAccelerationDisabled, found via app.asar strings, not exposed in the visible Settings dialog) — delayed the crash for a couple of interactions but did not prevent recurrence; the crash returned the next morning with hardware acceleration still confirmed disabled.
6. Repeated Remove-AppxPackage + reinstall — restores the app each time but is only a temporary patch.

Evidence ruling out a driver-level cause: cross-checked the Windows System event log (not just the app's own log) at all 4 known crash timestamps for display-driver-failure signals (nvlddmkm, amdkmdap, TDR events). Found none. If the GPU driver itself had actually crashed or reset, Windows would have logged it — it did not, at any of the 4 occurrences.

Conclusion / ask: this looks like an app-level bug in the Preview feature's GPU compositing path, specific to hybrid-GPU hardware, and independent of the hardware-acceleration setting. Requesting: (1) investigation of the Preview GPU compositing crash on hybrid-GPU systems, and (2) a fix so that a GPU-process crash doesn't corrupt the MSIX package registration — that compounding failure is what turns a recoverable crash into a full app reinstall each time.

What Should Happen?

The Preview feature should not crash the Electron GPU process on hybrid-GPU hardware (NVIDIA + AMD). If the GPU process does crash, it should recover gracefully (e.g., fall back to software rendering or restart the GPU process) without corrupting the app's MSIX package registration. Currently, every GPU-process crash leaves the package in a NeedsRemediation state (confirmed via Get-AppxPackage), which blocks the app from reopening at all — Windows shows a "try to repair" dialog, and the in-app repair/reset options in Settings cannot resolve it. The only working recovery is a full Remove-AppxPackage + reinstall. A single feature crash should never require a full app reinstall to recover.

Error Messages/Logs

# main.log — 2026-08-08 crash
2026-08-08 11:52:04 [info] [Preview] Server ready (HTTP responding) { serverId: '965fd9bd-723c-4c33-a3a4-2782b736bdce' }
2026-08-08 11:52:04 [error] [Preview] navigatePreview failed {
  serverId: 'preview-local_b42f33ff-a9f1-4f79-b216-0c6aeaa3dbf4',
  origin: 'http://localhost:3000',
  error: ''
}
2026-08-08 11:52:05 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

# main.log — 2026-08-07 crash (same signature, different Preview call)
GPU process gone: reason: crashed, exitCode: 101457950
tied to [Preview] capturePreviewScreenshot compositing path

# Get-AppxPackage Claude — after every GPU crash
Name            : Claude
PackageFullName : Claude_1.26832.0.0_x64__pzs8sxrjxfjjc
Status          : Modified, NeedsRemediation

Si el formulario deja espacio para más contexto, puedes añadir: "GPU process crash signature (exitCode: 101457950) confirmed identical across all 4 occurrences (2026-08-06 19:53, 2026-08-07 12:11, 2026-08-07 12:35, 2026-08-08 11:52); Windows System event log shows zero display-driver-failure/TDR events at any of those timestamps, ruling out an actual driver crash."

Steps to Reproduce

1. Open a project/session in Claude Desktop that starts a local dev server and uses the Preview panel (embedded live preview, e.g. via a local server at http://localhost:3000).
2. Interact with Preview in a way that triggers a screenshot capture or a navigation within the preview pane (observed trigger events in logs: [Preview] capturePreviewScreenshot and [Preview] navigatePreview).
3. The Electron GPU process crashes shortly after (GPU process gone: reason: crashed, exitCode: 101457950).
4. The app becomes unusable; Get-AppxPackage shows the MSIX package in Modified, NeedsRemediation state, and relaunching triggers Windows' own "try to repair" dialog instead of opening the app.

Note: the correlation with Preview activity is 100% across all 4 observed crashes (confirmed on hybrid NVIDIA/AMD GPU hardware), but I haven't isolated the exact minimal action inside Preview that triggers it (e.g., a specific screenshot capture vs. any navigation) — it doesn't reproduce during general app use outside of Preview.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Based on the Windows AppX deployment log, an auto-update to version 1.25927.0.0 was registered on 2026-08-06 at 5:02 PM. The first GPU-crash was logged roughly 3 hours later, at 19:53 that same day. A further auto-update to 1.26832.0.0 happened later that same night (11:01 PM) but did not resolve the issue — crashes continued on 2026-08-07 and 2026-08-08 while running 1.26832.0.0 (still the currently installed version). The most likely last-known-good version is 1.24012.11.0 — it's the version that was active and being cleaned up from the package repository at the time of the 1.25927.0.0 update, meaning it was the one previously installed. I can't independently confirm it ran crash-free for a period beforehand (no older logs survived to check that), but it's the version immediately preceding the update that preceded the first crash.

Claude Code Version

Claude Code version: 2.1.226

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

$pkg = Get-AppxPackage Claude
$exe = Join-Path $pkg.InstallLocation 'app\Claude.exe'

Invoke-CommandInDesktopPackage `
  -PackageFamilyName $pkg.PackageFamilyName `
  -AppId Claude `
  -Command $exe `
  -Args '--disable-gpu'