Impossible d'ouvrir cette application : Claude Desktop ne démarre plus sous Windows, réparez-le sans perdre vos sessions
Vous essayez d'ouvrir Claude Desktop sous Windows et ce qui apparaît est une boîte de dialogue intitulée « Impossible d'ouvrir cette application », qui vous demande d'aller dans les options avancées de Claude et de choisir Réparer — et faire exactement ce qu'elle dit fonctionne. Sans désinstaller quoi que ce soit, et sans passer par Réinitialiser, qui, lui, jette vos données. Il y a toutefois une marche au milieu du chemin, et c'est le cœur de cet article. Un clic sur Réparer peut vous renvoyer un message vous disant que l'application est encore en cours d'exécution, alors qu'aucune fenêtre Claude n'est ouverte nulle part. La cause est que Claude Desktop continue de tourner dans la zone de notification après la fermeture de sa fenêtre : tant que ce processus résident tient ouverts les fichiers du paquet, la réparation ne peut pas aboutir. La solution est simple : fermez explicitement les processus, puis cliquez sur Réparer. Et ce fait désigne la cause même de la panne, le même processus ayant cassé la mise à jour avant de bloquer la réparation. L'article répond aussi à la question que tout le monde pose en premier : vos sessions sont-elles effacées ? La réponse se divise en trois. Votre historique de conversations claude.ai est sur les serveurs d'Anthropic et reste intact. Les sessions Claude Code vivent dans %USERPROFILE%\.claude\projects\, hors du paquet de l'application : elles survivent à une réparation, à une réinitialisation et même à une désinstallation (une machine réelle en contenait 2 977 fichiers, environ 3,0 Go, répartis sur 52 projets). La seule chose exposée, ce sont les réglages côté application dans %APPDATA%\Claude, et Réparer les conserve même — Windows écrit la différence sur l'écran lui-même, en indiquant à côté de Réparer que les données de l'application ne seront pas affectées, et à côté de Réinitialiser qu'elles seront supprimées. Suivent la vérification d'état en PowerShell en lecture seule, une routine de sauvegarde, une escalade par paliers quand l'application refuse toujours de s'ouvrir (contrôle de vmcompute et hns, réinstallation avec -PreserveApplicationData), la cause déduite d'un MSIX à moitié enregistré appuyée sur les tickets GitHub (#55465, où l'installation a réussi sans qu'aucun point d'entrée soit créé, plus #50285 et #48437 — tous clos en closed as not planned, sans correctif officiel), les moyens de réduire les risques de récidive, et une comparaison avec l'ancienne version installeur, où la dernière version MSIX et une machine en ancien format affichaient toutes deux 1.24012.9.