In-app Browser pane crashes Desktop app's GPU process (exitCode 101457950), even with hardware acceleration disabled

Status Closed — duplicate

Reported on v2.1.219

Maintainer reply None cached

Activity 9 comments · opened Jul 28, 2026 · closed Aug 25, 2026

Bug report: In-app Browser pane reliably crashes the Desktop app's GPU process (exitCode 101457950), even with hardware acceleration disabled

Summary

On the Claude Desktop app (Windows), opening the in-app Browser pane used by Claude Code's browser preview tools (mcp__Claude_Browser__preview_start / navigate) reliably crashes the app's Chromium GPU process within ~1 second, which brings down the app (it auto-relaunches ~60s later, losing the browser pane and interrupting the running Claude Code session). It reproduces even with hardware acceleration disabled (software/WARP rendering, NVIDIA driver not loaded), so it is not a GPU-driver problem — it appears to be a bug in the browser-preview feature itself.

Environment

Claude Desktop app version: 1.24012.9.0 (MSIX / Windows Store install)
Claude Code (CCD) version: 2.1.219
OS: Windows 11, build 26200
GPU: NVIDIA RTX 4090, driver 32.0.16.1074 (2026-07-01) + AMD Radeon iGPU (dual-GPU)
Displays: dual monitor (Alienware AW2725DF OLED 2560×1440 + LG TV 1920×1080)
isHardwareAccelerationDisabled: true was set in claude_desktop_config.json (confirmed active: GPU process runs --use-angle=d3d11-warp-webgl, loads D3D10Warp.dll + Microsoft.Internal.WarpPal.dll, and zero nv* NVIDIA DLLs)

Steps to reproduce

In a Claude Code session inside the Desktop app, call the browser preview tool (preview_start with a URL), i.e. open the in-app Browser pane.
Within ~1 second, the app's GPU process crashes and the app restarts.

Reproduced 3/3 times in one day.

Evidence (from `%APPDATA%\Claude\logs\main.log`, 2026-07-27)

Each [Preview] Created browser preview is followed within 1 second by a GPU process crash with an identical exit code:

18:17:41  [Preview] Created browser preview
18:17:42  GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

18:19:58  [Preview] Created browser preview
18:20:01  GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

23:06:20  [Preview] Created browser preview { serverId: 'browser-preview-...' }
23:06:21  GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }
23:07:12  Starting app   ← auto-relaunch

Notes:

A non-browser preview in the same period ([Preview] Created Claude page preview at 18:16:40) did NOT crash — only the browser preview triggers it.
The 23:06 crash occurred while the app was confirmed to be rendering in software/WARP mode (hardware acceleration disabled), so the NVIDIA driver was not in the code path.
Earlier crashes on 18:17/18:20 produced the same exit code 101457950 (one earlier crash showed exitCode 34).

Impact

The in-app Browser pane is effectively unusable on this machine — every use crashes the app and interrupts the active Claude Code session.
Workaround in use: avoid the in-app Browser pane entirely; use an external browser connector / web search instead.

Suspected area

Browser-preview GPU/compositor initialization crashing the shared GPU process; reproduces independent of hardware acceleration setting, pointing at the feature rather than the GPU/driver.

View original on GitHub ↗

3 Comments

labolabo · 1 month ago

Confirming this issue with a controlled reproduction on Windows 10 Pro 19045, Claude Desktop 1.24012.9.0 (MSIX).

After recovering from a crash that occurred right after opening the in-app browser, I deliberately repeated the trigger while tailing main.log:

Crash #1 (organic):

21:28:21 [PreviewContext] Opened preview user tab
21:28:29 electron process count 20→21, RSS +250MB (new renderer + GPU context)
21:28:33 GPU process gone: { reason: 'crashed' }   ← 12 seconds after open

Crash #2 (deliberate repro, ~15 min after recovery):

21:43:40 [Preview] Created session preview context / Created browser preview
         (asked the assistant to open a page — cloudflare.com — in the in-app browser)
21:43:46 GPU process gone: { reason: 'crashed' }   ← 6 seconds after open

The app had been running crash-free for ~28.5 hours before crash #1; both crashes landed within 6–12 seconds of opening the browser pane. n=2, 2-for-2.

Aggravating factor on MSIX: each GPU crash also flips the package to Modified, NeedsRemediation, after which the app cannot launch at all ("There's a problem with Claude…" dialog) — turning a rendering bug into a full app brick. Recovery details (incl. the CoworkVMService lock that blocks repair, and why the Settings "Repair" button doesn't help): https://github.com/anthropics/claude-code/issues/81756#issuecomment-5101534076

Workaround for now: avoid opening the in-app browser pane entirely.

frostyjulian · 1 month ago

Can confirm this on a different, single-GPU setup — same crash signature, different hardware, so this doesn't look GPU/driver-specific:

Claude Desktop version: 1.24012.9.0 (same as OP)
OS: Windows 11 Pro, build 26200
GPU: NVIDIA GeForce RTX 4070 Ti SUPER, driver 32.0.15.9649 (current, 2026-05-05)
Trigger: opening the browser pane (preview_start + navigate) on a page with heavy WebGL/Three.js rendering (a 3D hero scene). From main.log:

GPU process gone: {
type: 'GPU',
reason: 'crashed',
serviceName: 'GPU'
}
immediately preceded by repeated WebGL errors in the renderer log (INVALID_ENUM: getInternalformatParameter, CONTEXT_LOST_WEBGL: loseContext: context lost).

One difference from OP's report: in my case the app didn't just auto-restart after ~60s — it fully froze and had to be force-closed via Task Manager, and on one occasion required a repair/reinstall before it would start normally again. So the severity/recovery behavior may vary by machine, but the underlying GPU-process crash on browser-pane use looks like the same root cause.

Also note: Windows Application Error log and Crashpad reports had no entry for the freeze — it's a hard hang of the whole process tree rather than a clean, dump-producing crash, which likely makes this harder to catch via normal crash reporting.

labolabo · 27 days ago

Follow-up from https://github.com/anthropics/claude-code/issues/81840#issuecomment-5117994605 — new data point: the GPU-crash → Modified, NeedsRemediation brick can happen without the in-app browser at all.

5th brick on this machine, 2026-08-04 14:35:10 JST, app 1.24012.9.0, now on Windows 11 Pro 26200 (this box migrated Win10 → Win11 25H2 on Aug 3).

Since Aug 1 the Browser tools toggle (Settings → Claude Code) has been off on this machine, and main.log has zero PreviewContext / Created browser preview entries that day — so the browser pane path from my earlier repro is excluded this time.

What main.log shows in the ~2 seconds before the crash (internal claude.ai webview activity, not user-initiated browsing):

14:35:08 Navigation to https://claude.ai/api/challenge_redirect?to=...%2Fepitaxy%2Flocal_... failed with status code 403
14:35:08 Health check returned non-200 status: { status: 429 }
14:35:08 Turnstile iframe detected. Removing error overlay.
14:35:09 Blocked permission check (x8)
14:35:10 GPU process gone: { type: 'GPU', reason: 'crashed', serviceName: 'GPU' }

So the suspect this time is the app's internal claude.ai webview hitting a Cloudflare Turnstile challenge right before the GPU process died (correlation, not proven causation). Whatever the trigger, the damaging part is unchanged: a GPU-process crash immediately corrupts the MSIX state to Modified, NeedsRemediation, i.e. the brick chain is not specific to the browser pane.

Recovery this time additionally hit the orphaned Silo/Job launch failure (0x80070020, AppModel-Runtime EventID 215/208) after a successful MSIX repair — details posted in #53247.

Showing cached comments. Read the full discussion on GitHub ↗