Claude Code a supprimé mes fichiers ? La couche qui l'en empêche

Si Claude Code a supprimé vos fichiers, seul ce qui existe ailleurs revient. Pour empêcher Claude Code de supprimer à nouveau des fichiers, poussez votre travail, puis ajoutez une règle de refus et un hook. Ce guide met en place chaque couche pour Claude Code en 30 minutes environ et montre ce que chacune laisse passer.

Nous faisons tourner une protection contre la suppression sur chaque session Claude Code de notre propre dépôt. Les exemples utilisent Marrowby Tiles, un magasin de carrelage fictif ; les règles et les motifs reprennent les nôtres.

Claude Code a supprimé des fichiers : ce qui revient

Le chemin du retour se construit avant la suppression, jamais après.

Vous venez de perdre des fichiers ? Procédez dans cet ordre :

1. Regardez dans le dossier _archive/ du projet.
2. Lancez git status pour lister les fichiers suivis manquants.
3. Commité mais pas poussé ? git restore --source=HEAD --staged --worktree <path> le récupère depuis votre dernier commit local.
4. Lancez git fetch, puis git restore --source=origin/main <path> pour récupérer un fichier dans son dernier état poussé (remplacez main par le nom de votre branche).
5. Si un commit a supprimé le fichier, git log --diff-filter=D -- <path> indique ce commit.

Tout ce qui échappe à ces étapes a disparu du disque.

Pourquoi Claude Code supprime des fichiers

Une demande d'approbation protège la personne devant le clavier. Elle ne fait rien pour une exécution à 3 h du matin.

Les agents suppriment pour des raisons banales : quand on lui demande de « repartir de zéro », Claude Code vide d'abord le dossier, et lors de notre test dans un dossier jetable, il a choisi find -delete de lui-même. Git supprime aussi : git reset --hard, git clean, git restore, git checkout -- et git stash drop jettent le travail non commité, et un simple git stash le cache jusqu'à ce que vous le récupériez.

La demande d'approbation est la couche la plus faible. On approuve ce qu'on survole, et nos exécutions planifiées d'agents utilisent --dangerously-skip-permissions : aucune demande n'apparaît.

Découvrez comment ConvOps place une étape de validation avant chaque merge(s’ouvre dans un nouvel onglet) : une suppression faite pendant une exécution sans surveillance n'atteint jamais main sans le feu vert d'une personne.

Quelle couche arrête vraiment une suppression

La liste de refus est un ralentisseur. Le hook est un mur aux failles connues. Le travail poussé est le socle.

Qu'est-ce qu'une règle de refus ? Une règle de refus (deny) est une ligne des paramètres de Claude Code qui refuse toute commande Bash dont le texte correspond à un motif, comme Bash(rm *).

Qu'est-ce qu'un hook PreToolUse ? Un hook PreToolUse est un script que Claude Code exécute avant un appel d'outil ; quand le script se termine avec le code 2, l'appel est bloqué et l'agent lit le message du script.

Quatre couches séparent la suppression lancée par un agent de vos fichiers, et seule la demande d'approbation saute quand personne ne regarde.

Lors de nos tests dans des dossiers jetables, une règle de refus et un hook ont chacun bloqué rm à eux seuls. Aucun des deux n'a tout arrêté.

Chaque couche, seule, laisse passer quelque chose : une suppression par find passe la règle de refus, un one-liner Python passe le hook, et la couche suivante prend le relais.

Commiter et pousser avant que l'agent ne touche à quoi que ce soit

Le travail non poussé meurt avec le dossier qui le contient.

Avant de lancer Claude Code, enregistrez tout sur le dépôt distant :

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

Ne lancez l'agent que sur une arborescence propre et à jour avec le dépôt distant. Nos workflows poussent le résultat de chaque étape avant de passer à la suivante, et un hook d'arrêt empêche de clore une session qui laisse du travail non poussé. Exécutez le travail risqué dans un worktree git, comme ~/marrowby-shop-run-0412, ou dans une exécution isolée qui part du dépôt distant.

Ajouter des règles de refus à Claude Code

Les règles de refus comparent le texte de la commande, pas ce que fait la commande.

Ce bloc va dans le fichier .claude/settings.json du projet :

{
  "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 *) et l'ancienne forme Bash(rm:*) se sont comportées de la même façon sur la 2.1.295, même avec --dangerously-skip-permissions. La documentation des modes de permission(s’ouvre dans un nouvel onglet) d'Anthropic indique que les règles de refus « bloquent dans tous les modes, y compris bypassPermissions », et range le mode auto parmi ces modes. La documentation des permissions(s’ouvre dans un nouvel onglet) précise aussi qu'une règle de refus « n'est pas une frontière de sécurité autour du programme ». Lors de notre test, find -delete, /bin/rm et un one-liner python3 -c ont chacun supprimé le fichier ; sh -c 'rm ...' a été intercepté.

Ajouter un hook qui bloque et propose une issue

Un blocage sans alternative apprend à l'agent à vous contourner.

Le fichier .claude/settings.json complet, avec une clé hooks à côté de permissions (guide des hooks(s’ouvre dans un nouvel onglet)) :

{
  "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} pointe vers la racine du projet, si bien que le chemin reste valable quand l'agent change de dossier. Un mauvais chemin de script fait sortir python3 avec le code 2 : chaque appel Bash est alors bloqué avec une erreur can't open file. Le blocage se fait donc par défaut (fail closed), et la première commande le révèle.

Et le script, .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())

Chaque ligne a sa raison d'être :

• Le code de sortie 2 bloque l'appel ; l'agent lit stderr.
• (?<!-)\brm\b intercepte tout jeton rm, /bin/rm compris. Le lookbehind laisse passer docker run --rm.
• Une entrée illisible sort avec 0 : elle ne bloque jamais une session, et elle passe sans contrôle.
• Aucun motif pour les interpréteurs. Les one-liners os.remove et shutil.rmtree passent : le hook ne bloque que ce que ses motifs nomment.

Un hook s'exécute à chaque appel Bash, quelle que soit la consigne donnée à l'agent (graph engineering). C'est pourquoi une règle comme celle-ci a sa place dans un hook, et non dans un CLAUDE.md qui ne cesse de grossir.

Tester le hook avant de s'y fier

Une regex non testée n'est qu'une supposition.

Envoyez un exemple de payload au script :

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

Ajoutez un cas de test par forme, y compris les ratés attendus :

Terminez par un blocage en conditions réelles : dans un dossier jetable, demandez à Claude Code de supprimer un fichier sans importance.

Une tentative de suppression, retracée

Le meilleur blocage est celui dont l'agent se remet seul.

Le hook bloque la suppression par find de l'agent avec le code 2, son message nomme le dossier _archive/ du projet, et l'agent y déplace les fichiers à la place : rien n'est supprimé.

1. Déclencheur. Marrowby Tiles demande : « Régénérez l'export du flux produits, en repartant de zéro. » L'agent lance find exports -mindepth 1 -delete (repère 1).
2. Blocage. Le hook détecte \bfind\b.*\s-delete\b et sort avec le code 2 ; son message nomme _archive/ dans ce projet (repère 2).
3. Redirection. L'agent lance mkdir -p _archive && mv exports/* _archive/ (repère 3).
4. Verdict. 2 éléments déplacés, 0 supprimé : _archive/product-feed.csv et _archive/old/ (repère 4).

Ce qui tourne mal avec une protection contre la suppression

Nous préférons expliquer un faux blocage plutôt que restaurer un dossier.

Une recherche en lecture seule de « rm -rf » est bloquée parce que le hook compare du texte, et nous gardons ce faux positif exprès : mieux vaut un faux blocage qu'une suppression non détectée.

Quatre échecs que nous avons rencontrés, chacun avec sa règle :

• Une recherche a été bloquée. Un grep -rn "rm -rf" scripts/ en lecture seule a déclenché le motif. Règle : garder le faux positif (fail closed) et son cas de test.
• Des messages de commit ont déclenché le hook. « Never rm -rf exports » a été détecté comme une commande. Règle : retirer d'abord les arguments -m et --message entre guillemets.
• Le chemin d'archive sortait du projet. Notre message de blocage nommait un dossier à la racine de notre dépôt, et un agent de test dans un autre projet y a déplacé ses fichiers. Règle : nommer _archive/ dans ce projet.
• Une commande git a effacé du travail. git checkout -- sur deux dossiers a effacé du travail non commité. Règle : refuser et intercepter aussi les commandes git qui suppriment.

Quand personne ne regarde

Les demandes d'approbation ne protègent pas les exécutions sans surveillance. Les validations et l'isolation, si.

Nos exécutions sans surveillance sautent volontairement les demandes d'approbation. Trois contrôles les encadrent :

Nos workflows s'arrêtent pour une validation là où se trouve le risque (humain dans la boucle), et notre boucle de réparation du site tourne dans un environnement isolé.

Copiez le bloc de refus et le hook dès aujourd'hui. Ensuite, exécutez vos traitements d'agent sans surveillance sous forme de tâches ConvOps(s’ouvre dans un nouvel onglet), avec une étape de validation avant le merge et une exécution isolée.

La même protection dans OpenCode et Kimi Code CLI

Une seule forme de protection, trois fichiers.

Nous avons testé cette protection dans des projets jetables ; notre protection au quotidien tourne dans Claude Code.

La même vérification avant exécution se trouve dans le fichier propre à chaque outil : un hook PreToolUse dans Claude Code, un plugin tool.execute.before dans OpenCode et une entrée hooks dans Kimi Code CLI.

OpenCode 1.18.31

Dans OpenCode, les règles de refus de permission.bash ont arrêté rm et find -delete, puis l'agent a supprimé avec un one-liner Python. Un plugin, .opencode/plugins/delete-guard.js, vérifie chaque commande bash dans tool.execute.before, avec os.remove et shutil.rmtree parmi ses motifs, et lève une erreur dont le message nomme _archive/. Il a bloqué les six formes que nous avons essayées, et l'agent a archivé à la place. opencode run --pure ignore les plugins, protection comprise.

Kimi Code CLI 0.31.1

Kimi Code CLI (qui fait tourner des modèles comme Kimi K3) accepte un hook PreToolUse dans ~/.kimi-code/config.toml :

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

Le script sort avec le code 2 et le même message et, en mode yolo, a bloqué les six formes. Les hooks se trouvent uniquement dans la configuration utilisateur, jamais dans le projet. La règle native Bash(rm *) n'a jamais intercepté un chemin contenant une barre oblique ; Bash(rm */**), si.

Quel que soit votre outil, l'ordre est le même : pousser, refuser, intercepter, tester.