« GPU process gone » — Claude Desktop se fige et emporte toutes vos sessions Claude Code

Vous êtes en plein travail quand Claude Desktop se fige d'un coup et que toutes les sessions Claude Code ouvertes meurent en même temps. Vous forcez l'arrêt, vous relancez — et il arrive que l'application refuse alors de démarrer. Quand cela se produit, la dernière ligne du journal est presque toujours la même.

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

Cet article explique ce que signifie cet exitCode 101457950 (= 0x060C201E), pourquoi des sessions qui n'ont rien à voir entre elles tombent ensemble, et quels remèdes tiennent la route — et lesquels non.

1. Le verdict — ce n'est pas Claude Code qui a lâché, c'est le contenant

Commençons par séparer les deux. Vous avez l'impression que « Claude Code a planté », mais ce n'est pas Claude Code (la CLI) qui a planté. Ce qui a planté, c'est le processus GPU de l'application de bureau (Electron) qui l'héberge.

✅ Confirmé : le test est simple, il suffit de regarder la fin de %APPDATA%\Claude\logs\main.log. Si la ligne qui précède immédiatement le redémarrage est GPU process gone, c'est bien de cela qu'il s'agit. Le journal s'arrête là, et la ligne suivante est Starting app.

Et le point important, c'est que ce que vous perdez est un processus, pas vos données. L'historique de conversations et les transcriptions sont écrits sur le disque : rouvrir la session après un redémarrage vous ramène là où vous en étiez. Le travail qui était en cours d'exécution, en revanche, c'est une autre histoire — le §6 y revient.

2. Le symptôme — elle ne plante pas, elle se fige

Le plus pénible dans ce bug, c'est que l'application ne disparaît pas : elle reste là, sans répondre. Pas de boîte de dialogue de plantage, pas de redémarrage automatique. Elle reste simplement figée jusqu'à ce que vous vous en aperceviez et forciez son arrêt.

Sur les trois occurrences observées sur la machine de l'auteur (Windows 11 / RTX 2080 Ti / 32 Go de RAM) le 14 août 2026, le plus long intervalle entre la mort du processus GPU et l'arrêt forcé a été d'environ 30 minutes. Pendant tout ce temps, les huit sessions ouvertes sont restées à l'arrêt.

3. Pourquoi des sessions sans rapport tombent avec elle

C'est le cœur du bug, et aussi la raison pour laquelle aucun réglage ne vous en sortira.

Electron (Chromium) concentre le travail de rendu dans un processus dédié, le processus GPU. Et il n'en existe qu'un seul par application. Toutes les fenêtres, tous les onglets et toutes les sessions le partagent.

Autrement dit, quand une seule page ouverte dans le navigateur intégré tue le processus GPU, des sessions qui n'ont strictement aucun lien avec cette page tombent au même instant. Il n'y a pas d'isolation par onglet ni par session. ✅ Confirmé : c'est ainsi que le modèle de processus de Chromium est conçu, et aucun réglage accessible à l'utilisateur ne permet de les séparer.

4. Le déclencheur — le navigateur intégré est le plus fréquent, mais pas le seul

✅ Confirmé : le déclencheur qui revient le plus souvent dans les tickets publics est le navigateur intégré (le panneau navigateur). Le ticket #80444 décrit le processus GPU mourant 15 à 36 secondes après qu'une page ouverte dans un onglet du navigateur a lancé la détection de fonctionnalités WebGL/WebGPU — quatre fois, avec le même 0x060C201E à chaque fois.

Le ticket #82967 va plus loin dans le détail et attribue le déclenchement à la capture de captures d'écran d'aperçu de l'outil navigateur (capturePreviewScreenshotIfChanged). Le ticket #83478 rapporte l'avoir reproduit en laissant ouvert un aperçu qui se rafraîchit en continu.

🟡 Signalé : le navigateur n'est cependant pas le seul déclencheur. Le ticket #68049 signale le même code de sortie au démarrage sur ARM64, sans la moindre interaction avec le navigateur. Le ticket #83028 le reproduit sur un GPU intégré Intel. « Cela ne peut jamais arriver si vous n'utilisez pas le navigateur » n'est pas une chose que l'on peut affirmer.

5. Confirmer le diagnostic dans les journaux

Plutôt que d'en rester aux conjectures, trois fichiers suffisent à trancher. Notez au passage qu'il n'existe aucun répertoire ~/.claude/logs, au cas où vous iriez le chercher.

Le code de sortie distingue un plantage d'une fermeture propre. « Terminé » peut recouvrir des choses très différentes, et vous ne voulez suivre que celle qui compte.

6. Récupération — quand Réparer la ramène, et quand il n'y parvient pas

Forcez l'arrêt, relancez, et la plupart du temps tout repart. Le problème, c'est le cas où l'application refuse purement et simplement de redémarrer.

✅ Confirmé : après un plantage du GPU, Windows peut décider que le paquet MSIX a été « modifié » et refuser de le lancer. Le ticket #80444 consigne cet état sous la forme appxState=2 (Modified) et rapporte que Paramètres → Applications → Claude → Options avancées → Réparer l'a ramenée à chaque fois. Le ticket #81836 dit lui aussi que Réparer suffit.

Ce qui suit est, à mon sens, la partie la plus utile en pratique de cet article. Il existe aussi des signalements où Réparer ne fonctionne pas. Le ticket #82967 décrit un paquet parvenu jusqu'à l'état Modified, NeedsRemediation, où Réparer a échoué systématiquement et où seules une suppression complète et une réinstallation ont ramené l'application.

À propos de vos données. Les transcriptions restent sur le disque, vous pouvez donc les relire après un redémarrage. Mais le ticket #81698 rapporte avoir « perdu tout le travail en cours — les résultats des sous-agents lancés en parallèle sont partis avec ». Ce qui était enregistré survit ; ce qui était encore en train de tourner ne revient pas — deux choses qu'il vaut mieux garder distinctes dans son esprit.

7. Ce qui aide, et ce qui n'aide pas

Malheureusement, il n'existe pas de contournement de fond. Tout ce que vous pouvez faire, c'est rendre le déclenchement moins probable — et comme certaines des solutions que l'on vous proposera sont signalées comme sans effet, les deux listes sont séparées.

🟡 Signalé : si vous êtes sur une configuration à GPU hybride (qui bascule entre carte intégrée et carte dédiée), fixer le GPU utilisé par Claude dans Paramètres → Système → Affichage → Graphiques de Windows vaut la peine d'être essayé. Le raisonnement vient du côté Chromium : sous Windows, choisir un GPU via powerPreference n'a aucun effet — Chrome ne sait pas encore composer une image en s'appuyant sur deux GPU à la fois — et le sujet est suivi sous la référence ticket Chromium 40268366. Autrement dit, une application ne peut pas fixer elle-même le GPU sur lequel elle dessine : si vous voulez le fixer, le réglage du système d'exploitation est le seul levier. Cela dit, aucun signalement indiquant que cela ait aidé pour ce symptôme précis n'a été trouvé, alors n'en attendez pas trop.

8. Un phénomène voisin, facile à confondre — l'arrêt forcé par une mise à jour du Store

Dans la version distribuée par le Microsoft Store (MSIX), la mise à jour automatique propre à l'application est désactivée. À la place, c'est le Store qui force l'arrêt de l'application en cours d'exécution et la remplace. L'application disparaît en plein travail, ce qui la rend facile à confondre avec un plantage du GPU.

Le journal les distingue sans ambiguïté. Une mise à jour du Store laisse une ligne Windows session ending (close-app), et aucun GPU process gone. Si le numéro de version a changé au lancement suivant, l'affaire est entendue.

Celle-là est inévitable : faire passer la mise à jour avant d'entamer une longue session de travail est le seul moyen d'en limiter les effets.

Résumé

FAQ

Articles liés

• Claude Desktop « Impossible d'ouvrir cette application » — la réparer avec Réparer (le nettoyage après ce bug)
• « Un autre programme utilise actuellement ce fichier » (0x80070020) (un autre problème : elle ne démarre plus après une mise à jour)
• Panorama des erreurs Claude Code