„Ändere bitte nur die Entwürfe“ ist eine sinnvolle Arbeitsanweisung. Sie ist aber noch kein technischer Kontrollpunkt. Ein Hook kann eine wiederkehrende Regel dort ansetzen lassen, wo eine konkrete Aktion vorbereitet ist. Damit wird aus einer allgemeinen Bitte eine überprüfbare Entscheidung über einen bestimmten Werkzeugaufruf.
Die Claude-Code-Referenz beschreibt unter anderem PreToolUse: Das Ereignis liegt nach der Erzeugung der Werkzeugparameter und vor der Verarbeitung des Aufrufs. Der Hook kann eine Entscheidung zurückgeben. Die folgenden Beispiele erläutern einen eigenen Entwurf; eine Hook-Konfiguration wurde dafür nicht installiert oder ausgeführt.
Welche Information liegt am Entscheidungspunkt vor?
Unser Lernprojekt enthält einen Entwurfsordner und eine Referenzdatei daneben. Der Agent soll nur Entwürfe bearbeiten. Eine sinnvolle Regel betrachtet deshalb die konkrete Zielangabe einer Schreibaktion. Sie entscheidet nicht, ob der gesamte Gesprächsinhalt vertrauenswürdig ist.
Die Schnittstelle liefert Werkzeugname und Eingabe. Für eine passende Dateianfrage lässt sich daraus das Ziel bestimmen. Ein unbekanntes Werkzeug oder eine unverständliche Eingabe sollte einen eigenen Zustand auslösen. Ein stiller Fehler im Prüfprogramm darf nicht wie ein erfolgreich überprüfter Pfad aussehen.
Eine Entscheidung ist strukturierte Rückgabe
Ein illustrativer Ablehnungswert in der dokumentierten PreToolUse-Struktur sieht so aus. Der Grund ist selbst formuliert; er beschreibt die lokale Regel, keine allgemeine Bewertung des Nutzers.
{
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
"permissionDecision": "deny",
"permissionDecisionReason": "Die Zieldatei liegt außerhalb des Entwurfsbereichs."
}
}Dieser Ausschnitt ist die Rückgabe, kein vollständiges Prüfprogramm. Er enthält weder die Registrierung des Hooks noch das Lesen und Prüfen der Eingabe. Gerade diese Trennung ist hilfreich: Regel, technische Auswertung und Schnittstellenausgabe lassen sich unabhängig betrachten.
Pfadzugehörigkeit ist mehr als ein Textanfang
Ein bloßer Vergleich von Zeichenfolgen kann ähnlich benannte Nachbarordner verwechseln. Die eigene Regel sollte daher mit eindeutig aufgelösten Pfaden arbeiten und die tatsächliche Zugehörigkeit zum vorgesehenen Wurzelordner prüfen. Unterschiedliche Trennzeichen und Verknüpfungen müssen in der eingesetzten Umgebung berücksichtigt werden.
eigene Regellogik, schematisch:
Eingabe vollständig lesbar? Sonst Prüfstatus unbekannt.
Werkzeug gehört zum behandelten Schreibweg? Sonst nicht geprüft.
Ziel und erlaubte Wurzel eindeutig auflösen.
Ziel liegt wirklich innerhalb der Wurzel? Sonst ablehnen.
Nur den konkret behandelten Aufruf bewerten.Diese Skizze lässt bewusst keine komplette Absicherung vermuten. Besonders externe Programme, die selbst weitere Dateien verändern, benötigen eine andere Betrachtung als ein einzelnes Dateifeld. Eine erlaubte Startdatei sagt noch nicht, welche Folgeaktionen ein Skript ausführt.
Vier Proben machen die Reichweite sichtbar
Lege im Wegwerfprojekt eine erlaubte Datei, eine geschützte Referenz und einen ähnlich benannten Nachbarordner an. Ergänze eine fehlerhafte Eingabe. Für jeden Fall schreibst du vorher auf, welche Entscheidung erwartet wird. Betrachte dann sowohl Rückgabe als auch tatsächliche Ausführung.
Teste außerdem den Ausfall des Prüfprogramms selbst. Das Fehlerverhalten hängt von Ereignis und Konfiguration ab und gehört deshalb zur Abnahme. Eine fehlende Meldung ist kein Beleg, dass die Regel erfolgreich geprüft wurde.
Notiere pro Probe auch, ob der Hook überhaupt erreicht wurde. Eine Aktion, die über einen anderen Weg erfolgt, kann an der Regel vorbeilaufen, ohne dass deren interne Pfadprüfung falsch gearbeitet hätte.
Ein Hook ist kein vollständiger Schutzrahmen
PreToolUse betrifft Werkzeugaufrufe. Kontext kann auf anderen Wegen in die Sitzung gelangen; die aktuelle Referenz beschreibt dafür ausdrücklich Grenzen. Ein Hook ersetzt daher weder Berechtigungen noch die Kontrolle der Umgebung und ist keine allgemeine Absicherung gegen Prompt Injection.
Beginne mit einer einzelnen lokalen Regel und dokumentiere die erfassten sowie nicht erfassten Wege. Der technische Gewinn liegt im verständlichen Kontrollpunkt. Ob dieser Punkt in deiner Version richtig eingerichtet ist, muss ein tatsächlicher Versuch mit den passenden Schnittstellen zeigen.
Quellen und Dokumentationsstand: 25. Oktober 2026.
