Windows Desktop: a single GPU-process crash kills the whole app (and the claude-code session); hardware-acceleration auto-disable is unreachable

What happens

On a machine with no usable GPU, using the in-app Claude Browser / preview pane reliably kills
Claude Desktop outright: Chromium's GPU process crashes, and ~1.5 seconds later the entire
Electron process tree exits — main, renderers, GPU, utilities, and the claude-code CLI child
processes. Any Claude Code session running in the app dies with it, which is why it first looked
like "Claude Code became unresponsive".

There is no crash dialog, no dump left on disk, and no Windows Application Error event. The app
simply disappears.

Environment

• Claude Desktop 1.34493.1, MSIX / Windows Store install, CCD 2.1.237, Electron node 24.18.1
• Windows 10 Pro 19045, accessed over RDP
• No usable GPU: Intel(R) HD Graphics P4600/P4700, driver 20.19.15.5063 (2018), plus several

Microsoft Remote Display Adapter entries

• Hardware acceleration: enabled (the default)

Timeline from an instrumented reproduction

2-second process sampling plus the app's own log:

| time | event |
|---|---|
| T-3min | preview pane opened, an ordinary page renders fine |
| T-20s | navigate to a new origin → [PreviewOriginPolicy] origin prompt: in-app card, Emitted tool permission request … for browser:open_site |
| T-1.5s | user answers "Always allow"; config written. App fully responsive (Responding=True, 14 processes) |
| T-0.5s | GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950 } ← last line the app ever writes |
| T+0.9s | whole process tree gone: 14 processes → 2 |
| T+0.9s | cowork-service.log: Persistent RPC: connection ended: failed to read length: EOF |

exitCode 101457950 = 0x060C201E, byte-identical across two separate occurrences a day apart,
so it looks deterministic rather than a random fault. No kernel TDR / display-driver reset event
accompanies it, so the GPU process died on its own.

The same crash appears earlier in the same log, also in the preview-pane path (preceded by
[Preview] capturePreviewScreenshotIfChanged failed: UnknownVizError), and there too the log just
stops until the next manual Starting app.

Two separate defects

1. A single GPU-process crash is fatal to the whole app. The app's own child-process-gone
handler doesn't quit — it logs, emits desktop_gpu_process_gone and returns — so the teardown is
happening below that. Losing the GPU process should degrade to software compositing, not take the
browser process and every child with it. Taking the user's claude-code session down as collateral
makes it much worse than a repaint glitch.

2. The built-in GPU recovery can never fire in this failure mode. From the shipped bundle, the
auto-disable path needs three GPU deaths:

• in-session: 3 deaths within a 5-minute window → disable hardware acceleration and show

"Graphics problems detected";

• across sessions: a GPU-crash streak marker file, written on quit, read at startup and only

honoured at >= 3 (otherwise "consumed startup marker below threshold").

Here the app dies at death #1, so the counter never reaches 3, and because the teardown isn't a
graceful quit the streak marker is never written either. The mitigation that exists for exactly this
situation is unreachable, and the user hits the same crash forever.

Collateral: cowork-svc.exe (Claude VM Service) survives the teardown as an orphan and blocks
reinstall until killed manually. It also logs failed to configure recovery actions … Access is
denied, so a crashed service stays down until reboot.

Expected behaviour

• If no usable GPU is detected at install/first launch — or the session is remote (RDP / Remote

Display Adapter) — default hardware acceleration to off, or at least ask the user. Don't ship
a default that is known-fatal on that hardware.

• Whatever the default, don't fail this way: a GPU-process crash should not terminate the app.

Suggested fixes

• Make GPU-process loss non-fatal: fall back to software compositing. At minimum log the teardown

reason and flush before exit — today the app leaves no artifact at all for the fatal half.

• Write the GPU-crash streak marker at GPU-death time, not on quit, so a hard teardown still

counts; and treat "previous session's last event was a GPU death" as sufficient to disable
acceleration on the next launch instead of requiring 3.

• Gate acceleration off by default for remote sessions / stale-driver blocklist matches.
• Produce a crash artifact for this path. Right now only the desktop_gpu_process_gone telemetry

event survives, so the app-death half is invisible.

Unrelated smaller bug found alongside

The preview pane refuses popups outright: window.open() returns null even from a real
user-gesture click, and no tab is created. Federated-login flows ("Continue with Google") therefore
do nothing at all, with no signal to the user or the model that the popup was suppressed. Either
host the popup in a pane tab or surface an explicit error.

Workaround

Help → Troubleshooting → Disable Hardware Acceleration, then restart (or
"isHardwareAccelerationDisabled": true in %APPDATA%\Claude\config.json).