Comment j'ai cessé d'avoir peur de Claude Code et appris à aimer les Guard Hooks

Imaginez ceci : vous êtes bien installé dans votre fauteuil, sirotant votre café, pendant que votre agent IA préféré (que ce soit Claude Code, Cursor ou GitHub Copilot CLI) vous annonce joyeusement avoir terminé une tâche de refactoring. Soudain, rm -rf ou, encore plus drôle, sudo rm -rf / s'affiche dans le terminal. Le café vous reste en travers de la gorge, et des heures de travail non rémunéré — ces modifications que vous n'avez pas encore commitées — s'évaporent dans l'oubli numérique.

Sensation familière d'impuissance face aux « hallucinations » des réseaux de neurones ? Dans ma pratique, cela m'est arrivé quelques fois, et à chaque fois c'était une leçon douloureuse. C'est pourquoi le projet destructive_command_guard (ou simplement dcg) a immédiatement attiré mon attention. Ce n'est pas une « plateforme révolutionnaire », juste un chien de garde très rapide et courageux pour votre terminal.

Qu'est-ce que cette bête

En bref, dcg est un hook haute performance écrit en Rust. Il intercepte le processus de communication entre vous (ou votre agent IA) et la ligne de commande. Sa seule tâche est d'intercepter une commande destructive avant qu'elle ait une chance de casser quelque chose.

L'outil prend en charge pratiquement tout ce qui est tendance dans le monde du développement IA : Claude Code, Codex CLI, Gemini CLI, Copilot CLI, Cursor IDE, Grok, et même des options exotiques comme Hermes Agent. L'utilitaire fonctionne sur Linux, macOS et Windows (via WSL ou nativement via PowerShell).

Pourquoi un simple grep ne vous sauvera pas

On pourrait se demander : pourquoi créer tout un projet Rust quand on peut écrire un simple script Bash ou Python ? L'auteur du projet, Jeffrey Emanuel, a suivi ce chemin : la première version était en Python. Mais il est rapidement devenu clair que les tâches modernes nécessitent une approche plus nuancée.

Le contexte, c'est tout

dcg ne se contente pas de rechercher la chaîne rm -rf. Il analyse le contexte. Si un agent écrit « don't use rm -rf / » dans la documentation, le hook comprendra qu'il s'agit de données et ne bloquera pas l'écriture du fichier. Mais dès qu'il s'agit d'exécuter réellement la commande — le blocage se déclenche.

Pour cela, un système de vérification à trois niveaux est utilisé :

1. Recherche rapide de sous-chaînes (Quick Reject) via instructions SIMD. Cela prend des microsecondes.
2. Normalisation des commandes (les espaces supplémentaires sont supprimés, les chemins absolus sont remplacés par des chemins relatifs).
3. Vérification par rapport à des motifs complexes utilisant des expressions régulières.

Protection contre les menaces « cachées »

Une fonctionnalité intéressante — l'analyse des Heredocs et des scripts inline. Si un agent décide d'appeler rm -rf, un simple filtre de ligne de commande le laissera passer. dcg creuse à l'intérieur de ces constructions, les analyse en utilisant des AST (Abstract Syntax Trees) et trouve les appels de fonctions suspects.

Ce qu'il bloque exactement

Out of the box, même si vous n'avez rien configuré, dcg protège contre les choses les plus terrifiantes :

• rm -rf, sudo rm -rf /, dd if=/dev/zero.
• git push --force en dehors des dossiers temporaires.
• Formatage de disque, suppression de partitions et autres délices système.

Mais le meilleur reste les « packs » (packs de sécurité). Il y en a plus de 50 dans le dépôt. Vous pouvez activer la protection pour des technologies spécifiques dans votre dcg.toml :

[packs]
enabled = [
    "database.postgresql",    # Заблокирует DROP TABLE
    "kubernetes.kubectl",     # Не даст удалить namespace по ошибке
    "cloud.aws",              # Спасет от случайного terminate-instances
    "containers.docker",      # Ограничит docker system prune
]

Comment ça looks en pratique

Disons que votre agent a décidé de tout perdre et de réinitialiser tous les changements. Vous verrez quelque chose comme ceci dans le terminal :

════════════════════════════════════════════════════════════════
BLOCKED  dcg
────────────────────────────────────────────────────────────────
Reason:  git reset --hard destroys uncommitted changes

Command: git reset --hard HEAD~5

Tip: Consider using 'git stash' first to save your changes.
════════════════════════════════════════════════════════════════

Le blocage vient avec des conseils utiles. Dans la plupart des cas, l'agent, ayant reçu un tel refus, réalise son erreur et suggère un chemin plus sûr, par exemple en utilisant git stash.

Tripes techniques et performance

Ce qui m'a conquis, c'est l'approche de la performance. L'auteur revendique une latence sous la milliseconde. Pour ceux qui aiment les détails :

• Rust + SIMD : les instructions vectorielles du processeur sont utilisées pour une recherche de mots-clés ultra-rapide.
• Dual Regex Engine : les motifs simples sont traités par un moteur rapide avec un temps d'exécution linéaire, tandis que les motifs complexes (où des lookaheads/lookbehinds sont nécessaires) sont traités par un moteur regex plus puissant mais plus lent.
• Zero-allocation : dans les chemins critiques, le programme essaie de ne pas allouer de mémoire heap, ce qui est critique quand le hook est appelé à chaque frappe ou commande de l'agent.

Au fait, le projet implémente une philosophie fail-open. Si dcg n'a pas le temps d'analyser la commande dans le budget de temps alloué (200ms par défaut), il la laisse passer. Cela est fait pour que l'outil ne devienne jamais un « frein » qui entrave le travail normal. De mon point de vue, un compromis raisonnable entre sécurité et commodité.

Comment intégrer dans votre flux de travail

Le moyen le plus simple de l'essayer est d'exécuter le script d'installation du README. Il déterminera votre OS, téléchargera le bon binaire et configurera les paramètres dans les configs des agents IA.

Pour Claude Code, cela ressemble à ajouter une section dans claude_desktop_config.json :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "dcg" }]
      }
    ]
  }
}

Et si vous travaillez en équipe et voulez vous assurer que personne n'a commité un git push --force destructif ou un pipeline CI cassé, il y a un mode scan :

dcg scan --staged

Vous pouvez le hooker à un pre-commit hook, et il vérifiera tous les fichiers que vous essayez de pousser vers Git.

Quelques mots sur les inconvénients

Il n'y a pas d'outils parfaits. Qu'est-ce qui peut mal tourner ?

1. Faux positifs : Malgré l'analyse avancée, parfois dcg peut bloquer des commandes parfaitement légitimes. Pour ce cas, il y a une « sortie de secours » via la variable d'environnement DCG_BYPASS ou le système DCG_UNLOCK_CODE.
2. Complexité de configuration : Si vous avez besoin de quelque chose de spécifique, vous devrez plonge dans les configs TOML.
3. Rust Nightly : Si vous voulez compiler le projet vous-même depuis les sources, vous aurez besoin de la version nightly de Rust, car des fonctionnalités de l'édition 2024 sont utilisées.

Qui en a besoin

Si vous utilisez des agents IA plus d'une fois par semaine et leur faites confiance pour exécuter des commandes dans le terminal — installez-le sans hésiter. C'est une assurance peu coûteuse. C'est particulièrement pertinent pour les débutants qui pourraient ne pas remarquer immédiatement que la commande « de nettoyage du cache » suggérée par le réseau de neurones efface en fait la moitié du système.

Pour les développeurs expérimentés, c'est plutôt un moyen d'économiser ses nerfs. Nous savons tous à quel point il est facile d'appuyer sur Ctrl+C en pilotage automatique, puis de se rappeler frénétiquement quand était la dernière sauvegarde.

dcg est cet outil qui fonctionne silencieusement en arrière-plan et qui « ne demande pas à manger » jusqu'à ce qu'un moment critique arrive. Il ne fait pas de magie, il parse juste bien les chaînes et sait à quoi ressemblent les mauvaises commandes. Dans un monde où nous déléguons de plus en plus l'écriture et l'exécution du code aux machines, ces « fusibles numériques » deviennent un attribut obligatoire de l'environnement de travail.

Cela vaut le coup de l'essayer au moins pour voir à quel point les logiciels Rust modernes sont rapides. Et vous, avez-vous déjà fait confiance à votre IA pour supprimer des fichiers ? Comment cela s'est-il terminé ?