Problème où Claude Code exécute `git reset --hard origin/main` toutes les 10 minutes dans un dépôt de projet

• Dans un environnement macOS, un phénomène a été signalé où les modifications du projet étaient automatiquement supprimées toutes les 10 minutes
• Après enquête, il a été confirmé que la cause n’était pas Claude Code mais un autre outil d’automatisation local créé par l’utilisateur, qui exécutait périodiquement git reset --hard origin/main via GitPython
• Comme le même répertoire de travail était partagé, Claude Code semblait être à l’origine du problème, alors qu’en réalité c’était un script externe qui effectuait le reset
• L’équipe Claude Code a clairement indiqué qu’aucune logique d’exécution de cette commande n’existait dans son code interne, et a expliqué qu’un comportement similaire n’était possible qu’en cas d’utilisation de l’option --dangerously-skip-permissions
• En conclusion, l’incident a été attribué non pas à un bug de Claude Code mais à un outil utilisateur, et le titre a été modifié avant la clôture du sujet

---

Symptômes et environnement

• Il a été observé que Claude Code exécutait git fetch origin et git reset --hard origin/main toutes les 10 minutes dans le dépôt de projet de l’utilisateur
• Ce comportement supprime toutes les modifications non commit des fichiers suivis, tandis que les fichiers non suivis sont conservés
• Dans un environnement Git worktree, ces resets ne se produisent pas
• Informations sur l’environnement
  • Version de Claude Code : 2.1.87 (Homebrew cask, binaire Bun)
  • OS : macOS 15.4 (Darwin 25.3.0, arm64)
  • Shell : zsh

Déroulement de l’enquête

• Dans le Git reflog, plus de 95 entrées reset: moving to origin/main ont été enregistrées à intervalle de 10 minutes
  • Le décalage varie selon les sessions, mais dans chaque session la répétition se fait exactement toutes les 600 secondes
• Lors d’un test de reproduction en temps réel, le fichier suivi (api.ts) était restauré à son état d’origine au moment du reset, tandis que le fichier non suivi (.canary-test.txt) restait intact
• En surveillant le répertoire .git/ avec fswatch, un motif de modification des fichiers .git/refs et .git/logs/HEAD a été capturé au moment du reset
• Selon lsof, le seul processus utilisant ce dépôt comme CWD était le CLI Claude Code
• Aucun processus git externe n’ayant été détecté, il a été supposé qu’une exécution interne via libgit2 ou équivalent avait lieu
• Dans un environnement worktree, aucune trace de reset n’apparaît dans le reflog

Causes écartées

• Les hooks Git, les hooks utilisateur de Claude Code, les mises à jour de plugins, la synchronisation cloud macOS, Cron/LaunchAgents, l’IDE, Time Machine, les outils de surveillance de fichiers, etc. ont tous été confirmés comme sans lien
• Chaque hypothèse a été écartée par inspection réelle des fichiers de configuration et des processus

Analyse binaire (partielle)

• Certaines fonctions dans le binaire Claude Code contiennent des fragments de code exécutant la commande ["fetch","origin"]
• Une fonction wrapper pour git pull et une logique de gestion d’état fileHistory existent, mais aucun minuteur sur 10 minutes n’a été identifié

Impact

• Les modifications non commit étaient automatiquement supprimées toutes les 10 minutes, si bien que des changements ont disparu au moins trois fois pendant une session de deux heures
• Quand toutes les modifications étaient commit, le reset n’avait plus d’effet, ce qui rendait le problème intermittent en apparence

Réponse de l’équipe Claude Code

• Jarred-Sumner a explicitement déclaré que « Claude Code lui-même ne contient pas de code exécutant git reset --hard origin/main »
• Il a expliqué qu’avec l’option --dangerously-skip-permissions, Claude peut exécuter des commandes shell sans demander de confirmation, et que si la commande /loop 10m <prompt> demandait périodiquement de “se synchroniser avec le distant”, cela pouvait conduire à l’exécution de git fetch && git reset --hard origin/main
• Comme méthode de vérification, il a proposé :
  1. grep -r "reset --hard" ~/.claude/projects/ pour rechercher dans les logs de session
  2. exécuter claude --debug-file /tmp/debug.txt --dangerously-skip-permissions, attendre 10 minutes, puis rechercher grep -i bash /tmp/debug.txt | grep reset
• La fonctionnalité fileHistory de Claude Code n’a aucun lien avec git et n’appelle pas git reset en interne

Conclusion finale

• Une mise à jour du 30 mars 2026 a confirmé que la cause profonde du problème n’était pas Claude Code mais un outil local distinct de l’utilisateur
• Cet outil utilisait GitPython pour effectuer un hard reset toutes les 10 minutes et surveillait le même répertoire que Claude Code
• L’issue a été close avec le statut « not planned », et son titre a été modifié de « Claude Code exécute le reset » à « Mon outil d’automatisation exécute le reset »

Solution temporaire

• Avec git worktree, le reset n’a aucun impact
• En commitant fréquemment, il est possible de protéger les modifications

Issues liées

• #8072 — problème où des modifications de code sont annulées de manière répétée
• #7232 — perte de données due à l’exécution de git reset --hard sans approbation
• #32793 — problème où la commande claude install modifie incorrectement l’URL du remote git (cas similaire mais distinct)