You are in the middle of something when Claude Desktop suddenly freezes and every Claude Code session you had open dies at once. You force-quit it and restart — and sometimes the app itself refuses to start. When that happens, the last line in the log is almost always the same one.

GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }

This article sets out what that exitCode 101457950 (= 0x060C201E) means, why sessions with nothing to do with each other go down together, and which remedies are real and which are not.

⚠️ Confidence labels used in this article: ✅ Confirmed = recorded in a public issue, or measured on the author's machine / 🟡 Reported = multiple reports but no official confirmation / 🔴 Unverified = cannot be stated as fact. Anthropic has published neither an explanation of the cause nor a fix announcement for this symptom (as far as could be checked on August 15, 2026).

GPU PROCESS GONE · 0x060C201E

One tab takes every session down with it

— because the GPU process is a shared resource, and there is only one of it per app

What happens
The app goes unresponsive. It does not disappear, it freezes — and stays frozen until you force-quit it
Blast radius
Every session you had open. Unrelated projects stop at the same moment
Can it be isolated?
No. It follows from how Electron/Chromium is built, and no setting changes it
How to recover
Force-quit, then restart. If it no longer starts, use Repair

1. The verdict — Claude Code is not what failed; the shell around it is

Start by separating the two. It feels like "Claude Code crashed", but Claude Code (the CLI) is not what crashed. What crashed is the GPU process of the desktop app (Electron) that hosts it.

✅ Confirmed: the test is easy — look at the end of %APPDATA%\Claude\logs\main.log. If the line immediately before the restart is GPU process gone, this is your problem. The log stops there, and the next line is Starting app.

The important part is that what you lose is a process, not your data. Conversation history and transcripts are written to disk, so reopening the session after a restart picks up where you left off. Work that was mid-flight is a different matter, and §6 comes back to it.

2. The symptom — it does not crash, it hangs

The nastiest thing about this bug is that the app does not vanish; it sits there unresponsive. No crash dialog, no automatic restart. It simply stays frozen until you notice and force-quit it.

Across three occurrences observed on the author's machine (Windows 11 / RTX 2080 Ti / 32GB RAM) on August 14, 2026, the longest gap between the GPU process dying and the force-quit was about 30 minutes. For that whole stretch, all eight open sessions stayed stopped.

Three ways to tell

  • Everything, not just one — if a single session stopped, look elsewhere. If several sessions restarted within the same minute, the app itself went down
  • The log cuts off mid-stream — a clean shutdown leaves shutdown lines behind. Here, writing stops dead right after GPU process gone
  • No dumps — if nothing new has appeared in %APPDATA%\Claude\Crashpad\, it was not a native crash on the CLI side

3. Why unrelated sessions go down with it

This is the heart of the bug, and the reason no setting can get you out of it.

Electron (Chromium) concentrates rendering work in a dedicated GPU process. And there is exactly one of that process per application. Every window, every tab and every session shares it.

So when one page opened in the in-app browser kills the GPU process, sessions that have no connection to that page whatsoever go down at the same instant. There is no per-tab or per-session isolation. ✅ Confirmed: this is by design in Chromium's process model, and there is no user-facing setting that will separate them.

Everything shares one GPU process

Session A
different project
Session B
different project
Session C
opens a heavy page
↓ ↓ ↓
GPU process (one per app)
when this dies, everything above it stops

4. The trigger — the in-app browser is the most common one, not the only one

✅ Confirmed: the trigger that appears most often in public issues is the in-app browser (the browser pane). #80444 records the GPU process dying 15 to 36 seconds after a page opened in a browser tab ran WebGL/WebGPU feature detection — four times, with the same 0x060C201E every time.

#82967 gets more specific still, pinning the trigger on the browser tool's preview screenshot capture (capturePreviewScreenshotIfChanged). #83478 reports reproducing it by leaving a continuously refreshing preview open.

🟡 Reported: the browser is not the only trigger, though. #68049 reports the same exit code at launch on ARM64, with no browser interaction involved at all. #83028 reproduces it on an Intel integrated GPU. "It can never happen if you avoid the browser" is not something you can say.

💡 Measured on the author's machine (not generalizable): while researching AI tools, the pattern of opening four pages in the in-app browser back to back at one- to two-second intervals was repeated about 18 times in a single day, and the GPU process died on 3 of them. It does not fall over every time — it falls over only when a particular combination of heavy pages lines up. This is one machine, so the frequency itself cannot be carried over to other environments.

5. Confirming it from the logs

Rather than leaving it at guesswork, three files will settle the question. Note that there is no such directory as ~/.claude/logs, in case you go looking for it.

What to look at Path What it tells you
The app itself%APPDATA%\Claude\logs\main.logIf the line immediately before the restart is GPU process gone, this is it
The browser window%APPDATA%\Claude\logs\unknown-window.logA CONTEXT_LOST_WEBGL at the same timestamp means the rendering side saw the GPU go down too
Native crashes%APPDATA%\Claude\Crashpad\If no new dumps have appeared, the failure was not on the CLI side

⚠️ The requestAdapter warning in the same log is not the culprit. The line "The powerPreference option is currently ignored when calling requestAdapter() on Windows." is not a sign of a crash; it is a normal Chromium message telling you that powerPreference has no effect on Windows (Chrome for Developers / Chromium issue 40268366). Open any page that uses WebGPU and it appears, crash or no crash. Do not treat its presence as evidence of anything.

The exit code separates a crash from a clean exit. "Exited" can mean very different things, and you only want to chase the one that matters.

exitCode Hex Meaning
1014579500x060C201EThe signature of this bug. The one to chase
-10737412050xC000026BSign-out or shutdown. Normal
10738073640x40010004A deliberate termination. Normal

6. Recovery — when Repair brings it back, and when it does not

Force-quit and restart, and most of the time you are back in business. The problem is the case where the app will not start again at all.

✅ Confirmed: after a GPU crash, Windows can decide the MSIX package has been "modified" and refuse to launch it. #80444 records this as appxState=2 (Modified) and reports that Settings → Apps → Claude → Advanced options → Repair brought it back every time. #81836 likewise says Repair fixes it.

What follows is, I think, the most practically useful part of this article. There are also reports where Repair does not work. #82967 describes a package that had gone as far as Modified, NeedsRemediation, where Repair failed every time and only a complete removal and reinstall brought the app back.

The order to work through when it will not start

  1. End the resident processes — while they hold the files, Repair is refused on the grounds that the app is running
  2. Repair — Settings → Apps → Installed apps → Claude → Advanced options. Your data is kept
  3. If that still fails, uninstall and reinstall (you will have to sign in again)

The steps in detail, and the question of whether conversation history and sessions get wiped, are covered in the repair procedure for "Can't open this app".

About your data. Transcripts stay on disk, so you can read them again after a restart. But #81698 reports "lost the entire in-flight run — the results from the subagents running in parallel went with it". What was saved survives; what was still running does not come back — worth keeping the two apart in your head.

7. What helps, and what does not

Unfortunately there is no real workaround. All you can do is make the trigger less likely to fire — and some of the things people suggest are reported not to work at all, so the two are listed separately.

◯ Things that help
  • Do not open heavy pages in the in-app browser. Send them to a real browser
  • Do not open several pages at once. Leave a gap between them
  • Do not leave a preview open indefinitely (the reproduction condition in #83478)
  • Turn the browser feature off entirely — the workaround #82967 offers. But that only stops the browser-triggered cases; it does nothing for the crash-at-launch family (#68049)
  • Do not pile a long stretch of work into one session. Re-reading it after a recovery is lighter
× Things that do not work, or cannot be done
  • --disable-gpu is not available — the MSIX build rejects it with "access is denied" (#82967)
  • Updating the app does not fix it — it recurred on a newer build on the author's machine
  • Isolating the GPU process — structurally impossible (§3)
  • Changing GPU scheduling or driver settings — #82967 tried several and reports no effect

🟡 Reported: if you are on a hybrid-GPU setup (one that switches between integrated and discrete), pinning Claude to a specific GPU under Windows Settings → System → Display → Graphics is worth a try. The reasoning comes from the Chromium side: on Windows, choosing a GPU via powerPreference has no effect — Chrome cannot yet composite across two GPUs — and it is tracked as Chromium issue 40268366. In other words, an app cannot pin which GPU it renders on, so if you want it pinned, the OS setting is the only lever. That said, no report of it helping with this particular symptom has been found, so do not pin your hopes on it.

8. A different thing that is easy to confuse with this — a forced quit from a Store update

The Microsoft Store (MSIX) build has the app's own auto-update disabled. Instead, the Store force-quits the running app and swaps it out. The app disappears mid-task, which makes it easy to mistake for a GPU crash.

The log tells them apart cleanly. A Store update leaves a Windows session ending (close-app) line, and no GPU process gone. If the version has changed on the next launch, that settles it.

There is no avoiding this one, so getting the update out of the way before a long session is the only mitigation available.

Summary

  • What it really is: not a Claude Code failure but a crash of the desktop app's GPU process (exitCode 101457950 / 0x060C201E)
  • Why everything goes down: the GPU process is a shared resource with one instance per app. One tab takes every session with it. No setting separates them
  • The trigger: the in-app browser most often. But crashes at launch are reported too, so it is not the only one
  • How to confirm: look at the line just before the restart in main.log. GPU process gone means this bug
  • Recovery: force-quit and restart. If it will not start, Repair. Some reports go past the point where Repair still works
  • Data: what was saved survives, but work that was in flight does not come back
  • No official fix has been announced (as of August 15, 2026)

FAQ

Q. Will my conversation history be deleted?

A. No. Transcripts are written to disk, so reopening them after a restart works fine. What was running at the moment of the crash is lost, though — there is a report of the results from subagents running in parallel disappearing along with it (#81698).

Q. Will updating the app fix it?

A. Not necessarily. On the author's machine it recurred with the same signature after an update. That said, #80444 reports it as a regression starting from a particular version, so how often it happens may well vary by build.

Q. Will updating the GPU driver fix it?

A. It is a weak lead. If the driver layer were at fault, Windows would log a TDR (event ID 4101) in the system log — and on the author's machine there was not a single one in 30 days. #68049 also reports it recurring after a driver update and a clean reinstall.

Q. Could it be low memory, or a bloated transcript?

A. Both were ruled out on the author's machine. At the moment of the crash, all Electron processes together came to about 1.7GB, with 14.8GB free out of 31.9GB. One session had a transcript that had grown to 98.5MB, but there was no correlation with the times it went down.

Q. Is it the same thing if only one session stopped?

A. No. This bug freezes the app itself, so it always takes everything down. If only one stopped, suspect a different cause. If responses merely cut off partway through, you are looking at the Connection closed mid-response or response stalled mid-stream family.