Problem, dass Claude Code im Projekt-Repository alle 10 Minuten `git reset --hard origin/main` ausführt

 (github.com/anthropics)
3 Punkte von GN⁺ 2026-03-31 | 1 Kommentare | Auf WhatsApp teilen
  • Es wurde ein Verhalten unter macOS gemeldet, bei dem Änderungen im Projekt alle 10 Minuten automatisch gelöscht wurden.
  • Die Untersuchung ergab, dass die Ursache nicht Claude Code war, sondern ein vom Nutzer erstelltes separates lokales Automatisierungstool, das über GitPython periodisch git reset --hard origin/main ausführte.
  • Weil beide dasselbe Arbeitsverzeichnis nutzten, sah es so aus, als sei Claude Code die Ursache; tatsächlich führte jedoch ein externes Skript den Reset aus.
  • Das Claude-Code-Team stellte klar, dass es in der internen Codebasis keine Logik zum Ausführen dieses Befehls gibt, und erklärte, dass ein ähnliches Verhalten nur bei Verwendung der Option --dangerously-skip-permissions möglich ist.
  • Abschließend wurde festgestellt, dass es sich nicht um einen Bug in Claude Code, sondern um ein Problem mit einem Nutzertool handelte; der Titel wurde geändert und das Issue geschlossen.

Problembild und Umgebung

  • Es wurde beobachtet, dass Claude Code im Projekt-Repository des Nutzers alle 10 Minuten git fetch origin und git reset --hard origin/main ausführt.
  • Dieses Verhalten löscht sämtliche nicht committeten Änderungen an verfolgten Dateien; nicht verfolgte Dateien bleiben erhalten.
  • In einer Git-worktree-Umgebung tritt ein solcher Reset nicht auf.
  • Umgebungsinformationen
    • Claude-Code-Version: 2.1.87 (Homebrew-Cask, Bun-Binärdatei)
    • OS: macOS 15.4 (Darwin 25.3.0, arm64)
    • Shell: zsh

Untersuchungsverlauf

  • Im Git-Reflog wurden mehr als 95 Einträge von reset: moving to origin/main im Abstand von 10 Minuten protokolliert.
    • Der Offset war je nach Sitzung unterschiedlich, innerhalb einer Sitzung wiederholte sich das Muster jedoch exakt alle 600 Sekunden.
  • In einem Echtzeit-Reproduktionstest wurde eine verfolgte Datei (api.ts) beim Reset auf den ursprünglichen Zustand zurückgesetzt, während eine nicht verfolgte Datei (.canary-test.txt) unverändert blieb.
  • Bei der Überwachung des .git/-Verzeichnisses mit fswatch wurde zum Zeitpunkt des Resets ein Muster erkannt, bei dem .git/refs und .git/logs/HEAD geändert wurden.
  • Laut lsof war der Claude-Code-CLI-Prozess der einzige Prozess, der dieses Repository als CWD verwendete.
  • Da keine externen Git-Prozesse erkannt wurden, wurde vermutet, dass die Ausführung intern über libgit2 oder Ähnliches erfolgte.
  • In einer worktree-Umgebung blieben Reset-Einträge im Reflog vollständig aus.

Ausgeschlossene Ursachen

  • Git-Hooks, Claude-Code-Benutzer-Hooks, Plugin-Updates, macOS-Cloud-Synchronisierung, Cron/LaunchAgents, IDEs, Time Machine und Dateiüberwachungstools wurden sämtlich als nicht ursächlich bestätigt.
  • Jeder dieser Punkte wurde durch Prüfung der tatsächlichen Konfigurationsdateien und Prozesse ausgeschlossen.

Binäranalyse (teilweise)

  • Ein Teil der Funktionen in der Claude-Code-Binärdatei enthält Codefragmente, die den Befehl ["fetch","origin"] ausführen.
  • Es gibt eine Wrapper-Funktion für git pull sowie Logik zur Verwaltung des fileHistory-Status, jedoch wurde kein Timer mit 10-Minuten-Intervall identifiziert.

Auswirkungen

  • Nicht committete Änderungen wurden alle 10 Minuten automatisch gelöscht, sodass in einer zweistündigen Sitzung Änderungen mindestens dreimal verloren gingen.
  • Wenn alle Änderungen bereits committet waren, hatte der Reset keine praktische Auswirkung, weshalb das Problem nur sporadisch sichtbar erschien.

Antwort des Claude-Code-Teams

  • Jarred-Sumner erklärte ausdrücklich: „Claude Code selbst enthält keinen Code, der git reset --hard origin/main ausführt.“
  • Bei Verwendung der Option --dangerously-skip-permissions kann Claude ohne Rückfrage Shell-Befehle ausführen; wenn der Befehl /loop 10m <prompt> periodisch eine „Synchronisierung mit dem Remote“ anfordert, kann git fetch && git reset --hard origin/main ausgeführt werden.
  • Als Prüfmethoden wurden genannt:
    1. grep -r "reset --hard" ~/.claude/projects/ zum Durchsuchen der Sitzungslogs
    2. claude --debug-file /tmp/debug.txt --dangerously-skip-permissions ausführen, 10 Minuten warten und dann grep -i bash /tmp/debug.txt | grep reset ausführen
  • Die fileHistory-Funktion von Claude Code hat nichts mit Git zu tun und ruft intern kein git reset auf.

Endgültige Schlussfolgerung

  • In einem Update vom 30. März 2026 wurde bestätigt, dass die eigentliche Ursache des Problems nicht Claude Code, sondern ein separates lokales Tool des Nutzers war.
  • Dieses Tool verwendete GitPython, um alle 10 Minuten einen Hard Reset auszuführen, und überwachte dabei dasselbe Verzeichnis wie Claude Code.
  • Das Issue wurde mit dem Status „not planned“ geschlossen, und der Titel wurde von „Claude Code führt einen Reset aus“ in „Mein Automatisierungstool führt einen Reset aus“ geändert.

Vorläufige Workarounds

  • Bei Verwendung von git worktree gibt es keine Auswirkungen durch den Reset.
  • Durch häufiges Committen lassen sich Änderungen schützen.

Verwandte Issues

  • #8072 — Problem, bei dem Codeänderungen wiederholt zurückgesetzt werden
  • #7232 — Datenverlust durch Ausführung von git reset --hard ohne Freigabe
  • #32793 — Problem, bei dem der Befehl claude install die Git-Remote-URL falsch ändert (ähnlicher, aber separater Fall)

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-31
Hacker-News-Kommentare

  • Das ist ein Update vom Autor selbst.
    Laut dem Issue-Link war die eigentliche Ursache des Problems nicht Claude Code, sondern ein Bug in einem vom Autor für lokale Tests gebauten Tool.
    Dieses Tool führte bei jedem Zyklus einen Hard Reset aus, um das lokale Arbeitsverzeichnis mit dem Remote zu synchronisieren, und löschte dabei alle nicht committeten Änderungen.

    • Schon lustig, dass der Autor angeblich so viel „untersucht“ hat, aber nicht auf die Idee kam, Claude einfach mal 10 Minuten auszuschalten.
      Wenn man den Titel in etwa zu „Entwickler erstellt ein Skript, das alle 10 Minuten das Git-Repo zurücksetzt, vergisst es und gibt dann Claude Code die Schuld“ ändern würde, würde ich die Markierung zurücknehmen.

  • Das eigentliche Problem ist, dass der doppelte Bindestrich im Titel auf HN automatisch in einen en dash umgewandelt wurde.

    • In LaTeX steht ein doppelter Bindestrich für einen en dash, ein dreifacher für einen em dash.
    • Ich denke zwar auch, dass man den doppelten Bindestrich eigentlich so stehen lassen sollte, aber nach der Tradition von LaTeX und Typst ist ein en dash passender.
    • Pro-Tipp: Es ist riskant, HN-Titel direkt zu kopieren und in die Kommandozeile einzufügen.
    • Eigentlich müsste es mit zwei Bindestrichen wie in „--hard“ geschrieben werden.
    • Es gibt die Regel: zwei für en dash, drei für em dash.

  • Ich habe das Problem auch selbst untersucht, und in Claude Code selbst gibt es keinen Code, der git reset --hard origin/main ausführt.
    Wahrscheinlich hat der Entwickler einen Befehl wie /loop 10m laufen lassen oder einen Cron-Job eingerichtet, der alle 10 Minuten Git zurücksetzt.

    • Vielleicht hielt man das für eine harmlose Funktion wie „regelmäßig mit dem Server synchronisieren“.

  • Dass man Prozesse im Abstand von 0,1 Sekunden überwacht hat und dabei keinen Git-Prozess sah, ist schwer glaubwürdig.
    Git-Befehle sind so schnell, dass man sie in diesem Intervall leicht verpasst.
    Besser ist es, git im $PATH zu wrappen und jede Ausführung mitzuprotokollieren.

    • Das wirkt wie ein Fall, in dem Claude Code seinem eigenen Schwanz hinterherjagt. Als ob es beim Debugging gescheitert wäre und nun selbst einen Bug-Report erstellen wollte.
      Vielleicht wurde er sogar ohne Eingabe des Nutzers „agentisch“ eingereicht, aber das ist reine Spekulation.
      Issue-Link
    • In solchen Fällen ist eBPF nützlich. Mit dem execsnoop-Skript von bpftrace kann man zum Beispiel alle Prozesse verfolgen, die auf dem System gestartet werden.

  • Dieser Beitrag kann dazu führen, dass ein Problem einer einzelnen Person als Problem des Gesamtsystems missverstanden wird.
    Wahrscheinlich gab es eine gewisse Beschädigung des Kontexts.

    • Ich habe etwas Ähnliches auch schon ein paar Mal erlebt. Einmal endete es sogar in einem Force Push auf GitHub.
      Claude hat es mit stash → sed-Ersetzung → Konflikt → reset --hard kaputtgemacht.
      Deshalb habe ich ganz oben in CLAUDE.md folgende Warnung notiert:
      „Keine Massenersetzungen mit sed, git push --force, git reset --hard und andere destruktive Git-Befehle strikt verboten.“
      Seitdem ist es deutlich besser geworden.
    • Du könntest recht haben. Aber wenn der Kontext nur zu 0,1 % beschädigt ist, kann in einer von 1000 Aufgaben schon ein Datenverlust passieren.
    • Eigentlich lässt sich so etwas durch technische Schutzmechanismen vollständig verhindern.
      Wenn man einen Hook einbaut, der bestimmte Git-Befehle blockiert, funktioniert das sicher unabhängig von der Vorhersageunsicherheit des Modells.
      Bei so etwas denke ich oft, dass viele die alten Grundprinzipien des Engineerings vergessen haben — deterministische und reproduzierbare Prozesse.
    • Letztlich machen LLMs manchmal einfach wirklich dumme Sachen. Das ist alles.

  • Ich hatte ein ähnliches Problem auch schon.
    Normalerweise lasse ich claude-code in einer Sandbox (bwrap, srt) laufen, aber wenn ich es außerhalb starte, ruft es jedes Mal gh auf, wenn ich /command lösche oder ein Menü schließe.
    Ich nutze KeepassXC als Secret Manager, deshalb fällt es sofort auf, weil jedes Mal ein Freigabe-Popup erscheint.
    Als ich Claude fragte, sagte es, die Ursache sei die Git-Context-Funktion.
    Da KeepassXC keine sitzungsweite Freigabe erlaubt, wird dadurch jedes Mal erneut eine Authentifizierung verlangt.

  • Man sollte meinen, dass sich so etwas durch Berechtigungen verhindern lässt.
    Aber der Nutzer hat es mit der Option --dangerously-skip-permissions ausgeführt, also muss man mit unvorhersehbarem Verhalten rechnen.

    • Mit einem pretooluse hook lässt sich das aber selbst mit aktivierter Option verhindern.
    • Wenn man die Permissions-Dokumentation von Anthropic liest, bleibt unklar, wie die Berechtigungen tatsächlich durchgesetzt werden.
      Man könnte es auch so lesen, dass sie sich per Prompt Injection umgehen lassen.
    • Ohne Berechtigungen in einem Live-Repo zu arbeiten, lädt Datenlöschvorfälle geradezu ein.
      Regeln, die nicht einmal einen Hard Reset verhindern können, sind reine Show.
    • Die aktuellen Regeln und Berechtigungen sind keine Programm-Flags, sondern lediglich Text, von dem der Agent „glaubt“, dass er ihn befolgen soll.

  • Wie der Autor selbst erklärte, war die Ursache nicht Claude Code, sondern ein Bug in einem selbst gebauten lokalen Test-Tool.

    • Also ein Fehlalarm.
      Issue-Link
    • Die Formulierung „ein von mir gebautes Tool“ ist etwas vage. Vermutlich war es ein schnell zusammengeschustertes vibe-coded Tool.
    • Eigentlich könnte sogar dieses Ticket selbst durch das Analyseergebnis von Claude Code entstanden sein, also durch eine Halluzination.

  • Es ist nicht überraschend, dass man solche schwer zu debuggenden Probleme bekommt, wenn man ein SaaS-basiertes Binary-Blob-Entwicklungswerkzeug benutzt.

  • Am Ende hat der Nutzer die Ursache selbst herausgefunden, und sein eigenes Tool war der Auslöser.
    So etwas gab es schon früher und gibt es auch heute noch.
    Ich habe auch schon oft genug ganz ohne Hilfe eines LLM eigenhändig Schaden angerichtet.
    Deshalb entwickle ich immer mit Time Machine auf dem Mac.
    Wenn Claude eine Datei gelöscht hat und dann „Soll sie wiederhergestellt werden?“ erscheint, wirkt es fast so, als wäre Claude erleichtert.
    Backups sind wirklich die Lebensader.