[Windows desktop] GPU process crash while Browser pane loads a Cloudflare-challenged site; app hangs as zombie, relaunch impossible until MSIX Repair

Status Open

Reported on v2.1.246

Maintainer reply None cached

Activity 0 comments · opened Aug 28, 2026

Environment

| Item | Value |
|---|---|
| OS | Windows 11 Pro 10.0.26200 (x64) |
| App | Claude desktop (MSIX / Microsoft Store install) 1.37937.1.0, package Claude_pzs8sxrjxfjjc, exe C:\Program Files\WindowsApps\Claude_1.37937.1.0_x64__pzs8sxrjxfjjc\app\Claude.exe |
| Embedded Claude Code (CCD) | 2.1.246 |
| CLI running the session | 2.1.227 |
| Update state | 1.40609.0 staged by the in-app updater but deferred by MSIX ("Deployment aborts due to active service") — still on 1.37937.1.0 |
| Electron | node 24.18.1 (per Starting app log entry) |

Summary

Loading an external site that serves a Cloudflare challenge page (HTTP 403, "Just a moment..." / "Attention Required!") in the integrated Browser pane (mcp__Claude_Browser__* tools) crashed the Electron GPU process twice in one afternoon (identical exitCode: 101457950 = 0x060C201E, reason: 'crashed'). After logging the GPU process gone event, the main process never writes another log line: the app window dies but Claude.exe stays alive as a zombie, holding the MSIX package. Relaunching the app then fails silently until the user runs Settings > Apps > Claude > Advanced options > "Repair", which works only because the AppX repair operation force-terminates the zombie process/services and re-registers the package — not because any file was corrupted.

The trigger is not specific to browser_batch: crash #1 came from a browser_batch (navigate + wait + javascript), crash #2 from a single computer {action: wait} right after preview_start against the same site.

Timeline (2026-08-28, local = UTC-4)

| Local time | Event | Evidence |
|---|---|---|
| 17:04:59 | browser_batch → navigate https://www.rcos1.com/... (CF-protected, curl gives 403 challenge) + wait 6 + javascript_exec (XPath count). Tool call never returns a result. | session transcript JSONL, tool_use without matching tool_result |
| 17:05:04 | GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' } — last log line of the run; main process logs nothing more (silent until restart 83 min later). | main.log |
| ~18:00 | User runs "Repair" #1. AppX log: RepairPackageOperation + event 9641 "Deployment aborts due to active service Claude_pzs8sxrjxfjjc!Claude" → the zombie process was still holding the package. | AppXDeploymentServer/Operational |
| 18:28:43 | App starts again (Starting app, CCD 2.1.246). | main.log |
| 18:34:42–44 | New session: preview_start to the same rcos1.com URL succeeds; next call computer {action: wait, duration: 7} never returns. | session transcript JSONL |
| 18:34:44 | Second, identical GPU process gone (exitCode: 101457950) — again the last log line; silence until next start. | main.log |
| 18:40–18:42 | "Repair" #2: step fails with 0x80073D02 ("apps need to be closed") because Claude.exe is still running; repair terminates CoworkVMService/app, re-registers package; update to 1.40609.0.0 downloaded but deferred again. | AppXDeploymentServer/Operational |
| 18:41:39 | App starts normally. | main.log |

Key evidence

main.log (both crashes, byte-identical shape):

2026-08-28 17:05:04 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}
<-- no further lines until "Starting app" at 18:28:43 -->

2026-08-28 18:34:44 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}
<-- no further lines until "Starting app" at 18:41:38 -->

These are the only GPU process gone events in the whole log (which starts 2026-08-21).

Crash telemetry gap — the native crash pipeline saw nothing:

%APPDATA%\Claude\Crashpad\reports and attachments: empty
%LOCALAPPDATA%\CrashDumps: no Claude dumps
WER (Event IDs 1000/1001/1002, 30 days, 800 events): 0 hits for claude/anthropic/electron
WER ReportArchive/ReportQueue: empty

So this crash class is likely invisible in crash telemetry.

Failing tool calls (from the session transcript JSONL):

Crash #1 (2026-08-28T21:04:59.734Z UTC): browser_batch with [navigate rcos1.com, computer wait 6, javascript_exec]
Crash #2 (2026-08-28T22:34:44.634Z UTC): single computer {action: wait, duration: 7} after preview_start on rcos1.com
All 3 sites involved answer curl with 403 + Cloudflare challenge HTML (rcos1.com, gemlaser.com, oemsupplies.com); the batch immediately before crash #1 rendered "Attention Required! | Cloudflare" from oemsupplies.com successfully.
Across all project transcripts (~130 browser-tool calls, incl. a 69-call session on 08-26) these are the only two calls without a tool_result.

Root-cause hypothesis

Rendering the Cloudflare challenge page (or its immediate aftermath) in the Browser pane crashes the Chromium GPU process (0x060C201E, both times identical → deterministic-ish, not random OOM; system had ~18 GB free RAM and app tree was ~1.3 GB at the time).
Electron's default behavior would relaunch the GPU process, but the app's main process instead goes completely silent — it neither exits nor recovers (likely deadlocked in/after the child-process-gone path, or waiting on the dead compositor).
The zombie Claude.exe keeps the single-instance lock and the MSIX package "in use", so normal relaunch does nothing.
"Repair" fixes it as a side effect: RepairPackageOperation force-closes the package's processes/services (after first aborting with 9641 "active service") and re-registers the package. No corrupted file is involved — a plain taskkill /F /IM Claude.exe is an equivalent, much faster recovery.

Suggested fixes (app side)

Handle child-process-gone for type: 'GPU': relaunch the GPU process or app.relaunch()+app.exit() instead of hanging.
Watchdog: if the main process detects GPU-gone and no recompose within N seconds, self-terminate so the singleton lock is released.
Ship the pending update path: MSIX defers staged updates while the (zombie) service is "active" — the same zombie blocks both relaunch and update.
Wire these GPU-gone events into Crashpad/telemetry; today they produce zero crash reports.

Minimal repro (⚠️ kills the whole app — do not run casually)

Claude desktop (Windows, MSIX 1.37937.1.0) with a Claude Code session in any project.
Ask for a preview_start/navigate to a Cloudflare-protected site currently serving the JS-challenge interstitial (e.g. https://www.rcos1.com/Manufacturers/HP/Technology/Printers-and-CopierFaxMultifunction-Machines.aspx — verify with curl that it returns 403 "Just a moment...").
Follow with computer {action: wait, duration: 6-7} (alone or inside browser_batch).
Observe: tool call never returns; app window dies; main.log ends in GPU process gone; relaunch fails until the zombie Claude.exe is killed (or "Repair" is run).

Reproduced 2/2 on 2026-08-28. Full logs available on request: %LOCALAPPDATA%\Claude\Logs\main.log, AppXDeploymentServer/Operational export, session transcript JSONL.

---
Diagnosed with the help of Claude Code (evidence collected from local logs; no live re-repro was attempted).

View original on GitHub ↗