Sie stecken mitten in der Arbeit, als Claude Desktop plötzlich einfriert und sämtliche offenen Claude-Code-Sitzungen auf einen Schlag sterben. Sie erzwingen das Beenden und starten neu — und manchmal weigert sich die App danach überhaupt zu starten. Wenn es so weit kommt, steht in der letzten Zeile des Protokolls fast immer dieselbe Meldung.

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

Dieser Artikel legt dar, was dieser exitCode 101457950 (= 0x060C201E) bedeutet, warum Sitzungen mit untergehen, die miteinander nichts zu tun haben, und welche Gegenmittel real sind und welche nicht.

⚠️ Vertrauenskennzeichnung in diesem Artikel: ✅ Bestätigt = in einem öffentlichen Issue dokumentiert oder auf dem Rechner des Autors gemessen / 🟡 Berichtet = es liegen mehrere Meldungen vor, aber keine offizielle Bestätigung / 🔴 Unbestätigt = lässt sich nicht als Tatsache behaupten. Anthropic hat zu diesem Symptom weder eine Erklärung der Ursache noch eine Korrekturmeldung veröffentlicht (soweit sich das am 15. August 2026 prüfen ließ).

GPU PROCESS GONE · 0x060C201E

Ein einziger Tab reißt alle Sitzungen mit

— weil der GPU-Prozess eine gemeinsame Ressource ist und es pro App nur einen davon gibt

Was passiert
Die App reagiert nicht mehr. Sie verschwindet nicht, sie friert ein — und bleibt es, bis Sie das Beenden erzwingen
Reichweite des Schadens
Jede offene Sitzung. Auch völlig unbeteiligte Projekte stehen im selben Moment still
Lässt es sich trennen?
Nein. Das folgt aus dem Aufbau von Electron/Chromium, und keine Einstellung ändert daran etwas
Wie Sie zurückkommen
Beenden erzwingen, dann neu starten. Startet sie nicht mehr, hilft Reparieren

1. Das Fazit — nicht Claude Code ist ausgefallen, sondern die Hülle darum

Beginnen wir damit, die beiden auseinanderzuhalten. Es fühlt sich an wie „Claude Code ist abgestürzt“, aber abgestürzt ist nicht Claude Code (die CLI). Abgestürzt ist der GPU-Prozess der Desktop-App (Electron), in der es läuft.

✅ Bestätigt: Die Probe ist einfach — sehen Sie sich das Ende von %APPDATA%\Claude\logs\main.log an. Steht unmittelbar vor dem Neustart die Zeile GPU process gone, haben Sie genau dieses Problem. Das Protokoll bricht dort ab, und die nächste Zeile lautet Starting app.

Entscheidend ist dabei: Was Sie verlieren, ist ein Prozess, nicht Ihre Daten. Unterhaltungsverlauf und Transkripte liegen auf der Festplatte, ein erneutes Öffnen der Sitzung nach dem Neustart knüpft also dort an, wo Sie aufgehört haben. Mit laufender Arbeit verhält es sich anders — darauf kommt §6 zurück.

2. Das Symptom — sie stürzt nicht ab, sie hängt

Das Unangenehmste an diesem Fehler ist, dass die App nicht verschwindet, sondern reaktionslos stehen bleibt. Kein Absturzdialog, kein automatischer Neustart. Sie bleibt schlicht eingefroren, bis Sie es bemerken und das Beenden erzwingen.

Bei drei Vorfällen, die am 14. August 2026 auf dem Rechner des Autors beobachtet wurden (Windows 11 / RTX 2080 Ti / 32 GB RAM), lag der längste Abstand zwischen dem Tod des GPU-Prozesses und dem erzwungenen Beenden bei rund 30 Minuten. Über diese ganze Zeit blieben alle acht offenen Sitzungen stehen.

Drei Erkennungsmerkmale

  • Alles, nicht bloß eine — ist nur eine einzelne Sitzung stehen geblieben, suchen Sie woanders. Sind mehrere Sitzungen innerhalb derselben Minute neu gestartet, ist die App selbst gefallen
  • Das Protokoll bricht mittendrin ab — ein sauberes Herunterfahren hinterlässt Zeilen zum Beendungsvorgang. Hier hört das Schreiben schlagartig auf, direkt nach GPU process gone
  • Keine Dumps — ist in %APPDATA%\Claude\Crashpad\ nichts Neues aufgetaucht, war es kein nativer Absturz auf der Seite der CLI

3. Warum unbeteiligte Sitzungen mit untergehen

Hier liegt der Kern des Fehlers, und zugleich der Grund, warum keine Einstellung Sie da herausbringt.

Electron (Chromium) bündelt die Darstellungsarbeit in einem eigenen GPU-Prozess. Und von diesem Prozess gibt es genau einen pro Anwendung. Jedes Fenster, jeder Tab und jede Sitzung teilt ihn sich.

Das heißt: Wenn eine einzige im In-App-Browser geöffnete Seite den GPU-Prozess umbringt, gehen im selben Augenblick Sitzungen unter, die mit dieser Seite nicht das Geringste zu tun haben. Eine Trennung pro Tab oder pro Sitzung gibt es nicht. ✅ Bestätigt: Das ist im Prozessmodell von Chromium so vorgesehen, und es gibt keine Einstellung auf Anwenderseite, die sie voneinander trennen würde.

Alles teilt sich einen einzigen GPU-Prozess

Sitzung A
anderes Projekt
Sitzung B
anderes Projekt
Sitzung C
öffnet eine schwere Seite
↓ ↓ ↓
GPU-Prozess (einer pro App)
stirbt er, steht alles darüber still

4. Der Auslöser — der In-App-Browser ist der häufigste, nicht der einzige

✅ Bestätigt: Der Auslöser, der in den öffentlichen Issues am häufigsten auftaucht, ist der In-App-Browser (der Browser-Bereich). #80444 hält fest, wie der GPU-Prozess 15 bis 36 Sekunden nachdem eine in einem Browser-Tab geöffnete Seite die Funktionserkennung für WebGL/WebGPU ausführte, starb — viermal, jedes Mal mit demselben 0x060C201E.

#82967 wird noch konkreter und macht als Auslöser die Aufnahme des Vorschau-Screenshots durch das Browser-Werkzeug aus (capturePreviewScreenshotIfChanged). #83478 berichtet, es reproduziert zu haben, indem eine sich fortlaufend aktualisierende Vorschau offen blieb.

🟡 Berichtet: Der Browser ist allerdings nicht der einzige Auslöser. #68049 meldet denselben Exit-Code beim Start auf ARM64, ganz ohne Zutun des Browsers. #83028 reproduziert ihn auf einer integrierten Intel-GPU. „Wenn Sie den Browser meiden, kann es nie passieren“ lässt sich also nicht sagen.

💡 Auf dem Rechner des Autors gemessen (nicht verallgemeinerbar): Bei der Recherche zu KI-Werkzeugen wurde das Muster, vier Seiten im Abstand von ein bis zwei Sekunden nacheinander im In-App-Browser zu öffnen, an einem einzigen Tag etwa 18-mal wiederholt, und in 3 Fällen starb der GPU-Prozess. Es kippt nicht jedes Mal um — es kippt nur dann, wenn eine bestimmte Kombination schwerer Seiten zusammenkommt. Das ist ein einzelner Rechner, die Häufigkeit selbst lässt sich also nicht auf andere Umgebungen übertragen.

5. Es über die Protokolle bestätigen

Statt es bei Vermutungen zu belassen: drei Dateien klären die Frage. Falls Sie danach suchen sollten — ein Verzeichnis ~/.claude/logs gibt es nicht.

Was Sie ansehen Pfad Was es Ihnen sagt
Die App selbst%APPDATA%\Claude\logs\main.logLautet die Zeile unmittelbar vor dem Neustart GPU process gone, ist es dieser Fall
Das Browser-Fenster%APPDATA%\Claude\logs\unknown-window.logEin CONTEXT_LOST_WEBGL zum selben Zeitstempel heißt, dass auch die Darstellungsseite die GPU wegbrechen sah
Native Abstürze%APPDATA%\Claude\Crashpad\Sind keine neuen Dumps hinzugekommen, lag der Fehler nicht auf der Seite der CLI

⚠️ Die requestAdapter-Warnung im selben Protokoll ist nicht der Schuldige. Die Zeile „The powerPreference option is currently ignored when calling requestAdapter() on Windows.“ ist kein Anzeichen für einen Absturz; sie ist eine ganz normale Chromium-Meldung, die Ihnen mitteilt, dass powerPreference unter Windows keine Wirkung hat (Chrome for Developers / Chromium issue 40268366). Öffnen Sie irgendeine Seite, die WebGPU nutzt, und sie erscheint — mit oder ohne Absturz. Nehmen Sie ihr Vorhandensein für gar nichts als Beleg.

Der Exit-Code trennt einen Absturz von einem sauberen Ende. „Beendet“ kann sehr Unterschiedliches heißen, und verfolgen wollen Sie nur das, worauf es ankommt.

exitCode Hex Bedeutung
1014579500x060C201EDie Signatur dieses Fehlers. Der, dem Sie nachgehen sollten
-10737412050xC000026BAbmelden oder Herunterfahren. Normal
10738073640x40010004Ein absichtliches Beenden. Normal

6. Wiederherstellung — wann Reparieren sie zurückbringt und wann nicht

Beenden erzwingen, neu starten, und meistens sind Sie wieder im Geschäft. Das Problem ist der Fall, in dem die App überhaupt nicht mehr startet.

✅ Bestätigt: Nach einem GPU-Absturz kann Windows entscheiden, das MSIX-Paket sei „verändert“ worden, und den Start verweigern. #80444 hält das als appxState=2 (Modified) fest und berichtet, dass Einstellungen → Apps → Claude → Erweiterte Optionen → Reparieren sie jedes Mal zurückgebracht hat. #81836 sagt ebenfalls, dass Reparieren es behebt.

Was jetzt folgt, ist meines Erachtens der praktisch nützlichste Teil dieses Artikels. Es gibt auch Berichte, in denen Reparieren nicht funktioniert. #82967 beschreibt ein Paket, dessen Zustand bis Modified, NeedsRemediation fortgeschritten war, bei dem Reparieren jedes Mal fehlschlug und nur eine vollständige Entfernung samt Neuinstallation die App zurückbrachte.

Die Reihenfolge, wenn sie nicht mehr startet

  1. Die Hintergrundprozesse beenden — solange sie die Dateien halten, wird Reparieren mit der Begründung abgelehnt, die App laufe noch
  2. Reparieren — Einstellungen → Apps → Installierte Apps → Claude → Erweiterte Optionen. Ihre Daten bleiben erhalten
  3. Hilft auch das nicht, deinstallieren und neu installieren (Sie müssen sich danach erneut anmelden)

Die Schritte im Einzelnen und die Frage, ob Unterhaltungsverlauf und Sitzungen dabei gelöscht werden, behandelt der Reparaturablauf für „Diese App kann nicht geöffnet werden“.

Zu Ihren Daten. Transkripte bleiben auf der Festplatte, Sie können sie nach einem Neustart also wieder lesen. Allerdings berichtet #81698: „der komplette laufende Durchgang war weg — die Ergebnisse der parallel laufenden Subagenten gingen mit“. Was gespeichert war, überlebt; was noch lief, kommt nicht zurück — die beiden sollten Sie im Kopf auseinanderhalten.

7. Was hilft und was nicht

Leider gibt es keinen echten Workaround. Sie können nur dafür sorgen, dass der Auslöser seltener zündet — und einiges von dem, was empfohlen wird, funktioniert Berichten zufolge überhaupt nicht, deshalb sind beide getrennt aufgeführt.

◯ Was hilft
  • Keine schweren Seiten im In-App-Browser öffnen. Schicken Sie sie in einen echten Browser
  • Nicht mehrere Seiten auf einmal öffnen. Lassen Sie Abstand dazwischen
  • Keine Vorschau dauerhaft offen lassen (die Reproduktionsbedingung in #83478)
  • Die Browser-Funktion ganz abschalten — der Behelf, den #82967 nennt. Das stoppt aber nur die vom Browser ausgelösten Fälle; gegen die Familie der Abstürze beim Start (#68049) richtet es nichts aus
  • Nicht endlos viel Arbeit in einer einzigen Sitzung anhäufen. Das erneute Einlesen nach einer Wiederherstellung fällt dann leichter
× Was nicht wirkt oder nicht geht
  • --disable-gpu steht nicht zur Verfügung — die MSIX-Variante weist es mit „Zugriff verweigert“ ab (#82967)
  • Die App zu aktualisieren behebt es nicht — auf dem Rechner des Autors trat es mit einer neueren Version erneut auf
  • Den GPU-Prozess zu isolieren — strukturell unmöglich (§3)
  • GPU-Planung oder Treibereinstellungen zu ändern — #82967 hat mehreres probiert und berichtet von keinerlei Wirkung

🟡 Berichtet: Wenn Sie ein Hybrid-GPU-Gespann verwenden (eines, das zwischen integrierter und dedizierter Grafik umschaltet), ist es einen Versuch wert, Claude unter Windows in Einstellungen → System → Bildschirm → Grafik auf eine bestimmte GPU festzulegen. Die Begründung kommt von der Chromium-Seite: Unter Windows hat die Wahl einer GPU über powerPreference keine Wirkung — Chrome kann noch nicht über zwei GPUs hinweg zusammensetzen —, und das wird als Chromium issue 40268366 verfolgt. Anders gesagt: Eine App kann nicht festlegen, auf welcher GPU sie zeichnet, wer es festgelegt haben will, hat also nur die Einstellung des Betriebssystems als Hebel. Allerdings wurde kein Bericht gefunden, wonach das bei genau diesem Symptom geholfen hätte — setzen Sie also keine großen Hoffnungen darauf.

8. Etwas anderes, das leicht damit verwechselt wird — ein erzwungenes Beenden durch ein Store-Update

Bei der Variante aus dem Microsoft Store (MSIX) ist die eigene automatische Aktualisierung der App abgeschaltet. Stattdessen beendet der Store die laufende App gewaltsam und tauscht sie aus. Die App verschwindet also mitten in der Arbeit, was sich leicht für einen GPU-Absturz halten lässt.

Das Protokoll trennt beide sauber. Ein Store-Update hinterlässt eine Zeile Windows session ending (close-app) und kein GPU process gone. Hat sich beim nächsten Start die Version geändert, ist die Sache klar.

Dieser Fall lässt sich nicht vermeiden, deshalb ist das Update vor einer langen Arbeitsstrecke hinter sich zu bringen die einzige verfügbare Milderung.

Zusammenfassung

  • Was es wirklich ist: kein Ausfall von Claude Code, sondern ein Absturz des GPU-Prozesses der Desktop-App (exitCode 101457950 / 0x060C201E)
  • Warum alles untergeht: Der GPU-Prozess ist eine gemeinsame Ressource mit genau einer Instanz pro App. Ein einziger Tab reißt alle Sitzungen mit. Keine Einstellung trennt sie
  • Der Auslöser: am häufigsten der In-App-Browser. Es werden aber auch Abstürze beim Start gemeldet, er ist also nicht der einzige
  • So bestätigen Sie es: Sehen Sie sich in main.log die Zeile direkt vor dem Neustart an. GPU process gone heißt: dieser Fehler
  • Wiederherstellung: Beenden erzwingen und neu starten. Startet sie nicht, Reparieren. Manche Berichte gehen über den Punkt hinaus, an dem Reparieren noch wirkt
  • Daten: Was gespeichert war, überlebt, aber laufende Arbeit kommt nicht zurück
  • Eine offizielle Korrektur wurde nicht angekündigt (Stand 15. August 2026)

FAQ

F. Wird mein Unterhaltungsverlauf gelöscht?

A. Nein. Transkripte werden auf die Festplatte geschrieben, sie nach einem Neustart wieder zu öffnen funktioniert also problemlos. Was im Augenblick des Absturzes lief, ist allerdings verloren — es gibt einen Bericht, wonach die Ergebnisse parallel laufender Subagenten mit verschwanden (#81698).

F. Behebt es ein Update der App?

A. Nicht zwangsläufig. Auf dem Rechner des Autors trat es nach einem Update mit derselben Signatur erneut auf. Allerdings meldet #80444 es als Regression ab einer bestimmten Version, wie oft es auftritt, kann also durchaus von der Version abhängen.

F. Behebt es ein Update des GPU-Treibers?

A. Das ist eine schwache Spur. Läge es an der Treiberschicht, würde Windows im Systemprotokoll einen TDR (Ereignis-ID 4101) verzeichnen — und auf dem Rechner des Autors gab es in 30 Tagen keinen einzigen. Auch #68049 berichtet, dass es nach einem Treiber-Update und einer sauberen Neuinstallation wieder auftrat.

F. Könnte es an zu wenig Arbeitsspeicher oder einem aufgeblähten Transkript liegen?

A. Beides ließ sich auf dem Rechner des Autors ausschließen. Im Augenblick des Absturzes kamen alle Electron-Prozesse zusammen auf etwa 1,7 GB, bei 14,8 GB frei von 31,9 GB. Eine Sitzung hatte ein Transkript, das auf 98,5 MB angewachsen war, aber es gab keinen Zusammenhang mit den Zeitpunkten der Abstürze.

F. Ist es dasselbe, wenn nur eine einzige Sitzung stehen geblieben ist?

A. Nein. Dieser Fehler friert die App selbst ein, er reißt also immer alles mit. Ist nur eine stehen geblieben, vermuten Sie eine andere Ursache. Brechen die Antworten lediglich mittendrin ab, sind Sie bei der Familie Connection closed mid-response oder response stalled mid-stream.