### 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? Claude Desktop disappears without warning while working in the Code tab. Reproduced on <st

[BUG] Claude Desktop (Windows/MSIX): fatal GPU-process crash (exit 101457950 / 0x060C201E) on preview surfaces — --disable-gpu-compositing does NOT mitigate; package left Modified/NeedsRemediation

Status Open

Reported on v2.1.241

Maintainer reply None cached

Activity 2 comments · opened Aug 23, 2026

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?

<html>
<body>
Claude Desktop disappears without warning while working in the Code tab. Reproduced on two independent machines, including a brand-new laptop with a clean install performed the previous evening (2026-08-22 20:39). Crashpad captured the crash: the embedded Node.js utility process performs a deliberate abort.

The most reliable trigger observed so far: resuming a heavy Code session and starting a review with 3 parallel agents — the app dies within ~5 minutes. Light sessions run noticeably longer. (Caveat: Code is the only tab in regular use here, so I cannot confirm whether Chat alone is stable.)

After each crash:

<ul dir="ltr">
<li><code>Get-AppxPackage Claude</code> flips from <code>Ok</code> to <code>Modified, NeedsRemediation</code> without any deployment action by the user.</li>
<li>On next launch the app re-initializes (<code>first_launch_at</code> is reset) and the session index is emptied; transcripts under <code>~/.claude</code> survive.</li>
<li>No Application Error (Event ID 1000) is written to the Windows event log — consistent with Crashpad intercepting the exception before WER.</li>
</ul>

On machine A this cascaded into the known reinstall spiral: <code>0x80073CF9</code> with inner <code>0x80070020 ERROR_SHARING_VIOLATION</code> on <code>app\resources\cowork-svc.exe</code> (held by CoworkVMService, whose ACL also blocks <code>sc stop/delete</code> even elevated), <code>0x80073CFA (requires developer mode)</code>, and <code>0x80073D02</code>. Full logs available.

CoworkVMService is ruled out as the crash cause: on machine A a crash occurred while the service was <code>Stopped</code> + <code>Disabled</code> (verified before and after). System memory exhaustion is also ruled out for the latest crash (no Resource-Exhaustion-Detector events; 16 GB RAM).

<h2 dir="ltr">Crash evidence (machine B, 2026-08-23)</h2>

Two Crashpad reports written one second apart (two processes involved):

<ul dir="ltr">
<li><code>7b8a748a-15b3-4368-b5e2-4595133c8e3d</code> — 15:19:10 local (13:19:10 UTC)</li>
<li><code>9b76bbed-b37f-4f17-aabe-c9e53e4e33e2</code> — 15:19:11 local</li>
</ul>

Sentry session files were updated at crash time, so these reports may already be on your backend under those IDs.

Minidump analysis of <code>9b76bbed…</code> (no public symbols, so frames are <code>Claude.exe+offset</code>):

<ul dir="ltr">
<li>Crashed process command line: <code>"…\Claude_1.34493.1.0_x64__pzs8sxrjxfjjc\app\Claude.exe" --type=utility --utility-sub-type=node.mojom.NodeService --lang=es …</code></li>
<li>Crashpad annotations: <code>ptype=utility</code>, <code>process_type=utility</code>, <code>platform=win32</code>, <code>osarch=x86_64</code>, <code>pid=11064</code></li>
<li>Exception: <code>0x80000003 EXCEPTION_BREAKPOINT</code>, raised in <code>KERNELBASE.dll</code> (deliberate abort / fatal path), crashing thread 536; stack resolves into <code>Claude.exe</code> (statically linked Electron/Node)</li>
<li>Not a per-process OOM: only ~0.37 GB committed at crash time (~3.5 TB reserved, i.e. normal V8 cage reservations); 24 threads incl. <code>V8Worker</code>; trivial CPU time (3 s user)</li>
<li>No OOM/fatal message strings ("Reached heap limit", "FatalProcessOutOfMemory", …) present in the captured memory</li>
<li>Process start 14:44:44 local → ~34 min uptime, crash within ~5 min of resuming the heavy session</li>
<li><code>Roaming\Claude\git-worktrees.json</code> was written inside the crash window (agents/worktrees being set up)</li>
</ul>

<h3 dir="ltr">Sentry breadcrumb timeline (browser process — last seconds before the crash)</h3>

<code>sentry/scope_v3.json</code> (<code>event.process: browser</code>) holds 100 breadcrumbs ending at 13:19:09 UTC — one second before the Crashpad dumps (13:19:10/11 UTC):

<ul dir="ltr">
<li>13:18:49 / 13:18:59 / 13:19:09 — <code>powerMonitor.speed-limit-change</code> ×3 in 20 s (CPU speed-limit changes: machine throttling under load)</li>
<li>13:19:06 — <code>app.session-created</code>, <code>app.web-contents-created</code>, several <code>renderer.dom-ready</code> (new sessions/webcontents spinning up — the agent review starting)</li>
<li>13:19:06 — <code>POST https://api.anthropic.com/v1/oauth/{uuid}/authorize</code> → 200; <code>POST …/v1/oauth/token</code> → 200</li>
<li>13:19:07–09 — <code>url_hash_check</code> / <code>domain_info</code> (browser_extension) → 200</li>
<li>trail ends; both dumps written at 13:19:10–11</li>
</ul>

<code>sentry/session.json</code> was written at process start (12:44:41.7 UTC, matching <code>app_start_time</code> 12:44:41.597Z) and was never finalized — still <code>init: true</code>, <code>status: "ok"</code>, <code>errors: 0</code>, duration ≈ 0 — i.e. no graceful shutdown path ran, and no handled error preceded the abort. The second Crashpad report (<code>7b8a748a…</code>, written 1 s before <code>9b76bbed…</code>) is therefore most likely the browser process going down together with the Node utility.

Runtime (from Sentry contexts): Electron 42.9.2, Chromium 148.0.7778.280, Node 24.18.1, release <code>Claude@1.34493.1</code>, <code>build_type: windows-store</code>.

<h2 dir="ltr">Environment</h2>

</div>
</body>
</html>

</div>

<h2 dir="ltr">Steps to Reproduce</h2>

<ol dir="ltr">
<li>Clean install of Claude Desktop 1.34493.1.0 on Windows 11 (10.0.26200) — installer completes with no errors.</li>
<li>Sign in, work in the Code tab. Light sessions: no crash for a while.</li>
<li>Resume a heavier session; start a review using 3 parallel agents.</li>
<li>Within ~5 minutes the app window disappears (no dialog). Crashpad writes two <code>.dmp</code> reports; <code>Get-AppxPackage</code> now shows <code>Modified, NeedsRemediation</code>; next launch re-initializes the app.</li>
</ol>

Reproduced 5+ times across the two machines over two days (2026-08-22/23).
</body>
</html>

What Should Happen?

A Code-tab multi-agent review should not abort the Node utility process; and a child-process crash should not take down the whole app, wipe the session index, or leave the MSIX package flagged Modified, NeedsRemediation.

Error Messages/Logs

Steps to Reproduce

Clean install of Claude Desktop 1.34493.1.0 on Windows 11 (10.0.26200) — installer completes with no errors.
Sign in, work in the Code tab. Light sessions: no crash for a while.
Resume a heavier session; start a review using 3 parallel agents.
Within ~5 minutes the app window disappears (no dialog). Crashpad writes two .dmp reports; Get-AppxPackage now shows Modified, NeedsRemediation; next launch re-initializes the app.

Reproduced 5+ times across the two machines over two days (2026-08-22/23).