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)

[GN⁺]

Commentaires sur Hacker News

• Il s’agit d’une mise à jour publiée par l’auteur lui-même
  D’après le lien vers l’issue, la cause profonde du problème n’était pas Claude Code, mais un bug dans un outil que l’auteur avait créé pour des tests locaux
  Cet outil effectuait un hard reset à chaque cycle pour synchroniser le répertoire de travail local avec le distant, supprimant ainsi toutes les modifications non commit.

  • C’est drôle que l’auteur dise avoir fait autant de « recherches » sans penser à simplement désactiver Claude pendant 10 minutes
    Je retirerais mon signalement si le titre était changé en quelque chose comme « un développeur crée un script qui réinitialise son dépôt git toutes les 10 minutes, l’oublie, puis accuse Claude Code »

• Le vrai problème, c’est que le double tiret du titre a été automatiquement converti en tiret demi-cadratin sur HN

  • En LaTeX, le double tiret sert pour le demi-cadratin, et le triple tiret pour le cadratin
  • Je pense aussi à l’origine qu’il faudrait garder le double tiret tel quel, mais si on suit la tradition de LaTeX et Typst, le demi-cadratin est plus approprié
  • Conseil de pro : copier-coller un titre HN tel quel dans la ligne de commande est dangereux
  • À l’origine, il fallait l’écrire avec deux tirets, comme dans « --hard »
  • La règle, c’est deux pour un demi-cadratin, trois pour un cadratin

• J’ai aussi enquêté directement sur ce problème, et Claude Code lui-même ne contient pas de code qui exécute git reset --hard origin/main
  Il est bien plus probable que le développeur ait lancé une commande comme /loop 10m ou créé une tâche cron qui réinitialise git toutes les 10 minutes

  • Il a peut-être cru qu’il s’agissait d’une fonction anodine du genre « synchroniser périodiquement avec le serveur »

• Il est difficile de croire qu’en surveillant les processus toutes les 0,1 seconde, aucun processus git n’ait été vu
  Les commandes git sont trop rapides pour être capturées à cet intervalle
  Il vaut mieux à la place envelopper git dans le $PATH pour journaliser toutes les exécutions

  • On dirait que Claude Code se mord la queue ici. Comme s’il avait échoué à déboguer le problème et essayait ensuite de créer lui-même un rapport de bug
    Il l’a peut-être même soumis de manière « agentique » sans intervention de l’utilisateur (pure spéculation)
    Lien vers l’issue
  • Dans ce genre de cas, eBPF est utile. Par exemple, le script execsnoop de bpftrace permet de suivre tous les processus exécutés sur le système

• Ce billet peut faire prendre à tort un problème individuel pour un problème de tout le système
  Il y a probablement eu une certaine corruption de contexte

  • Il m’est arrivé quelque chose de similaire plusieurs fois. Une fois, cela a même fini en force push sur GitHub
    Claude avait tout cassé dans l’ordre stash → remplacement via sed → conflit → reset --hard
    J’ai donc mis l’avertissement suivant tout en haut de CLAUDE.md
    « Interdiction des remplacements massifs avec sed, de git push --force, de git reset --hard et des autres commandes git destructrices »
    Depuis, ça va nettement mieux
  • Tu as peut-être raison. Mais si le contexte est corrompu à seulement 0,1 %, alors une tâche sur 1000 peut suffire à faire perdre des données
  • En réalité, ce genre de problème peut être totalement empêché avec des protections techniques.
    Si l’on met en place un hook qui bloque certaines commandes git, le comportement reste sûr indépendamment de l’incertitude prédictive du modèle
    Quand je vois ça, j’ai l’impression que beaucoup ont oublié un principe fondamental de l’ingénierie d’autrefois — des processus déterministes et reproductibles
  • Au final, les LLM font parfois des choses vraiment stupides. C’est tout

• J’ai eu un problème similaire moi aussi
  D’habitude, j’exécute claude-code dans un sandbox (bwrap, srt), mais si je le lance en dehors, il appelle gh chaque fois que je supprime /command ou que je ferme le menu
  Comme j’utilise KeepassXC comme gestionnaire de secrets, une fenêtre de validation apparaît à chaque fois, donc c’est immédiatement visible
  Quand j’ai demandé à Claude, il a répondu que la cause venait de la fonction de contexte git.
  Comme KeepassXC ne permet pas d’autorisation valable pour toute la session, cela finit par demander une authentification à chaque fois

• Je me demande si les paramètres d’autorisation ne sont pas censés empêcher ce genre de chose
  Mais comme l’utilisateur l’a lancé avec l’option --dangerously-skip-permissions, il faut s’attendre à des comportements imprévisibles

  • Cela dit, un hook pretooluse permettrait quand même de l’empêcher même avec cette option activée
  • En lisant la documentation d’Anthropic sur les permissions, on ne voit pas clairement comment ces permissions sont réellement appliquées.
    On peut même l’interpréter comme quelque chose qui pourrait être contourné par prompt injection
  • Exécuter ça sur un dépôt en production sans permissions, c’est s’exposer à un incident de suppression de données
    Une règle incapable d’empêcher un hard reset n’est qu’un affichage de façade
  • Les règles et permissions actuelles ne sont pas des drapeaux programmatiques, mais simplement du texte que l’agent « croit devoir respecter »

• Comme l’auteur l’a lui-même expliqué, la cause n’était pas Claude Code mais un bug dans son propre outil de test local

  • En d’autres termes, c’était un faux signalement
    Lien vers l’issue
  • L’expression « un outil que j’ai créé » est un peu ambiguë. C’était probablement un outil vibe-codé bricolé à la va-vite
  • En fait, ce ticket lui-même a peut-être été généré par le résultat de l’analyse de Claude Code (autrement dit, une hallucination)

• Il n’est pas surprenant que des outils de développement blob binaire en SaaS puissent produire ce genre de problèmes difficiles à déboguer

• Au final, c’est bien l’utilisateur qui a trouvé la cause, et son propre outil était à l’origine du problème
  Ce genre de chose arrivait déjà avant, et arrive encore aujourd’hui.
  Moi aussi, j’ai largement réussi à casser des choses tout seul, sans l’aide d’un LLM
  C’est pourquoi je développe toujours avec Time Machine sur Mac.
  Quand Claude a supprimé des fichiers et que macOS demande « Voulez-vous restaurer ? », on dirait presque que Claude est soulagé
  Les sauvegardes sont vraiment une bouée de sauvetage