›_ Claude Code Issues
Claude Code Issues / #89997

[BUG] browser pane causing GPU crash

Status Open
Reported on v2.1.246
Maintainer reply None cached
Workaround ✓ Mentioned in description ↑
Activity 0 comments · opened Aug 27, 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?

Desktop app (Windows): GPU process killed seconds after opening the Browser preview pane — regression in 1.37937.x

Summary

Since updating to 1.37937.x, the Claude desktop app on Windows repeatedly loses its GPU
process — GPU process gone ... reason: 'crashed' — which takes the window down. The app
has to be relaunched. Seven occurrences in one evening.

Five of the seven deaths land 2–6 seconds after the in-app Browser preview pane opens
([Preview] Created session preview context / Created browser preview).

The same exit code appears every single time: 101457950 (0x060C201E).

No crashpad dump is written for any of them (%APPDATA%\Claude\Crashpad\reports\ stays
empty), which suggests the process is being terminated rather than faulting.

This did not happen on 1.34493.x. The same preview pane was used on Aug 20, 21, 22 and 25
with zero GPU deaths, and the app stayed up for days per launch.

Steps to reproduce

  1. Windows 11, desktop app 1.37937.3 (MSIX install)
  2. Open a local session
  3. Open the Browser preview pane in that session
  4. Within ~2–6 seconds the GPU process dies and the app window goes away

Reproduced 5 times out of 8 preview-pane opens.

Timeline (from %LOCALAPPDATA%\Claude\Logs\main.log)

Preview opened → GPU process gone:

| Preview pane opened | GPU process gone | Gap |
|---|---|---|
| 2026-08-26 20:41:03 | 2026-08-26 20:41:05 | 2s |
| 2026-08-26 20:47:14 | 2026-08-26 20:47:17 | 3s |
| 2026-08-26 20:55:14 | 2026-08-26 20:55:20 | 6s |
| 2026-08-27 00:01:33 | 2026-08-27 00:01:35 | 2s |
| 2026-08-27 00:04:07 | 2026-08-27 00:04:09 | 2s |

Two further GPU deaths had no preview open nearby: 2026-08-26 19:53:06 and
2026-08-26 23:56:24.

Three preview opens did not produce a crash: 18:00:13, 21:58:19, 23:11:38.

So the correlation is strong but not absolute — the trigger may depend on what the preview
is pointed at, rather than on opening the pane alone.

Resulting relaunch cycle — five app starts in fifty minutes:

20:15:19  Starting app   appVersion 1.37937.1
20:42:48  Starting app   appVersion 1.37937.1
20:54:28  Starting app   appVersion 1.37937.3   (updater: 1.37937.1 -> 1.37937.3)
21:01:57  Starting app   appVersion 1.37937.3
21:05:33  Starting app   appVersion 1.37937.3

Log excerpt

Identical in all seven instances:

2026-08-27 00:04:07 [info] [Preview] Created session preview context {
  previewId: 'preview-local_f0c7bf00-ad4a-4ffb-bf70-3a42d4fde9ba',
  totalContexts: 1
}
2026-08-27 00:04:07 [info] [Preview] Created browser preview { serverId: 'browser-preview-1787803447854-0' }
2026-08-27 00:04:09 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

What has been ruled out

Hardware acceleration / graphics driver. Disabling hardware acceleration
(Help → Troubleshooting → Disable Hardware Acceleration) does not fix it. Verified the
setting applied — the GPU process came up with:

--use-gl=angle
--use-angle=d3d11-warp-webgl

That is Microsoft's WARP software rasterizer, with the NVIDIA driver bypassed entirely. The
GPU process still died, with the identical exit code 101457950. Crashes at 00:01:35 and
00:04:09 both occurred in this state.

Display driver instability. No nvlddmkm / TDR / "display driver stopped responding"
events anywhere in the Windows System log.

Broken installation. Get-AppxPackage -Name Claude reports Status: Ok throughout.
(Windows Settings → Advanced options → Repair appears to recover the app, but only because
it re-registers the MSIX package and clears leftover processes — nothing about the install
is actually damaged.)

A stale or downlevel build. Crashes occurred on both 1.37937.1 and 1.37937.3, including
immediately after the auto-update to .3.

Related but probably separate

One Application Hang / MoAppHang at 2026-08-26 21:02:55 — Windows force-closed
claude.exe 1.37937.3.0 ("stopped interacting with Windows and was closed"). Only one such
event in 14 days, so likely a different failure from the GPU deaths.

Service Control Manager 7034 ("The Claude service terminated unexpectedly",
app\resources\cowork-svc.exe) fires around each app restart. This looks like a symptom of
the app going down rather than a cause.

Note on the automatic GPU-crash recovery

The app's built-in recovery — auto-disable hardware acceleration after repeated GPU crashes
— never triggered, because it requires 3+ crashes within a 5-minute window and the
crashes here were 48, 6, 8 and 5 minutes apart. Given that disabling acceleration turns out
not to help in this case, that recovery path may not be the right mitigation for this bug
anyway.

Environment

  • Claude desktop app 1.37937.3 (also reproduced on 1.37937.1); MSIX install,

C:\Program Files\WindowsApps\Claude_1.37937.3.0_x64__pzs8sxrjxfjjc

  • Last known-good: 1.34493.1
  • Windows 11 Home, build 26200 (10.0.26200), x64
  • Node 24.18.1 (per app startup log)
  • NVIDIA GeForce RTX 4070, driver 32.0.15.9186
  • 32 GB RAM; ~12–21 GB free at time of crashes (not memory-starved)
  • App process tree at crash: 17–24 Electron processes, ~2.7–4.1 GB RSS total

Workaround

Avoid opening the in-app Browser preview pane.

What Should Happen?

opening the browser pane shouldn't crash everything

Error Messages/Logs

Steps to Reproduce

Desktop app (Windows): GPU process killed seconds after opening the Browser preview pane — regression in 1.37937.x

Summary

Since updating to 1.37937.x, the Claude desktop app on Windows repeatedly loses its GPU
process — GPU process gone ... reason: 'crashed' — which takes the window down. The app
has to be relaunched. Seven occurrences in one evening.

Five of the seven deaths land 2–6 seconds after the in-app Browser preview pane opens
([Preview] Created session preview context / Created browser preview).

The same exit code appears every single time: 101457950 (0x060C201E).

No crashpad dump is written for any of them (%APPDATA%\Claude\Crashpad\reports\ stays
empty), which suggests the process is being terminated rather than faulting.

This did not happen on 1.34493.x. The same preview pane was used on Aug 20, 21, 22 and 25
with zero GPU deaths, and the app stayed up for days per launch.

Steps to reproduce

  1. Windows 11, desktop app 1.37937.3 (MSIX install)
  2. Open a local session
  3. Open the Browser preview pane in that session
  4. Within ~2–6 seconds the GPU process dies and the app window goes away

Reproduced 5 times out of 8 preview-pane opens.

Timeline (from %LOCALAPPDATA%\Claude\Logs\main.log)

Preview opened → GPU process gone:

| Preview pane opened | GPU process gone | Gap |
|---|---|---|
| 2026-08-26 20:41:03 | 2026-08-26 20:41:05 | 2s |
| 2026-08-26 20:47:14 | 2026-08-26 20:47:17 | 3s |
| 2026-08-26 20:55:14 | 2026-08-26 20:55:20 | 6s |
| 2026-08-27 00:01:33 | 2026-08-27 00:01:35 | 2s |
| 2026-08-27 00:04:07 | 2026-08-27 00:04:09 | 2s |

Two further GPU deaths had no preview open nearby: 2026-08-26 19:53:06 and
2026-08-26 23:56:24.

Three preview opens did not produce a crash: 18:00:13, 21:58:19, 23:11:38.

So the correlation is strong but not absolute — the trigger may depend on what the preview
is pointed at, rather than on opening the pane alone.

Resulting relaunch cycle — five app starts in fifty minutes:

20:15:19  Starting app   appVersion 1.37937.1
20:42:48  Starting app   appVersion 1.37937.1
20:54:28  Starting app   appVersion 1.37937.3   (updater: 1.37937.1 -> 1.37937.3)
21:01:57  Starting app   appVersion 1.37937.3
21:05:33  Starting app   appVersion 1.37937.3

Log excerpt

Identical in all seven instances:

2026-08-27 00:04:07 [info] [Preview] Created session preview context {
  previewId: 'preview-local_f0c7bf00-ad4a-4ffb-bf70-3a42d4fde9ba',
  totalContexts: 1
}
2026-08-27 00:04:07 [info] [Preview] Created browser preview { serverId: 'browser-preview-1787803447854-0' }
2026-08-27 00:04:09 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

What has been ruled out

Hardware acceleration / graphics driver. Disabling hardware acceleration
(Help → Troubleshooting → Disable Hardware Acceleration) does not fix it. Verified the
setting applied — the GPU process came up with:

--use-gl=angle
--use-angle=d3d11-warp-webgl

That is Microsoft's WARP software rasterizer, with the NVIDIA driver bypassed entirely. The
GPU process still died, with the identical exit code 101457950. Crashes at 00:01:35 and
00:04:09 both occurred in this state.

Display driver instability. No nvlddmkm / TDR / "display driver stopped responding"
events anywhere in the Windows System log.

Broken installation. Get-AppxPackage -Name Claude reports Status: Ok throughout.
(Windows Settings → Advanced options → Repair appears to recover the app, but only because
it re-registers the MSIX package and clears leftover processes — nothing about the install
is actually damaged.)

A stale or downlevel build. Crashes occurred on both 1.37937.1 and 1.37937.3, including
immediately after the auto-update to .3.

Related but probably separate

One Application Hang / MoAppHang at 2026-08-26 21:02:55 — Windows force-closed
claude.exe 1.37937.3.0 ("stopped interacting with Windows and was closed"). Only one such
event in 14 days, so likely a different failure from the GPU deaths.

Service Control Manager 7034 ("The Claude service terminated unexpectedly",
app\resources\cowork-svc.exe) fires around each app restart. This looks like a symptom of
the app going down rather than a cause.

Note on the automatic GPU-crash recovery

The app's built-in recovery — auto-disable hardware acceleration after repeated GPU crashes
— never triggered, because it requires 3+ crashes within a 5-minute window and the
crashes here were 48, 6, 8 and 5 minutes apart. Given that disabling acceleration turns out
not to help in this case, that recovery path may not be the right mitigation for this bug
anyway.

Environment

  • Claude desktop app 1.37937.3 (also reproduced on 1.37937.1); MSIX install,

C:\Program Files\WindowsApps\Claude_1.37937.3.0_x64__pzs8sxrjxfjjc

  • Last known-good: 1.34493.1
  • Windows 11 Home, build 26200 (10.0.26200), x64
  • Node 24.18.1 (per app startup log)
  • NVIDIA GeForce RTX 4070, driver 32.0.15.9186
  • 32 GB RAM; ~12–21 GB free at time of crashes (not memory-starved)
  • App process tree at crash: 17–24 Electron processes, ~2.7–4.1 GB RSS total

Workaround

Avoid opening the in-app Browser preview pane.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

[CCD] Wrote SDK version file: 2.1.246

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Same class of failure, ranked by community engagement — this issue is one of many, so it may not appear in the visible list: Windows & WSL problems, Crashes, hangs & freezes

Browse all Claude Code issue topics →