Claude Desktop MSIX crash on Intel integrated GPU during browser pane use — reproducible, no workaround available

Adding detailed evidence from another affected machine — same crash signature, plus the full install-corruption chain. 6 forced reinstalls in 3 days on this box.

Environment

• Claude Desktop 1.26832.0 — MSIX Claude_1.26832.0.0_x64__pzs8sxrjxfjjc, SignatureKind=Developer (sideloaded from the claude.com installer). The app's telemetry reports build_type: "windows-store" and the updater logs MSIX detected: windowsStore=true, source=windowsStore — it believes it is Store-managed while actually sideloaded.
• Electron 42.7.0 · Chromium 148.0.7778.280 · Node 24.18.0
• Windows 11 Pro 10.0.26200 · ASUS laptop · Intel Core Ultra 7 155H · 32 GB RAM (22 GB free at crash time)
• GPU: Intel Arc integrated 0x7d55. Driver was updated mid-day (32.0.101.8801 / 2026-05-11 → 32.0.101.8860 / 2026-06-24) — crashes continued after the driver update, consistent with the CIG/vk_swiftshader mechanism described in #81341 / #83130 rather than a driver defect.

Crash signature (matches this issue, #81933, #81698)
Any session, fresh or old: as soon as the in-app browser pane opens (preview_start / navigate / screenshot), within ~30 s the GPU process dies and the whole window collapses. From %APPDATA%\Claude\logs\main.log:

GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 34, serviceName: 'GPU' }
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }   // = 0x060C201E

Occurrences on 2026-08-07 (PDT): 09:13:29, 09:49:26 (exit 34), 14:55:49, 15:15:05 (exit 0x060C201E), plus several on Aug 5–6. Each is preceded in the log by [WarmLifecycle:preview] Warming up session …. No TDR / display-driver reset events in the Windows System log at any crash time; not memory pressure (~2.3 GB Electron tree RSS, 22 GB system RAM free). The local Crashpad reports folder is empty, so dumps were presumably uploaded — Sentry user id 84df0746-b33f-4043-bd6d-e194f7da9e35 should locate them server-side at those timestamps. Notably, this machine's AppXDeploymentServer log also shows vk_swiftshader_icd.json in an orphaned-hardlink warning (event 1230) — the same component #81341 / #83130 identify.

Corruption chain after each crash (matches #83932)
On next launch Windows shows "This app can't open — try repairing it"; Repair always fails:

• Event 8107 "Illegal non-AppStore or non-AppInstaller package integrity validation attempted" + 8104 (trust label, 0x80070057) — Repair is structurally impossible for this sideloaded Developer-signed package
• Removal fails 0x80073CFA — "the PreserveApplicationData flag can only be used on a package that was deployed in development mode" (7+ occurrences across v1.25927/1.26832)
• Re-register fails 0x80073D02 with "Deployment aborts due to active service Claude_pzs8sxrjxfjjc!Claude" (CoworkVMService/tray processes still resident during the swap)
• Event 658: new version marked for deferred registration while the old version is still running; event 1230: orphaned hardlinks left from v1.24012

Requests

1. Exempt or Microsoft-sign the SwiftShader fallback (per #81341 / #83130), or relax the GPU process CIG policy; and/or ship a supported software-rendering fallback or hardware-acceleration toggle — the MSIX build accepts no launch flags and honors no electron-flags.conf.
2. Updater: don't pass PreserveApplicationData when removing non-dev-mode packages; terminate app processes and CoworkVMService before the package swap instead of deferring registration under a live instance; reconcile the windows-store self-identification with the actual sideloaded signature so the Repair path can work.

Current workarounds on this machine: HKLM\SOFTWARE\Policies\Claude → disableAutoUpdates=1 (stopped the corruption loop), avoiding the in-app browser pane entirely (sessions are told to use the Chrome extension instead), and re-registering the package manifest instead of reinstalling.

Additional data point — same crash on a different integrated GPU family and a
newer app version, still reproducing after a full driver update, with crash
artifacts that the original report describes as absent.

Environment

• Claude Desktop 1.26832.0.0 (MSIX, Claude_pzs8sxrjxfjjc)
• Windows 11 10.0.26200.8875
• Intel Iris Xe Graphics — single GPU, no discrete GPU

11th Gen Intel(R) Core(TM) i7-1195G7 @ 2.90GHz

Name : Intel(R) Iris(R) Xe Graphics
DriverVersion : 32.0.101.7088
DriverDate : 17/06/2026 2:00:00

The original report is on Intel HD Graphics, so this is not limited to one
integrated GPU family.

Stale driver ruled out. The crash first occurred on driver 30.0.100.9864
(2021-08-20). I updated the graphics driver and all other system drivers, then
retested: the crash still reproduces on the current driver.

Trigger — narrower than "browser pane"

Reproducible on demand via the Claude Code preview pane. Note the preview
server is spawned by the app itself, not manually by me:

[Preview] Starting server with config { name: '<project>-static',
          command: 'python3', args: ['-m','http.server','8592','--directory','<dir>'] }
[Preview] Spawning process { pid: 18408 }
[Preview] Created session preview context

The app dies ~15s after the server starts. Issuing the same request to Claude
Code reproduces the crash reliably.

Crash artifacts DO exist here

The original report states no crash dump or log entry corresponds to this crash.
In my case both exist:

1. Crashpad dump written: Crashpad\reports\32239b47-...-d54de337dfc8.dmp,

35,419,952 bytes.

1. logs\main.log ends mid-session on an explicit GPU process crash:

13:21:15 [info]  [Preview] Spawning process { command: 'python3', port: 8592 }
13:21:19 [info]  [Preview] Server ready (HTTP responding)
13:21:20 [error] [Preview] navigatePreview failed { origin: 'http://localhost:8592', error: '' }
13:21:21 [info]  [process-memory] tree_rss_sum=1922MB electron(12)=1922MB
                 sys_free=17660MB/32470MB
13:21:25 [info]  [WarmLifecycle:preview] Warming up session
13:21:30 [info]  GPU process gone: { type: 'GPU', reason: 'crashed',
                 exitCode: 101457950, serviceName: 'GPU' }
[log ends here]

Notes that may help narrow the cause

• Memory exhaustion is ruled out: 1922MB in use, 17.6GB free of 32GB, per the

app's own instrumentation 9 seconds before the crash.

• navigatePreview failed with an empty error string ~10s before the GPU

process died. The server was confirmed HTTP-responsive at that point, so this
is not a connection failure. The empty error may be worth investigating on its
own — it suggests the navigation failure is swallowed rather than handled.

• Get-AppxPackage reports Status: Ok after the crash. I did not hit the

Modified, NeedsRemediation package corruption from the original report, so
that looks like a separate or version-specific failure mode.

• No MCP servers were involved — no mcp-server-*.log files exist at all.
• No Windows Application Error event was logged, consistent with Crashpad

handling the exception before WER sees it.

Severity: no usable workaround

Because the preview server is spawned by the app, avoiding the preview pane
manually does not prevent the crash, and opening the same URL in an external
browser does not help — the app dies regardless. On projects with a preview
server configured, Claude Desktop is unusable, and MSIX offers no reachable way
to disable GPU compositing as a mitigation. This makes the toggle requested in
the original report the difference between a workaround existing and not.

<html>
<body>
<!--StartFragment--><html><head></head><body><h1>Claude Desktop browser-pane crash — GitHub issue draft</h1>
<p><strong>Prepared:</strong> 2026-08-08</p>
<h2>Comment body</h2>
<p>Adding a corroborating data point that <strong>contradicts the Intel-integrated-GPU framing</strong> of this issue.
Same failure chain — browser-pane crash → package <code>Modified, NeedsRemediation</code> → Windows Repair fails →
reinstall-only recovery — but on a <strong>discrete NVIDIA RTX 5060 Ti</strong> and on a <strong>newer build (1.26832.0.0)</strong>
than the reports here. This matches #82967 (RTX 4070 Ti) and #83478 / #80444, which all show the same
GPU-process crash exit code <code>101457950</code> (<code>0x060C201E</code>). The GPU class is not the differentiator.</p>
<p><strong>Environment</strong></p>
<ul>
<li>Claude Desktop <strong>1.26832.0.0</strong> (MSIX; install location <code>Claude_1.26832.0.0_x64__pzs8sxrjxfjjc</code>, package family <code>pzs8sxrjxfjjc</code>), installed from the standalone Win32 installer</li>
<li>Windows 11 Pro, build 26100</li>
<li>CPU: Ryzen 7 4700LE (8c/16t), 16 GB RAM, ~91% free SSD</li>
<li>GPU: NVIDIA GeForce RTX 5060 Ti (discrete, sole display controller), driver 32.0.15.9649 (2026-05-04)</li>
</ul>
<p><strong>Symptom / trigger</strong></p>
<ul>
<li>Crash occurs the instant the in-app Browser pane opens to render a site.</li>
<li><strong>Not connector-specific</strong>: the Webflow connector was disconnected and the app still crashed on the next browser-pane open. (Webflow previews render through the same pane, which is why it originally looked connector-related.)</li>
<li><strong>Same build "works then crashes"</strong>: the app ran fine overnight, then crashed on the first browser-pane render in the morning. A reinstall installed the <em>same</em> build (1.26832.0.0) and it crashed again the same day — so this is not a bad-install or version-regression artifact; it points at a page-content / render-path trigger.</li>
</ul>
<p><strong>Confirmed on-demand reproduction (2026-08-08)</strong>
Opening a site in the in-app Browser pane crashed the app instantly and left the package corrupted. Captured live immediately afterward:</p>
<pre><code>Name : Claude
Version : 1.26832.0.0
Status : Modified, NeedsRemediation
InstallLocation : C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc
</code></pre>
<p>This is a clean "open pane → instant crash → NeedsRemediation" repro on the current build, not a stale/one-off corruption.</p>
<p><strong>Corruption + recovery</strong></p>
<ul>
<li>Multiple independent browser-pane crashes across the day (morning, ~5:36 PM, and the confirmed reproduction above), each flipping the package to <code>Modified, NeedsRemediation</code>.</li>
<li>Windows Settings → Repair did nothing — <strong>even with all Claude processes force-killed first</strong>.</li>
<li>The only thing that restored launchability: <code>Remove-AppxPackage</code> + deleting <code>%LOCALAPPDATA%\Claude</code>, <code>%APPDATA%\Claude</code>, <code>%LOCALAPPDATA%\AnthropicClaude</code>, <code>SquirrelTemp</code> + reboot + fresh install.</li>
</ul>
<p><strong>Diagnostics gap (notable — makes this hard to self-triage)</strong></p>
<ul>
<li><strong>No crash artifacts for <code>claude.exe</code></strong>: no AppCrash / Event ID 1000, no faulting module, no Crashpad dump under <code>%APPDATA%\Claude</code> or <code>%LOCALAPPDATA%\Claude</code>. The process exits without Windows classifying it as a crash — consistent with an Electron GPU/child-process death triggering an orderly main-process shutdown.</li>
<li>System log has <strong>zero</strong> Resource-Exhaustion-Detector events; system memory never ran out. (A single <code>RADAR_PRE_LEAK_64</code> memory-growth heuristic fired for claude.exe at 1:48 AM, but that is a warning, not the crash.)</li>
<li>The only WER artifacts are <strong>AppHangB1 on the installer stub</strong> (<code>Claude Setup*.exe</code>) — i.e., the <em>reinstall</em> hanging, not the app crashing. Minidumps for those exist and can be shared on request.</li>
<li>The Claude-for-Chrome extension bridge (<code>chrome-native-host.log</code>, named pipe <code>claude-mcp-browser-bridge</code>) is completely clean throughout — the failure is isolated to the <strong>in-app</strong> pane, not the extension.</li>
</ul>
<p><strong>What would help (echoing #83028 / #82967)</strong></p>
<ol>
<li>Contain GPU/renderer crashes to the webview instead of taking down the host process and corrupting the MSIX registration (graceful crash frame / reload, not a fatal exit).</li>
<li>Expose a <strong>"Disable hardware acceleration"</strong> toggle. MSIX AppContainer blocks passing <code>--disable-gpu*</code> / <code>--disable-gpu-compositing</code> flags to the executable, so an in-app setting or config file is the only viable lever for affected users.</li>
</ol>
<p>Happy to attach the installer-hang minidumps or run a diagnostic build.</p>
<hr>
<h2>Related issues (confirmed via search, 2026-08-08)</h2>

Issue | What it reports | GPU | Status
-- | -- | -- | --
#83028 | Browser-pane crash → NeedsRemediation → Repair fails → reinstall; framed Intel-integrated-only | Intel HD (integrated) | Open, no maintainer reply
#82967 | In-app Browser tool crashes GPU process, corrupts MSIX; exit 0x060C201E; trigger tied to preview-screenshot capture | RTX 4070 Ti (discrete) | Open, no maintainer reply
#83478 | "GPU process gone… exitCode 101457950" during live browser preview kills host; WebGL: INVALID_ENUM | — | Open, no maintainer reply
#80444 | Fatal GPU-process crash 0x060C201E via in-app Browser tab; MSIX unlaunchable (appxState=2) until Repair | — | Open
#81664 | Repeated browser-pane screenshot crashes, then relaunch failure | — | Open
#81159 | GPU-process crash 101457950 corrupts MSIX on in-page browser action, Win11 | — | Open

<p><strong>Note:</strong> #83403 (which prior notes labeled as the "Cloudflare Turnstile" crash) actually resolves to a
<em>separate</em> bug about crashing near the 5-hour usage limit. A Turnstile-specific browser-pane crash may
exist under a different number — verify before citing it.</p></body></html><!--EndFragment-->
</body>
</html># Claude Desktop browser-pane crash — GitHub issue draft

Prepared: 2026-08-08

Where to post this

Recommended: add as a comment on [#83028](https://github.com/anthropics/claude-code/issues/83028).
That issue is framed as Intel-integrated-GPU-specific, and your machine (discrete RTX 5060 Ti)
is a clean counterexample that breaks that framing — the most useful thing you can contribute is the
data point that the GPU class is not the differentiator.

It is equally valid as a comment on [#82967](https://github.com/anthropics/claude-code/issues/82967)
(already a discrete NVIDIA RTX 4070 Ti report, same exit code 0x060C201E) or
[#83478](https://github.com/anthropics/claude-code/issues/83478) (GPU process gone, exit 101457950).
All three are the same root cause. File a new issue only if a maintainer asks you to split it out.

The comment below is written to work as-is on #83028. Swap the first paragraph's cross-links if you post elsewhere.

---

Comment body (copy-paste)

Adding a corroborating data point that contradicts the Intel-integrated-GPU framing of this issue.
Same failure chain — browser-pane crash → package Modified, NeedsRemediation → Windows Repair fails →
reinstall-only recovery — but on a discrete NVIDIA RTX 5060 Ti and on a newer build (1.26832.0.0)
than the reports here. This matches #82967 (RTX 4070 Ti) and #83478 / #80444, which all show the same
GPU-process crash exit code 101457950 (0x060C201E). The GPU class is not the differentiator.

Environment

• Claude Desktop 1.26832.0.0 (MSIX; install location Claude_1.26832.0.0_x64__pzs8sxrjxfjjc, package family pzs8sxrjxfjjc), installed from the standalone Win32 installer
• Windows 11 Pro, build 26100
• CPU: Ryzen 7 4700LE (8c/16t), 16 GB RAM, ~91% free SSD
• GPU: NVIDIA GeForce RTX 5060 Ti (discrete, sole display controller), driver 32.0.15.9649 (2026-05-04)

Symptom / trigger

• Crash occurs the instant the in-app Browser pane opens to render a site.
• Not connector-specific: the Webflow connector was disconnected and the app still crashed on the next browser-pane open. (Webflow previews render through the same pane, which is why it originally looked connector-related.)
• Same build "works then crashes": the app ran fine overnight, then crashed on the first browser-pane render in the morning. A reinstall installed the same build (1.26832.0.0) and it crashed again the same day — so this is not a bad-install or version-regression artifact; it points at a page-content / render-path trigger.

Confirmed on-demand reproduction (2026-08-08)
Opening a site in the in-app Browser pane crashed the app instantly and left the package corrupted. Captured live immediately afterward:

Name            : Claude
Version         : 1.26832.0.0
Status          : Modified, NeedsRemediation
InstallLocation : C:\Program Files\WindowsApps\Claude_1.26832.0.0_x64__pzs8sxrjxfjjc

This is a clean "open pane → instant crash → NeedsRemediation" repro on the current build, not a stale/one-off corruption.

Corruption + recovery

• Multiple independent browser-pane crashes across the day (morning, ~5:36 PM, and the confirmed reproduction above), each flipping the package to Modified, NeedsRemediation.
• Windows Settings → Repair did nothing — even with all Claude processes force-killed first.
• The only thing that restored launchability: Remove-AppxPackage + deleting %LOCALAPPDATA%\Claude, %APPDATA%\Claude, %LOCALAPPDATA%\AnthropicClaude, SquirrelTemp + reboot + fresh install.

Diagnostics gap (notable — makes this hard to self-triage)

• No crash artifacts for claude.exe: no AppCrash / Event ID 1000, no faulting module, no Crashpad dump under %APPDATA%\Claude or %LOCALAPPDATA%\Claude. The process exits without Windows classifying it as a crash — consistent with an Electron GPU/child-process death triggering an orderly main-process shutdown.
• System log has zero Resource-Exhaustion-Detector events; system memory never ran out. (A single RADAR_PRE_LEAK_64 memory-growth heuristic fired for claude.exe at 1:48 AM, but that is a warning, not the crash.)
• The only WER artifacts are AppHangB1 on the installer stub (Claude Setup*.exe) — i.e., the reinstall hanging, not the app crashing. Minidumps for those exist and can be shared on request.
• The Claude-for-Chrome extension bridge (chrome-native-host.log, named pipe claude-mcp-browser-bridge) is completely clean throughout — the failure is isolated to the in-app pane, not the extension.

What would help (echoing #83028 / #82967)

1. Contain GPU/renderer crashes to the webview instead of taking down the host process and corrupting the MSIX registration (graceful crash frame / reload, not a fatal exit).
2. Expose a "Disable hardware acceleration" toggle. MSIX AppContainer blocks passing --disable-gpu* / --disable-gpu-compositing flags to the executable, so an in-app setting or config file is the only viable lever for affected users.

Happy to attach the installer-hang minidumps or run a diagnostic build.

---

Related issues (confirmed via search, 2026-08-08)

| Issue | What it reports | GPU | Status |
|---|---|---|---|
| [#83028](https://github.com/anthropics/claude-code/issues/83028) | Browser-pane crash → NeedsRemediation → Repair fails → reinstall; framed Intel-integrated-only | Intel HD (integrated) | Open, no maintainer reply |
| [#82967](https://github.com/anthropics/claude-code/issues/82967) | In-app Browser tool crashes GPU process, corrupts MSIX; exit 0x060C201E; trigger tied to preview-screenshot capture | RTX 4070 Ti (discrete) | Open, no maintainer reply |
| [#83478](https://github.com/anthropics/claude-code/issues/83478) | "GPU process gone… exitCode 101457950" during live browser preview kills host; WebGL: INVALID_ENUM | — | Open, no maintainer reply |
| [#80444](https://github.com/anthropics/claude-code/issues/80444) | Fatal GPU-process crash 0x060C201E via in-app Browser tab; MSIX unlaunchable (appxState=2) until Repair | — | Open |
| [#81664](https://github.com/anthropics/claude-code/issues/81664) | Repeated browser-pane screenshot crashes, then relaunch failure | — | Open |
| [#81159](https://github.com/anthropics/claude-code/issues/81159) | GPU-process crash 101457950 corrupts MSIX on in-page browser action, Win11 | — | Open |

Note: #83403 (which prior notes labeled as the "Cloudflare Turnstile" crash) actually resolves to a
separate bug about crashing near the 5-hour usage limit. A Turnstile-specific browser-pane crash may
exist under a different number — verify before citing it.