Claude Code ignore les interdictions de CLAUDE.md : ce qu'il faut déplacer vers les permissions et les hooks

Vous avez écrit dans CLAUDE.md « ne supprime pas de données sans demande », et l'agent les a quand même supprimées. Ce n'est pas un bug rare : dans l'issue #46779, l'auteur se plaint que Claude Code effaçait régulièrement des données au-delà de la tâche, alors que l'interdiction était écrite noir sur blanc. Une analyse publiée sur Habr propose une manière claire d'aborder le problème : une règle doit vivre là où le coût de sa violation le justifie.

Pourquoi le texte ne suffit pas

CLAUDE.md est chargé au début de chaque session, et Claude Code le relit après la compression de la conversation. La règle semble donc toujours présente dans le contexte. Mais le problème n'est pas la mémoire. Dans le benchmark StateTrack-Bench présenté à l'EMNLP 2026, les auteurs attribuent 88,6 % des échecs dans les longues conversations à une dérive comportementale : le modèle se souvient de la contrainte, mais cesse de la respecter. Microsoft Research ajoute un constat général : chez les meilleurs modèles, la qualité en dialogue multitour est en moyenne inférieure de 39 % à celle en dialogue à un seul tour.

Anthropic écrit honnêtement dans sa documentation qu'une instruction du type « ne fais jamais X » est respectée dans la plupart des cas, mais qu'elle peut être violée sous pression, lors d'une longue session, dans une situation ambiguë ou en cas de prompt injection. Ici, la prompt injection désigne l'instruction d'un tiers cachée dans un fichier que l'agent a ouvert pour sa tâche.

Répartir les règles selon le coût d'une erreur

Si l'erreur coûte quelques minutes, une ligne de texte suffit. Si elle coûte de l'argent, expose des clés ou lance un travail sans confirmation, il faut du code. Il existe trois outils :

• permissions : les règles allow, ask et deny définissent ce que l'agent fait seul, ce qu'il demande avant de faire et ce qui lui est interdit ;
• hooks : des commandes shell que Claude Code exécute sur un événement de session, par exemple avant l'écriture d'un fichier ou lorsqu'il tente de terminer son tour ;
• une vérification par le code avant le lancement, par exemple un script qui ne démarre pas le travail sans fichier contenant un plan validé.

Exemple tiré de la pratique de l'auteur : une commande d'un outil de navigateur consommait des crédits payants. Elle a été bloquée par une règle deny dans .claude/settings.json, et non par une demande écrite dans le texte. Il est conseillé de versionner le fichier de configuration dans git pour que toute l'équipe bénéficie des règles. Détail important tiré d'un commentaire de l'issue #65563 : une protection qui ne surveille que les commandes Bash ne verra pas un appel passant par MCP. Dans cette issue, on demandait à l'agent d'enquêter sur un bug, et il a, via l'automatisation du navigateur, cliqué sur la suppression et la confirmation sur un véritable enregistrement de la base de production.

Il en va de même pour les clés. Un deny sur la lecture de .env protège le fichier, un hook sur l'écriture rejette une modification contenant une clé, mais l'affichage d'un secret depuis l'environnement n'est couvert par aucune de ces deux règles. Une clé divulguée ne peut pas être récupérée ; on ne s'en protège donc pas avec du simple texte.

Le hook Stop contre le travail inachevé

Pour que l'agent ne termine pas son tour tant qu'une vérification échoue, on attache à l'événement Stop un script qui lance la vérification du projet (par exemple make check) et, en cas d'échec, se termine avec le code 2. Le code 2 bloque la fin du tour, et stderr est transmis à l'agent comme message d'erreur. Le code 1 sans sortie ne bloque pas l'action, ce qu'a vérifié Caprock sur les versions 2.1.289 et 2.1.299. Depuis la version 2.1.295, l'option onFailure: block bloque l'action même en cas de défaillance du hook.

Il existe une limite : après huit blocages consécutifs sans appel d'outil, Claude Code termine tout de même son tour. La variable CLAUDE_CODE_STOP_HOOK_BLOCK_CAP relève ce seuil, et sur les tâches longues, il convient de vérifier que le hook ne s'y heurte pas.

Que faire

Considérez CLAUDE.md comme un journal des défaillances, et non comme une déclaration d'intentions. Ajoutez une ligne après la deuxième erreur identique, gardez le fichier sous 200 lignes, désignez un responsable et relisez les modifications comme du code. Une entrée obsolète nuit davantage que son absence.

Limite de l'approche : les exemples de l'article sont illustratifs, et la syntaxe exacte doit être vérifiée sur la page Configure permissions de la documentation. Quant à la question principale à se poser pour votre projet, elle est simple : quelles sont les trois règles de votre fichier qui coûtent de l'argent ou exposent des secrets ? Ce sont elles qu'il faut déplacer en premier vers deny, les hooks et les vérifications par le code.