Claude Desktop (Windows 11 Home): opening a Browser tab crashes the app instantly; relaunch requires Apps Repair + killing leftover process (1.32352.1)

Additional finding, same machine: in-app /feedback is also unavailable — it reports:

/feedback has been disabled via the CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC environment variable

However, the variable's value in sessions spawned by the Desktop app is the string "0" (i.e. "not disabled" by the documented convention), and no durable config on the machine sets it at all — verified absent from ~/.claude/settings.json and settings.local.json, project settings, Windows User and Machine environment scopes, HKCU\Environment registry, bash and PowerShell profiles, %APPDATA%\Claude, and the MSIX package data folder (%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc).

This suggests two things:

1. The /feedback gate treats any non-empty value as "disabled", including "0".
2. The Desktop app itself injects CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=0 into its Claude Code sessions.

Net effect: users hit by this crash cannot report it through the in-app feedback button either, which is why this report comes via GitHub.

Confirming this is still present on 1.32885.1.0 (newer than the 1.32352.1 originally
reported here), on a near-identical environment. Second total failure within ~48 hours.

Environment

• Claude Desktop: 1.32885.1.0 (MSIX, Claude_1.32885.1.0_x64__pzs8sxrjxfjjc)
• OS: Windows 11 Home, Build 10.0.26200.9168 (25H2)
• System locale: de-DE
• GPU: Intel UHD Graphics 620 (integrated, no discrete GPU), driver 31.0.101.2135 (2025-03-06)
• RAM: 16 GB, ~6 GB free at time of crash
• Free space on C:: 27.5 GB

What happened
Triggered while Claude Code was searching for an STL file — i.e. the in-app Browser pane
was in use. The app died instantly. Afterwards the icon did nothing at all.

Unlike the first occurrence, this time neither Repair nor Reset recovered the app.
Only a full uninstall → reboot → reinstall worked.

Evidence from Windows Event Log (Application), all within 4 seconds:

19:04:29-19:04:32  Windows Error Reporting (1001)
  crashpad_log                    x10
  StoreAgentInstallFailure1       x4
  StoreAgentScanForUpdatesFailure0
  WindowsWcpOtherFailure3         x3
  LiveKernelEvent

Two things worth highlighting:

1. StoreAgentInstallFailure1 (x4) — this is the Windows repair machinery itself

failing. It explains why the documented workaround (Settings → Apps → Claude →
Advanced options → Repair) no longer worked on the second occurrence. The recovery
path this issue currently recommends is not reliable.

1. LiveKernelEvent — no dump was written to C:\Windows\LiveKernelReports, so this

is circumstantial, but it is consistent with a display-driver reset and reinforces the
GPU-process theory in this thread.

No Crashpad reports were retained in %APPDATA%\Claude\Crashpad\reports (empty after
reinstall), so no minidump is available.

Data loss
Reinstalling wipes %APPDATA%\Claude\claude-code-sessions\, which is what backs the local
session list in the sidebar. All local chats disappear from the UI. The transcripts
themselves survive in ~/.claude/projects/*.jsonl, but there is no supported way to
re-link them, so from the user's point of view the chats are gone — including, in my case,
the chat documenting the recovery from the first crash.

Suggestions, in order of usefulness to affected users:

1. A "Disable hardware acceleration" toggle in Settings (see #77857). This is the

single change that would let affected users keep working today.

1. Make the GPU-process crash non-fatal to the MSIX package state. The renderer dying

should not leave the package unlaunchable.

1. Store claude-code-sessions outside the MSIX app-data scope, or restore it from the

transcripts, so that Reset/Reinstall does not destroy the session list.

標題：桌面版 Claude App 在雙顯示卡（NVIDIA + AMD）筆電上開啟 Code 分頁後穩定 GPU process 崩潰

環境資訊：

作業系統：Windows 11

筆電型號：ASUS ROG Strix G713PV

顯示卡：AMD Radeon(TM) 610M（內顯）+ NVIDIA GeForce RTX 4060 Laptop GPU（獨顯）

Claude 桌面 App 安裝方式：MSIX（Microsoft Store 封裝版）

問題描述： 點開 Code 分頁、進行一般操作（開啟瀏覽器預覽、OAuth 驗證等，非高負載操作）約數十秒到一分鐘內，App 必定崩潰。Chat／Cowork 分頁本身未受影響。

Log 內容（main.log 最後幾行，崩潰當下）：

2026-08-24 12:20:18 [info] GPU process gone: {
type: 'GPU',
reason: 'crashed',
exitCode: 101457950,
serviceName: 'GPU'
}

已嘗試過的修復方式，皆無效：

透過「已安裝的應用程式 → 進階選項 → 修復」執行修復，共執行兩次，結果皆為修復成功但問題依舊

完全重新開機，並手動結束所有 Claude 相關行程後再開啟

於「設定 → 系統 → 顯示 → 圖形」中，將 Claude 手動指定為固定使用 NVIDIA GeForce RTX 4060（高效能模式），問題依舊發生，僅崩潰前存活時間略有延長

備註： 獨立安裝的 Claude Code CLI（透過 npm 安裝，路徑 AppData\Roaming\npm）完全穩定，不受此問題影響，僅桌面 App 的 Code 分頁（Electron GUI 層）會崩潰。

English version

Title: Claude Desktop App crashes with GPU process death when opening Code tab on hybrid-GPU (NVIDIA + AMD) laptop

Environment:

OS: Windows 11

Laptop: ASUS ROG Strix G713PV

GPUs: AMD Radeon(TM) 610M (integrated) + NVIDIA GeForce RTX 4060 Laptop GPU (discrete)

Install method: MSIX (Microsoft Store package)

Description: Opening the Code tab and performing normal, low-load actions (opening a browser preview, OAuth token lookup) reliably crashes the app within roughly 30–60 seconds. The Chat and Cowork tabs are unaffected.

Log excerpt (main.log, at time of crash):

2026-08-24 12:20:18 [info] GPU process gone: {
type: 'GPU',
reason: 'crashed',
exitCode: 101457950,
serviceName: 'GPU'
}

Steps already tried, none resolved the issue:

Repair via Settings → Installed apps → Advanced options → Repair, run twice, both reported success but the crash persisted

Full reboot plus force-killing all Claude-related processes before relaunch

Manually pinning Claude to the NVIDIA GeForce RTX 4060 (High performance) via Settings → System → Display → Graphics — crash still occurs, only slightly delayed

Note: The standalone Claude Code CLI (installed via npm at AppData\Roaming\npm) is completely stable and unaffected — this issue is isolated to the Desktop app's Code tab (Electron GUI layer).

I'm seeing the same crash. In my case it seems to happen specifically when a Claude Code session tries to open an external URL (browser tool / preview navigation) — the moment it tries to open the URL, the whole desktop app crashes instantly, and I have to go through Settings → Apps → Claude → Advanced options → Repair to get it working again. This has now happened repeatedly, every time a session attempts to open a URL.

• OS: Windows 11 Home, version 25H2, OS build 26200.9168
• Claude Desktop version: 1.34493.1.0
• Trigger: Claude Code session calling a browser/URL-open tool
• Symptom: app crashes instantly on URL open attempt; relaunch fails until Repair is run

Same as reported here — no workaround found besides repeating the Repair procedure each time. Would appreciate any update on root cause / fix timeline.

Confirming I'm seeing this too on Windows. Using the Browser pane (navigating to a URL) crashes the app. After the crash, it won't reopen normally - "Repair" starts and then fails with "couldn't be repaired." The crashed process doesn't show up in Task Manager until I attempt the repair, and the only way to recover is manually ending it there or not. Happens reliably, not intermittent - reproduced it again just now in a fresh session.

Adding a fully-documented reproduction with logs. Same bug, 3 crashes in one evening (2026-08-28), and I can explain the "repair hell" aftermath too.

Environment: Claude Desktop 1.37937.3 (MSIX, SignatureKind=Developer, installed via claude.ai download — NOT Microsoft Store), Windows 11 Home 10.0.26200, 32GB RAM.

Trigger (3/3 times): a Claude Code workflow subagent opened the in-app Browser pane. On the 3rd crash I personally clicked "approve" on the browser permission prompt and the app died immediately — a clean manual confirmation of the trigger.

Death signature in %LOCALAPPDATA%\Claude\Logs\main.log (identical twice):

21:41:15 [Preview] Created browser preview
21:42:19 [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'script' }
21:42:36 GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 }   <- 0x060C201E
--- main.log goes silent; whole app dead, no shutdown lines ---

22:10:48 [Preview] Created browser preview
22:12:37 [PreviewContext] Blocked subresource to private-resolving host { resourceType: 'xhr' }
22:12:38 GPU process gone: { exitCode: 101457950 }   <- 1 second after the block

Same exitCode as #83478 and #80444. Per-minute [process-memory] telemetry shows nothing abnormal before death (~1.6GB tree, 18GB system free). No WER records, no Application-log errors, and the Crashpad DB is completely empty (0 bytes) — so no dumps ever get captured for this crash.

Why recovery costs 30 minutes (the #84992 chain, fully logged): ~24s after each death, AppXDeploymentServer starts an auto-repair (RegisterByPackageFullName + ForceTargetApplicationShutdown). It fails with 0x80073D02 in a retry loop (resiliency files numbered up to _13) because orphaned claude.exe CLI runtimes and the bundled CoworkVMService (cowork-svc.exe, declared as a packaged windows.service in the AppxManifest) keep the package in use. User-visible result: "repairing…" for 12–30 min, then "couldn't repair, try again later".

Workarounds verified on my machine:

• Fast recovery: kill ALL claude.exe + cowork-svc.exe processes, then relaunch — repair passes immediately.
• Prevention: deny any browser-pane permission prompt / forbid agents from opening the Browser pane. WebSearch/WebFetch (server-side) are unaffected.

Full AppXDeploymentServer + main.log excerpts available on request. Also: the invalid label on this issue seems wrong — this is the desktop app crashing while hosting Claude Code sessions, and it kills running workflows with it.