Claude Code hat meine Dateien gelöscht? Die Schicht, die es stoppt

Wenn Claude Code Ihre Dateien gelöscht hat, kommt nur zurück, was noch an einem anderen Ort existiert. Damit Claude Code nicht wieder Dateien löscht, pushen Sie Ihre Arbeit und richten dann eine Deny-Regel und einen Hook ein. Diese Anleitung baut jede Schicht für Claude Code in etwa 30 Minuten auf und zeigt, was jede einzelne übersieht.

Wir betreiben einen Löschschutz in jeder Claude-Code-Session in unserem eigenen Repository. Die Beispiele nutzen Marrowby Tiles, einen erfundenen Fliesenhändler; die Regeln und Muster entsprechen unseren.

Claude Code hat Dateien gelöscht: Was zurückkommt

Der Rückweg entsteht vor dem Löschen, nie danach.

Gerade Dateien verloren? Gehen Sie in dieser Reihenfolge vor:

1. Sehen Sie im Ordner _archive/ des Projekts nach.
2. Führen Sie git status aus, um fehlende versionierte Dateien aufzulisten.
3. Committet, aber nicht gepusht? git restore --source=HEAD --staged --worktree <path> holt die Datei aus Ihrem letzten lokalen Commit zurück.
4. Führen Sie git fetch und dann git restore --source=origin/main <path> aus, um eine Datei im zuletzt gepushten Stand zurückzuholen (setzen Sie den Namen Ihres Branches ein).
5. Hat ein Commit die Datei entfernt, nennt git log --diff-filter=D -- <path> diesen Commit.

Was diese Schritte nicht finden, ist von der Festplatte verschwunden.

Warum Claude Code Dateien löscht

Eine Rückfrage schützt die Person an der Tastatur. Für einen Lauf um 3 Uhr nachts tut sie nichts.

Agenten löschen aus ganz gewöhnlichen Gründen: Bittet man Claude Code, „neu anzufangen“, leert es zuerst den Ordner, und in unserem Test in einem Wegwerfordner wählte es von sich aus find -delete. Auch Git löscht: git reset --hard, git clean, git restore, git checkout -- und git stash drop verwerfen nicht committete Arbeit, und ein einfaches git stash versteckt sie, bis Sie sie mit git stash pop zurückholen.

Die Bestätigungsabfrage ist die schwächste Schicht. Menschen bestätigen, was sie nur überfliegen, und unsere geplanten Agentenläufe nutzen --dangerously-skip-permissions, sodass gar keine Abfrage erscheint.

Sehen Sie, wie ConvOps vor jeden Merge einen Freigabeschritt setzt(wird in einem neuen Tab geöffnet), damit eine Löschung aus einem unbeaufsichtigten Lauf main nie ohne das Ja einer Person erreicht.

Welche Schicht eine Löschung wirklich stoppt

Die Deny-Liste ist eine Bremsschwelle. Der Hook ist eine Mauer mit bekannten Lücken. Gepushte Arbeit ist das Fundament.

Was ist eine Deny-Regel? Eine Deny-Regel ist eine Zeile in den Einstellungen von Claude Code, die jeden Bash-Befehl ablehnt, dessen Text auf ein Muster passt, etwa Bash(rm *).

Was ist ein PreToolUse-Hook? Ein PreToolUse-Hook ist ein Skript, das Claude Code vor einem Tool-Aufruf ausführt; endet das Skript mit Exit-Code 2, wird der Aufruf blockiert und der Agent liest die Meldung des Skripts.

Vier Schichten liegen zwischen der Löschung eines Agenten und Ihren Dateien, und nur die Bestätigungsabfrage entfällt, wenn niemand zusieht.

Eine Deny-Regel und ein Hook blockierten in unseren Testläufen jeweils für sich allein rm. Keine der beiden stoppte alles.

Jede Schicht lässt für sich allein etwas durch, eine Löschung per find -delete an der Deny-Regel vorbei und einen Python-Einzeiler am Hook vorbei, und die nächste Schicht fängt es ab.

Committen und pushen, bevor ein Agent etwas anfasst

Ungepushte Arbeit geht mit dem Ordner verloren, in dem sie liegt.

Bevor Sie Claude Code starten, sichern Sie alles auf dem Remote:

git status
git add src/ data/products.json
git commit -m "Save work before the agent run"
git push

Starten Sie den Agenten nur auf einem sauberen Arbeitsverzeichnis, das mit dem Remote auf dem aktuellen Stand ist. Unsere Workflows pushen das Ergebnis jedes Schritts, bevor sie weitergehen, und ein Stop-Hook verhindert, dass eine Session mit ungepushter Arbeit endet. Führen Sie riskante Arbeit in einem Git-Worktree aus, etwa ~/marrowby-shop-run-0412, oder in einem isolierten Lauf, der vom Remote startet.

Deny-Regeln in Claude Code anlegen

Deny-Regeln prüfen den Text eines Befehls, nicht das, was der Befehl tut.

Dieser Block gehört in die .claude/settings.json des Projekts:

{
  "permissions": {
    "deny": [
      "Bash(rm *)",
      "Bash(rmdir *)",
      "Bash(git rm *)",
      "Bash(git clean *)",
      "Bash(git reset *)",
      "Bash(git restore *)",
      "Bash(git checkout -- *)",
      "Bash(git stash drop *)",
      "Bash(git stash clear *)",
      "Bash(git push --force *)",
      "Bash(git push -f *)"
    ]
  }
}

Bash(rm *) und das ältere Bash(rm:*) verhielten sich in Version 2.1.295 gleich, auch unter --dangerously-skip-permissions. Laut Anthropics Dokumentation zu den Berechtigungsmodi(wird in einem neuen Tab geöffnet) blockieren Deny-Regeln „in jedem Modus, einschließlich bypassPermissions“, und der Auto-Modus zählt dort zu diesen Modi. Die Dokumentation zu Berechtigungen(wird in einem neuen Tab geöffnet) hält außerdem fest, dass eine Deny-Regel „keine Sicherheitsgrenze um das Programm“ ist. In unserem Lauf löschten find -delete, /bin/rm und ein python3 -c-Einzeiler jeweils die Datei; sh -c 'rm ...' wurde abgefangen.

Einen Hook einrichten, der blockiert und einen Ausweg nennt

Eine Blockade ohne Alternative bringt dem Agenten bei, Sie zu umgehen.

Die vollständige .claude/settings.json mit einem hooks-Schlüssel neben permissions (Hooks-Leitfaden(wird in einem neuen Tab geöffnet)):

{
  "permissions": {
    "deny": [
      "Bash(rm *)",
      "Bash(rmdir *)",
      "Bash(git rm *)",
      "Bash(git clean *)",
      "Bash(git reset *)",
      "Bash(git restore *)",
      "Bash(git checkout -- *)",
      "Bash(git stash drop *)",
      "Bash(git stash clear *)",
      "Bash(git push --force *)",
      "Bash(git push -f *)"
    ]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "python3",
            "args": ["${CLAUDE_PROJECT_DIR}/.claude/hooks/delete-guard.py"],
            "timeout": 5
          }
        ]
      }
    ]
  }
}

${CLAUDE_PROJECT_DIR} zeigt auf das Projektverzeichnis, sodass der Pfad auch dann stimmt, wenn der Agent den Ordner wechselt. Ein falscher Skriptpfad lässt python3 mit Exit-Code 2 enden, sodass jeder Bash-Aufruf mit dem Fehler can't open file blockiert wird. Im Fehlerfall wird also blockiert statt durchgelassen, und schon der erste Befehl zeigt es.

Und das Skript, .claude/hooks/delete-guard.py:

import json, re, sys

ARCHIVE = ("file deletion is denied, archive instead: move it to _archive/ "
           "in this project (mkdir -p _archive && mv <path> _archive/)")
PATTERNS = [
    (r"\brm\s+-rf\b", "rm -rf is irreversible recursive deletion, " + ARCHIVE),
    (r"(?<!-)\brm\b", ARCHIVE),
    (r"\brmdir\b", ARCHIVE),
    (r"\bfind\b.*\s-delete\b", ARCHIVE),
    (r"\bgit\s+checkout\s+--\s+", "git checkout -- reverts uncommitted work"),
    (r"\bgit\s+reset\b", "git reset can destroy commit history"),
    (r"\bgit\s+restore\b", "git restore reverts uncommitted work"),
    (r"\bgit\s+clean\b", "git clean deletes untracked files"),
    (r"\bgit\s+stash\b", "git stash can drop uncommitted work"),
    (r"\bgit\s+push\b.*\s(?:-f|--force)\b", "force push overwrites remote history"),
]
MESSAGE_ARG = re.compile(r"""(?:^|\s)(?:-m|--message)(?:=|\s+)(?:"[^"]*"|'[^']*'|\S+)""")

def main():
    try:
        command = json.load(sys.stdin)["tool_input"]["command"]
    except Exception:
        return 0
    scanned = MESSAGE_ARG.sub(" ", command)
    for pattern, reason in PATTERNS:
        if re.search(pattern, scanned):
            print(f"BLOCKED: Destructive command detected.\n  Reason: {reason}\n"
                  f"  Command: {command}", file=sys.stderr)
            return 2
    return 0

sys.exit(main())

Jede Zeile hat einen Grund:

• Exit-Code 2 blockiert den Aufruf; der Agent liest stderr.
• (?<!-)\brm\b erfasst jedes rm-Token, auch /bin/rm. Der Lookbehind lässt docker run --rm weiterhin zu.
• Nicht lesbare Eingaben enden mit 0: So legen sie nie eine Session lahm, bleiben aber ungeprüft.
• Kein Muster für Interpreter. Einzeiler mit os.remove und shutil.rmtree kommen durch: Der Hook blockiert nur, was seine Muster benennen.

Ein Hook läuft bei jedem Bash-Aufruf, ganz gleich, was man dem Agenten gesagt hat (Graph Engineering). Deshalb gehört eine solche Regel in einen Hook und nicht in eine CLAUDE.md, die immer weiter wächst.

Den Hook testen, bevor Sie ihm vertrauen

Ein ungetesteter regulärer Ausdruck ist eine Vermutung.

Leiten Sie eine Beispiel-Payload in das Skript:

echo '{"tool_name":"Bash","tool_input":{"command":"find exports -mindepth 1 -delete"}}' \
  | python3 .claude/hooks/delete-guard.py; echo "exit $?"

Legen Sie für jede Befehlsform eine Fixture an, auch für erwartete Lücken:

Schließen Sie mit einer echten Blockade ab: Bitten Sie Claude Code in einem Wegwerfordner, eine Testdatei zu löschen.

Ein Löschversuch, Schritt für Schritt verfolgt

Die beste Blockade ist die, von der sich der Agent selbst erholt.

Der Hook blockiert die Löschung des Agenten per find -delete mit Exit-Code 2, seine Meldung nennt den Ordner _archive/ des Projekts, und der Agent verschiebt die Dateien stattdessen dorthin, sodass nichts gelöscht wird.

1. Auslöser. Marrowby Tiles gibt den Auftrag: „Produkt-Feed-Export neu erzeugen, komplett von vorn.“ Der Agent führt find exports -mindepth 1 -delete aus (Markierung 1).
2. Blockade. Der Hook erkennt \bfind\b.*\s-delete\b und endet mit Exit-Code 2; seine Meldung nennt _archive/ in diesem Projekt (Markierung 2).
3. Umleitung. Der Agent führt mkdir -p _archive && mv exports/* _archive/ aus (Markierung 3).
4. Ergebnis. 2 Elemente verschoben, 0 gelöscht: _archive/product-feed.csv und _archive/old/ (Markierung 4).

Was bei einem Löschschutz schiefgeht

Wir erklären lieber eine unnötige Blockade, als einen Ordner wiederherzustellen.

Eine reine Lesesuche nach „rm -rf“ wird blockiert, weil der Hook Text abgleicht, und diesen Fehlalarm behalten wir bewusst: Eine unnötige Blockade ist besser als eine übersehene Löschung.

Vier Fehler, auf die wir gestoßen sind, jeweils mit ihrer Regel:

• Eine Suche wurde blockiert. Ein reines Lese-grep -rn "rm -rf" scripts/ schlug an. Regel: den Fehlalarm behalten (im Zweifel blockieren), ebenso seine Fixture.
• Commit-Nachrichten lösten den Hook aus. „Never rm -rf exports“ wurde wie ein Befehl erkannt. Regel: -m- und --message-Argumente in Anführungszeichen vorher herausfiltern.
• Der Archivpfad verließ das Projekt. Unsere Blockademeldung nannte einen Ordner im Wurzelverzeichnis unseres Repositorys, und ein Testagent in einem anderen Projekt verschob seine Dateien dorthin. Regel: _archive/ in diesem Projekt nennen.
• Ein Git-Befehl vernichtete Arbeit. git checkout -- auf zwei Ordnern löschte nicht committete Arbeit. Regel: auch die Löschbefehle von Git per Deny-Regel und Hook sperren.

Wenn niemand zusieht

Rückfragen sind keine Kontrolle für unbeaufsichtigte Läufe. Gates und Isolation sind es.

Unsere unbeaufsichtigten Läufe überspringen Rückfragen absichtlich. Drei Kontrollen tragen sie:

Unsere Workflows halten dort für eine Freigabe an, wo das Risiko liegt (Human in the Loop), und unsere Reparaturschleife für die Website läuft in einer isolierten Umgebung.

Kopieren Sie den Deny-Block und den Hook noch heute. Führen Sie Ihre unbeaufsichtigten Agenten-Jobs dann als ConvOps-Tasks aus(wird in einem neuen Tab geöffnet), mit einem Freigabeschritt vor dem Merge und einem isolierten Lauf.

Derselbe Schutz in OpenCode und Kimi Code CLI

Ein Schutzprinzip, drei Dateien.

Wir haben diesen Schutz in Testprojekten geprüft; im Alltag läuft unser Schutz in Claude Code.

Dieselbe Löschprüfung vor der Ausführung steckt in der jeweils eigenen Datei jedes Tools: ein PreToolUse-Hook in Claude Code, ein tool.execute.before-Plugin in OpenCode und ein hooks-Eintrag in Kimi Code CLI.

OpenCode 1.18.31

In OpenCode stoppten Deny-Regeln in permission.bash zwar rm und find -delete, doch dann löschte der Agent mit einem Python-Einzeiler. Ein Plugin, .opencode/plugins/delete-guard.js, prüft jeden bash-Befehl in tool.execute.before, mit os.remove und shutil.rmtree unter seinen Mustern, und wirft eine Meldung, die _archive/ nennt. Es blockierte alle sechs Formen, die wir ausprobierten, und der Agent archivierte stattdessen. opencode run --pure überspringt Plugins, den Schutz eingeschlossen.

Kimi Code CLI 0.31.1

Kimi Code CLI (es betreibt Modelle wie Kimi K3) nimmt einen PreToolUse-Hook in ~/.kimi-code/config.toml auf:

[[hooks]]
event = "PreToolUse"
matcher = "Bash"
command = "node ~/.kimi-code/hooks/delete-guard.mjs"

Das Skript endet mit Exit-Code 2 und derselben Meldung und blockierte im yolo-Modus alle sechs Formen. Hooks stehen nur in der Benutzerkonfiguration, nie im Projekt. Die native Regel Bash(rm *) griff nie bei einem Pfad mit Schrägstrich; Bash(rm */**) greift.

Ganz gleich, welches Tool Sie verwenden, die Reihenfolge bleibt dieselbe: pushen, sperren, Hook einrichten, testen.