Wie ich aufhörte, mich vor Claude Code zu fürchten und lernte, Guard Hooks zu lieben

Stellen Sie sich vor: Sie sitzen gemütlich in Ihrem Sessel, trinken Kaffee, während Ihr Lieblings-KI-Agent (sei es Claude Code, Cursor oder GitHub Copilot CLI) fröhlich den Abschluss einer Refactoring-Aufgabe meldet. Plötzlich erscheint rm -rf oder, noch lustiger, sudo rm -rf / im Terminal. Der Kaffee bleibt Ihnen im Hals stecken, und Stunden unbezahlter Arbeit – die Änderungen, die Sie noch nicht committed haben – verdampfen in digitalem Nirvana.

Ein vertrautes Gefühl der Hilflosigkeit angesichts neuronaler Netzwerk-„Halluzinationen"? In meiner Praxis passierte mir so etwas ein paar Mal, und jedes Mal war es eine schmerzhafte Lektion. Deshalb hat das Projekt destructive_command_guard (oder einfach dcg) sofort meine Aufmerksamkeit erregt. Es ist keine „revolutionäre Plattform", sondern einfach ein sehr schneller und mutiger Wachhund für Ihr Terminal.

Was ist das für ein Biest

Kurz gesagt, ist dcg ein hochperformanter Hook, geschrieben in Rust. Er fängt die Kommunikation zwischen Ihnen (oder Ihrem KI-Agenten) und der Kommandozeile ab. Seine einzige Aufgabe ist es, einen destruktiven Befehl abzufangen, bevor er die Chance bekommt, etwas kaputtzumachen.

Das Tool unterstützt praktisch alles, was in der KI-Entwicklungswelt gerade im Trend liegt: Claude Code, Codex CLI, Gemini CLI, Copilot CLI, Cursor IDE, Grok und sogar exotischere Optionen wie Hermes Agent. Das Utility funktioniert unter Linux, macOS und Windows (via WSL oder nativ via PowerShell).

Warum ein normales grep Sie nicht retten wird

Man könnte meinen: Warum ein ganzes Rust-Projekt aufbauen, wenn man ein einfaches Bash- oder Python-Skript schreiben kann? Der Projekt-Autor Jeffrey Emanuel hat genau diesen Weg eingeschlagen: Die erste Version war in Python. Aber schnell wurde klar, dass moderne Aufgaben einen differenzierteren Ansatz erfordern.

Kontext ist alles

dcg sucht nicht einfach nur nach dem String rm -rf. Es analysiert den Kontext. Wenn ein Agent „don't use rm -rf /" in der Dokumentation schreibt, versteht der Hook, dass es sich um Daten handelt, und blockiert den Dateischreibvorgang nicht. Aber sobald es um die tatsächliche Ausführung des Befehls geht – schlägt die Blockade zu.

Dafür wird ein dreistufiges Verifizierungssystem verwendet:

1. Schnelle Substring-Suche (Quick Reject) via SIMD-Anweisungen. Das dauert Mikrosekunden.
2. Befehlsnormalisierung (zusätzliche Leerzeichen werden entfernt, absolute Pfade durch relative ersetzt).
3. Überprüfung gegen komplexe Muster mittels regulärer Ausdrücke.

Schutz vor „versteckten" Bedrohungen

Eine interessante Funktion – das Scannen von Heredocs und Inline-Skripten. Wenn ein Agent beschließt, rm -rf aufzurufen, lässt ein einfacher Kommandozeilenfilter das durch. dcg gräbt sich in solche Konstrukte, analysiert sie mit AST (Abstract Syntax Trees) und findet verdächtige Funktionsaufrufe.

Was genau es blockiert

Out of the box, auch wenn Sie nichts konfiguriert haben, schützt dcg vor den schlimmsten Dingen:

• rm -rf, sudo rm -rf /, dd if=/dev/zero.
• git push --force außerhalb von temporären Ordnern.
• Festplattenformatierung, Partitionslöschung und andere Systemdelikte.

Aber das Beste sind die „Packs" (Sicherheitspakete). Es gibt mehr als 50 davon im Repository. Sie können Schutz für spezifische Technologien in Ihrer dcg.toml aktivieren:

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

Wie es in der Praxis aussieht

Angenommen, Ihr Agent beschließt, durchzudrehen und alle Änderungen zurückzusetzen. Sie werden etwas like this im Terminal sehen:

════════════════════════════════════════════════════════════════
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.
════════════════════════════════════════════════════════════════

Der Block kommt mit hilfreichen Ratschlägen. In den meisten Fällen erkennt der Agent, nachdem er eine solche Ablehnung erhalten hat, den Fehler und schlägt einen sichereren Weg vor, zum Beispiel die Verwendung von git stash.

Technische Eingeweide und Performance

Was mich überzeugt hat, war der Performance-Ansatz. Der Autor verspricht Sub-Millisekunden-Latenz. Für diejenigen, die Details mögen:

• Rust + SIMD: Prozessor-Vektorinstruktionen werden für blitzschnelle Schlüsselwortsuche verwendet.
• Dual-Regex-Engine: einfache Muster werden von einer schnellen Engine mit linearer Ausführungszeit bearbeitet, während komplexere (wo Lookaheads/Lookbehinds benötigt werden) von einer leistungsfähigeren, aber langsameren regex verarbeitet werden.
• Zero-Allocation: in Hot Paths versucht das Programm, keinen Heap-Speicher zu allokieren, was kritisch ist, wenn der Hook bei jedem Tastendruck oder Agent-Befehl aufgerufen wird.

Übrigens implementiert das Projekt eine Fail-Open-Philosophie. Wenn dcg nicht genug Zeit hat, den Befehl innerhalb des zugewiesenen Zeitbudgets (standardmäßig 200ms) zu analysieren, lässt es ihn durch. Dies geschieht, damit das Tool niemals zum „Bremsklotz" wird, der normale Arbeit behindert. Meiner Meinung nach ein vernünftiger Kompromiss zwischen Sicherheit und Benutzerfreundlichkeit.

Wie man es in seinen Arbeitsprozess integriert

Der einfachste Weg, es auszuprobieren, ist das Installationsskript aus der README auszuführen. Es erkennt Ihr Betriebssystem, lädt das richtige Binary herunter und konfiguriert die Einstellungen in den KI-Agent-Konfigurationen.

Für Claude Code sieht es so aus, als würde man einen Abschnitt zu claude_desktop_config.json hinzufügen:

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

Und wenn Sie in einem Team arbeiten und sicherstellen möchten, dass niemand einen destruktiven git push --force oder eine kaputte CI-Pipeline committed hat, gibt es einen Scan-Modus:

dcg scan --staged

Sie können es an einen Pre-Commit-Hook anhängen, und es wird alle Dateien überprüfen, die Sie in Git pushen möchten.

Ein paar Worte zu den Nachteilen

Es gibt keine perfekten Tools. Was kann schiefgehen?

1. False Positives: Trotz fortschrittlichem Parsing kann dcg manchmal völlig legitime Befehle blockieren. Für diesen Fall gibt es einen „Notausgang" über die Umgebungsvariable DCG_BYPASS oder das DCG_UNLOCK_CODE-System.
2. Konfigurationskomplexität: Wenn Sie etwas Spezifisches brauchen, müssen Sie sich in TOML-Konfigurationen einarbeiten.
3. Rust Nightly: Wenn Sie das Projekt selbst aus dem Quellcode bauen möchten, benötigen Sie die Nightly-Version von Rust, da Features der 2024 Edition verwendet werden.

Wer braucht das

Wenn Sie KI-Agenten mehr als einmal pro Woche nutzen und ihnen vertrauen, Befehle im Terminal auszuführen – installieren Sie es ohne zu zögern. Es ist eine günstige Versicherung. Das ist besonders relevant für Anfänger, die möglicherweise nicht sofort bemerken, dass der „Cache-Bereinigungs"-Befehl, den das neuronale Netz vorschlägt, tatsächlich die Hälfte des Systems löscht.

Für erfahrene Entwickler ist es eher eine Art, Nerven zu schonen. Wir alle wissen, wie leicht man im Autopilot-Modus auf Ctrl+C drücken kann, und dann verzweifelt versucht, sich daran zu erinnern, wann das letzte Backup war.

dcg ist genau das Tool, das leise im Hintergrund läuft und „nicht um Futter bittet", bis ein kritischer Moment eintritt. Es macht keine Magie, es parsed einfach Strings gut und weiß, wie schlechte Befehle aussehen. In einer Welt, in der wir zunehmend das Schreiben und Ausführen von Code an Maschinen delegieren, werden solche „digitalen Sicherungen" zu einem obligatorischen Attribut der Arbeitsumgebung.

Es lohnt sich, es zumindest auszuprobieren, um zu sehen, wie schnell moderne Rust-Software ist. Und haben Sie Ihrem KI-Agenten jemals vertraut, Dateien zu löschen? Wie ist das ausgegangen?