Windows MSIX: opening the in-app Browser pane crashes the GPU process (exit 101457950); app then cannot relaunch until MSIX re-add (reinstall loop)

Confirming this on a third hardware configuration, and flagging a data-loss consequence I haven't
seen covered in the existing reports.

Same crash signature

Identical exit code, twice — 2026-07-24 and 2026-07-26. Both times triggered by using the in-app
browser; the second was on clicking the back arrow after navigating.

2026-07-26 06:59:33 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

The log terminates immediately after — no quit handlers ran. Preceding lines are routine oauth
token lookups only. Unlike #81275 I do not see [CDPTools] Compressed screenshot failed or
capturePreviewScreenshot failed right before the crash, though [WarmLifecycle:preview] and
[CoworkFilePreview] entries appear throughout the session, so the preview subsystem was active.
May help narrow which path in the capture pipeline is at fault.

Environment (adds a third GPU combination)

| | |
|---|---|
| Machine | MSI Crosshair 18 HX AI A2XWGKG |
| OS | Windows 11 Home 10.0.26200 |
| Package | MSIX Claude_pzs8sxrjxfjjc, Claude Code 2.1.219 |
| GPU 1 | NVIDIA GeForce RTX 5070 Laptop — driver 32.0.15.8183 |
| GPU 2 | Intel Arc iGPU (PCI\VEN_8086&DEV_7D67) — driver 32.0.101.6629 |

Consistent with #81275's finding that the backend doesn't matter — this is a different NVIDIA
generation (RTX 5070 vs 4070/3090 Ti) and an older Intel driver, same exit code.

The part I think is under-reported: the reinstall destroys the session index

Recovery requires a reinstall, and uninstalling the MSIX package deletes its container — including
LocalCache\Roaming\Claude\claude-code-sessions\, which holds every Claude Code session entry
(title, cwd, timestamps, ordering).

After reinstalling, the session list is empty apart from the new session, and it never rebuilds,
even though every transcript is still sitting in ~/.claude/projects/. I confirmed the app launched
repeatedly over two days without ever backfilling.

The conversations aren't lost — the index is. But the app gives no indication the transcripts are
still there, so it reads as total data loss. Rebuilding 176 sessions by hand took a full day.

This looks straightforward to fix: everything needed is already in the transcripts.

• cliSessionId = the transcript filename
• cwd = present on every message record
• title = custom-title / ai-title records inside the transcript
• createdAt / lastActivityAt = message timestamps

A rebuild-if-empty on launch would make this crash a nuisance instead of a data-loss event. Failing
that, storing claude-code-sessions/ outside the MSIX container would survive uninstall.

One caveat found while reconstructing: entries written with a UTF-8 BOM are silently ignored by the
app (JSON.parse rejects a leading BOM), with no error surfaced. Worth a tolerant parse.

Also worth knowing

Recovery destroys the evidence. The crash log lives inside the MSIX container, so the reinstall that
fixes the app also deletes the main.log showing why it crashed. I only have mine because I backed
up LocalCache\Roaming\Claude\ beforehand. That may be why several reports here lack logs — worth
mentioning in any triage response.

Separately: cleanupPeriodDays (default 30) had been silently deleting my older transcripts with no
warning. Not related to this crash, but it compounded the damage — some sessions were gone before I
started, and only an external backup recovered them.

Happy to attach the full 2.2 MB main.log, or retry with extra logging.

Attaching the full main.log from the 2026-07-26 crash, as offered above:

https://gist.github.com/5kknhbfp2r-eng/d708f7d4d8ed950c2ca3e1093046d1c9

13,923 lines, 2.0 MB, ending at the GPU process gone entry — the app died there and no quit
handlers ran.

Redacted: local username, account/org/client UUIDs, oauth cache keys and the device-bridge id are
replaced with placeholders. Nothing else was altered — line count is identical to the original and
all timestamps, log levels and message text are intact. No credentials appear in the file (checked
for tokens, JWTs, API keys and bearer headers before uploading).

Worth noting for triage: this log only exists because I backed up LocalCache\Roaming\Claude\
before reinstalling. The reinstall that recovers the app deletes the MSIX container along with the
logs, so anyone who follows the obvious recovery path loses the evidence. That may explain why
several reports of this crash have no log attached.

Fourth hardware configuration confirming, plus three additions: root-cause cross-references, a servicing-loop variant where Windows repair can NEVER succeed, and a verified fix on this machine.

Env: Claude Desktop 1.24012.9 MSIX, bundled Claude Code 2.1.219 (CCD sessions in heavy use), Windows 11 Home 10.0.26200, Intel i5-12450H / UHD iGPU only (no dGPU), 16 GB RAM. ~15 fatal crashes 26-28 Jul, all exit_code=101457950, never a crash dump or WER entry.

Root-cause cross-reference: this matches #80999 / #81341 — 0x060C201E is the exception ntdll raises via LdrAppxHandleIntegrityFailure when Code Integrity rejects a DLL loaded into an AppX/MSIX process (vk_swiftshader.dll is signed without page hashes and the MSIX ships no AppxMetadata\CodeIntegrity.cat; the GPU child runs with the MicrosoftSignedOnly mitigation). This issue and those two describe one and the same defect.

Trigger variant (broader than the Browser pane): we never deliberately opened the Browser pane. In 3/3 crashes captured with ELECTRON_LOG_FILE, the fatal moment is the Nth-window session spin-up — [MCP] AutoSyncConnectorsToSession: Syncing 209 enabled MCP tool(s)... 8 remote server(s) appears ~1 second before GPU process exited unexpectedly. Any SwiftShader-fallback moment under multi-window churn can fire it.

Why some machines cannot even repair (guaranteed reinstall loop): on this box every relaunch attempt fired RegisterByPackageFullName (CallingProcess=explorer.exe) plus RepairPackageOperation referencing the staged source at %TEMP%\Claude-*.msix — which the installer deletes after installing → 0x80070002 forever. 7+ forced reinstalls in 2 days. Keeping the staged .msix (or staging it outside %TEMP%) would let repair succeed and end the loop for everyone in the duplicate chain (#46390 → #46123 → #28304, #51143, #28900).

Separate migration defect, compounding: the legacy Squirrel install (%LOCALAPPDATA%\AnthropicClaude, app-0.14.10) was still present AND RUNNING in parallel with the MSIX — tonight the installer terminated 10 running legacy claude.exe processes and logged "Squirrel installation removed". Both builds share %APPDATA%\Claude (every main.log line written twice; constant Unable to move the cache: Access is denied).

Verified fix (this machine, tonight): switched to the non-MSIX build from the winget manifest (1.24012.1, https://downloads.claude.ai/releases/win32/x64/1.24012.1/Claude-0adcaed55041a881be363f2c4a4729f67a8b27d7.exe, SHA256 verified) and removed the MSIX package. The 6-window burst that previously killed the MSIX build every time now produces 0 crashes, 0 CodeIntegrity 3033 events, app stays up — consistent with the report in #81341.

For Anthropic triage: Sentry events already uploaded from this machine — 5f0e4b052fc747939812cbcca538b2d0, 296ef206f3184b54b51a2cbecc543d74 (tag grouped_fatal=gpu-process-unusable). Support conversation: 215475252170799. Full 8 MB Chromium internal log + AppXDeploymentServer event exports preserved and available.

Likely the same root cause as #81341, where I have just posted a measured breakdown: Chromium's Code Integrity Guard (MicrosoftSignedOnly = ON, AllowStoreSignedBinaries = OFF, measured live on the running GPU child) refuses the package's own Authenticode-signed app\vk_swiftshader.dll with 0xC0000428 (CodeIntegrity event 3033, RequestedPolicy 8 vs ValidatedPolicy 1) when Dawn probes for a SwiftShader fallback adapter. The GPU process exits 101457950 / 0x060C201E and the browser process then reaches IntentionallyCrashBrowserForUnusableGpuProcess().

Two points from that comment that may be useful here:

• Stock Chrome on the same machine takes the byte-identical refusal 275 times without crashing, so the block is routine and the fatal escalation is the actual defect.
• No Chromium or Electron bump fixes it. Chromium's 2022 preload workaround (51c97ad46b7b) was deliberately narrowed in March 2026 (97b3f5d7800fde085af53b1b7455b730c215a874), and Electron 42.7.0 already ships the narrowed Chromium 148.0.7778.280.

Full detail, including the ERROR_PACKAGES_IN_USE repair loop that produces the "reinstall the application" dialog: #81341.