Claude Desktop 0x80070020 : ne démarre plus après MàJ

Juste après avoir mis à jour Claude Desktop (Windows), essayer de lancer l'application fait apparaître une boîte de dialogue indiquant « Un autre programme utilise actuellement ce fichier » et l'application refuse de démarrer — et elle reste bloquée jusqu'au redémarrage du PC. C'est un bug connu, signalé pour la version Microsoft Store (MSIX) de Claude Desktop (GitHub #53247 et d'autres).

Commençons par l'essentiel. Un redémarrage complet du PC n'est pas forcément nécessaire. Dans bien des cas, il suffit de se déconnecter de Windows puis de se reconnecter pour récupérer (ce n'est ni un redémarrage du PC, ni une déconnexion de Claude). Ci-dessous, nous séparons ce qui marche, ce qui ne marche pas et ce qu'est vraiment l'erreur, en distinguant confirmé / supposé / non confirmé. Cet article s'appuie sur des journaux d'enquête d'une seule machine (Windows 11 Home, 10.0.26200), recoupés avec des issues GitHub connues.

1. L'essentiel — déconnectez d'abord votre session Windows pour récupérer

Le vrai préjudice de ce bug est « impossible de lancer », mais la récupération ne demande pas forcément un redémarrage complet du PC. Selon l'analyse de #53247, le « handle orphelin » à l'origine du problème persiste par session utilisateur Windows ; il suffit donc de se déconnecter de Windows puis de se reconnecter pour l'effacer. La plupart des gens redémarrent tout le PC par réflexe, ce qui fait perdre ce temps inutilement.

• ✅ Vous voulez que ce soit réglé tout de suite : se déconnecter → se reconnecter. Des cas sont rapportés où cela permet de relancer l'application (#53247).
• ✅ Vous voulez que ce soit réglé à coup sûr : redémarrer le PC. Lourd, mais fiable.
• ✅ Vous voulez empêcher la récidive : abandonner la version MSIX et passer à la version Squirrel (installeur) (voir plus bas ; d'après le rapporteur de #57221).

2. Symptôme — il apparaît au lancement après une mise à jour

La séquence typique : une fois la mise à jour de Claude Desktop appliquée, l'ouverture de l'application affiche une boîte de dialogue de style Explorateur Windows indiquant « Un autre programme utilise actuellement ce fichier », et elle ne démarre pas. Fermer puis rouvrir donne le même résultat, et rien ne se rétablit avant un redémarrage du PC (ou une déconnexion).

Point crucial : le libellé de cette boîte de dialogue ne reflète pas fidèlement ce qui se passe (détails au §4). De plus, la mise à jour elle-même a réussi — ce qui échoue n'est pas la mise à jour mais « le lancement de l'application ». Cela concerne la version Microsoft Store (MSIX) de Claude Desktop.

3. La solution — ce qui marche et ce qui ne marche pas

C'est le plus gros piège. On trouve un peu partout des affirmations du type « arrêter le service corrige le problème », mais pour ce bug, elles sont rapportées comme inefficaces. Séparons nettement ce qui marche de ce qui ne marche pas.

Les éléments de droite sont consignés comme essayés et infructueux à la fois dans #48003 et #53247. Ils ont tendance à faire perdre du temps, donc il est rationnel d'essayer d'abord la déconnexion.

Solution permanente : passer à la version Squirrel (installeur)

Si subir ce problème à chaque mise à jour est insupportable, le rapporteur de #57221 indique que désinstaller la version MSIX et passer à la version installeur (Squirrel) a résolu à la fois les problèmes de mise à jour et de lancement. L'essentiel des étapes :

1. Désinstaller complètement la version Store (MSIX) de Claude Desktop.
2. Installer la version installeur depuis le téléchargement officiel de Claude ou via winget (par ex. winget install Anthropic.Claude).
3. Ensuite, la mise à jour automatique amène l'application à la dernière version.

🟡 La raison avancée est que cela sort des contraintes de C:\Program Files\WindowsApps et de la couche du conteneur AppX. Le comportement peut varier selon l'environnement ; vérifiez donc votre cas d'usage (politique de déploiement en entreprise, etc.) avant de basculer.

4. Ce qu'est vraiment l'erreur — pas un verrou de fichier (confirmé)

La boîte de dialogue se lit comme « le fichier est en cours d'utilisation », mais dans les journaux de la machine, l'échec se situe ailleurs. Le journal d'événements Microsoft-Windows-AppModel-Runtime/Admin enregistre ce qui suit (✅ confirmé sur la machine) :

Event ID 215:
0x80070020: Cannot create the Desktop AppX container for package
            Claude_..._x64__pzs8sxrjxfjjc
            because an error was encountered converting the job.

Event ID 208:
0x80070020: Cannot create the process for package ... [LaunchProcess]

Et ✅ il a été vérifié qu'« aucun verrou de fichier n'existe ». Dans #53247, la vérification avec handle.exe et Process Explorer n'a montré aucun verrou de fichier en espace utilisateur. Ainsi, « parce qu'un autre programme retient le fichier » est faux, du moins en tant que verrou en espace utilisateur. Le vrai problème se situe dans la couche conteneur (Job/Silo) d'AppX/Desktop Bridge.

5. Deux explications concurrentes, pas encore tranchées

« Un problème de couche conteneur » est confirmé, mais il existe deux points de vue sur le déclencheur, et la question n'est pas tranchée. Nous évitons d'en affirmer un et présentons les deux.

À noter la tension suivante : si la thèse A (rétention par le service) était juste, « arrêter le service » devrait corriger le problème — or c'est rapporté comme inefficace (§3). En raison de cette contradiction, on ne sait pas laquelle prime. 🔴 Pour l'instant, présenter les deux est la posture honnête.

Par ailleurs, ce symptôme est confirmé dans plusieurs langues. Le rapporteur de #53247 est dans un environnement en portugais, où la boîte de dialogue indique « Há um outro programa usando este arquivo no momento » (un autre programme utilise actuellement ce fichier) — le même symptôme que dans le libellé anglais/japonais.

6. Vérifiez-le sur votre propre machine (PowerShell)

Vous pouvez vérifier si votre problème est le même que celui de cet article (aucun droit administrateur nécessaire). Si les événements 215/208 et 0x80070020 apparaissent, c'est le même problème.

Get-WinEvent -LogName 'Microsoft-Windows-AppModel-Runtime/Admin' |
  Where-Object { $_.Message -match 'Claude' } |
  Select-Object TimeCreated, Id, Message | Format-List

Pour recouper avec votre historique de mises à jour, et pour voir les réglages actuels du service intégré :

Get-WinEvent -LogName 'Microsoft-Windows-AppXDeploymentServer/Operational' |
  Where-Object { $_.Message -match 'Claude' } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List

Get-CimInstance Win32_Service -Filter "Name='CoworkVMService'" |
  Select-Object Name, StartMode, State, PathName

7. Des problèmes différents faciles à confondre

Claude Desktop (Windows) présente d'autres bugs aux codes d'apparence similaire qui sont faciles à confondre. Ils sont distincts du 0x80070020 de cet article (un échec de lancement) ; gardez-les donc séparés.

De plus, lorsque le CLI Claude Code (le claude.exe géré par l'application de bureau) se met à jour, vous pouvez voir EPERM: operation not permitted, unlink ... claude.exe, mais ce n'est qu'un échec de suppression de l'ancienne version — la nouvelle s'est bien installée — et c'est sans rapport avec ce bug.

Récapitulatif

• ✅ Déconnectez-vous d'abord de Windows → reconnectez-vous : la récupération ne demande pas forcément un redémarrage complet du PC (#53247). Si cela échoue, redémarrez le PC.
• 🔴 Arrêter/réenregistrer le service est rapporté comme inefficace : cela a tendance à faire perdre du temps, à éviter.
• ✅ La vraie cause n'est pas un « verrou de fichier » : c'est un échec dans la couche conteneur AppX (conversion Job→Silo). Le libellé de la boîte de dialogue ne reflète pas la réalité.
• 🔴 Le déclencheur a deux explications non tranchées : rétention par le service (#57221) vs. plantage au démarrage → handle orphelin (#53247). Aucun correctif officiel pour l'instant.
• ✅ La solution permanente est de passer à la version Squirrel : rapportée comme résolvant à la fois les problèmes de mise à jour et de lancement (#57221).

Cet article s'appuie sur les journaux d'enquête d'une seule machine (Windows 11 Home, 10.0.26200), recoupés avec des issues GitHub. Utilisez-le en sachant, en toute honnêteté, qu'il peut ne pas se reproduire à l'identique chez chaque utilisateur et que les détails fins de la cause restent à trancher.

FAQ

Q1. Quel est le moyen le plus rapide de corriger ?

Déconnectez-vous une fois de Windows puis reconnectez-vous (Démarrer → votre icône utilisateur → « Se déconnecter »). Ce n'est pas un redémarrage du PC, et pas une déconnexion de l'application/du compte Claude. D'après #53247, le handle orphelin sous-jacent persiste par session utilisateur Windows, donc un redémarrage complet du PC peut être inutile. Si cela ne se rétablit toujours pas, redémarrez le PC.

Q2. J'ai lu « il suffit d'arrêter le service » — ça marche ?

Pour ce bug, c'est rapporté comme inefficace (#48003, #53247). Stop-Service CoworkVMService : le service redémarre et l'erreur récidive, et Reset-AppxPackage ainsi que le redémarrage des divers services n'ont pas non plus résolu le problème. Il est plus rationnel d'essayer d'abord la déconnexion.

Q3. Le fichier est-il vraiment verrouillé ?

Non. La boîte de dialogue se lit comme « le fichier est en cours d'utilisation », mais la vérification (handle.exe / Process Explorer) a confirmé l'absence de verrou de fichier en espace utilisateur (#53247). Le vrai problème est un échec dans la couche conteneur (conversion Job Object → Silo) d'AppX/Desktop Bridge ; le code générique 0x80070020 (ERROR_SHARING_VIOLATION) est simplement traduit ainsi.

Q4. Alors quelle est la cause, au final ?

Le problème de couche conteneur est confirmé, mais le déclencheur a deux explications non tranchées : (1) CoworkVMService (démarrage automatique) retenant le Job Object (#57221), et (2) un plantage au démarrage laissant le nettoyage du Silo/Job inachevé, si bien qu'un handle orphelin subsiste (#53247). Puisque arrêter le service ne corrige rien, ce qui contredit (1), on ne peut pas l'affirmer de façon définitive pour l'instant.

Q5. Existe-t-il un correctif officiel ?

Au moment de l'enquête, aucun correctif permanent officiel n'a été publié. L'issue centrale #53247 est toujours Open. Sur l'issue, des correctifs permanents tels que passer le service à un démarrage à la demande (Manual) en sont au stade de proposition.

Q6. Cela arrive-t-il à chaque mise à jour ?

🔴 Impossible à affirmer de façon définitive. Sur la machine, on avait l'impression que « ça arrive à chaque mise à jour », pourtant le journal d'événements ne l'a montré que dans 2 mises à jour sur 6 (des enregistrements plus anciens ont pu être effacés à cause de la limite de taille du journal, donc c'est indéterminé). La fréquence peut varier selon la machine.

Q7. Comment empêcher la récidive ?

Un signalement indique qu'abandonner la version MSIX (Store) et passer à la version Squirrel (installeur) a résolu à la fois les problèmes de mise à jour et de lancement (#57221). Vous désinstallez complètement la version Store, puis installez la version installeur depuis le site officiel ou via winget. Si vous avez des contraintes comme une politique de déploiement en entreprise, vérifiez au préalable.

Articles liés

• Erreur « Response stalled mid-stream » de Claude Code — cause et solution d'une autre erreur connue
• Erreur « Output blocked » de Claude Code — arrêt sur le filtre de contenu