Vitalij Bojatschkin

Claude Code Hooks Cookbook: 12 Patterns für sichere und produktive Coding-Agents

Q: Was sind Claude Code Hooks?

Hooks sind Skripte, die Claude Code vor (Pre-Hook) oder nach (Post-Hook) bestimmten Tool-Aufrufen automatisch ausführt. Beispiele: vor jedem git commit Tests laufen lassen, nach jedem npm install Security-Audit triggern, vor jedem kubectl apply den Diff anzeigen.

Q: Wie unterscheidet sich ein Pre-Hook von einem Post-Hook?

Pre-Hooks laufen BEVOR ein Tool ausgeführt wird und können die Ausführung verhindern (durch Non-Zero-Exit). Sie sind richtig für Validation und Permission-Checks. Post-Hooks laufen NACH der Ausführung und reagieren auf das Ergebnis. Sie sind richtig für Logging, Notifications und Cleanup.

Q: Wo werden Hooks konfiguriert?

In der settings.json im .claude/-Ordner. Hooks sind Shell-Skripte (oder beliebige ausführbare Dateien), die mit Tool-Pattern-Matching getriggered werden. Skripte liegen typisch in .claude/hooks/ und werden ins Git committed — damit das ganze Team dieselbe Konfiguration hat.

Q: Können Hooks die Tool-Ausführung blockieren?

Pre-Hooks ja: ein Non-Zero-Exit-Code bricht die Ausführung ab und gibt dem Agent die Fehlermeldung. Damit lassen sich harte Security- oder Quality-Gates implementieren. Post-Hooks können nicht mehr blockieren — die Aktion ist bereits passiert.

Q: Verlangsamen Hooks den Workflow merklich?

Bei kurzen Hooks (Format-Check, Lint, Pre-Commit-Validation) typisch unter 1 Sekunde — kaum spürbar. Bei längeren Hooks (vollständige Test-Suites) lohnt sich Caching oder Inkrementelle Variante. Ein gut designter Hook fällt im Workflow nicht auf, fängt aber 80% der Probleme.

Pre/Post-Tool-Hooks für Claude Code: automatische Tests, Security-Scans, Audit-Logs, Format-Enforcement. 12 production-erprobte Patterns mit Konfigurationsbeispielen — für Platform- und Engineering-Teams.

import BlogFAQ from '../../src/components/BlogFAQ'; import KeyTakeaways from '../../src/components/KeyTakeaways';

<KeyTakeaways items= /

<p data speakable Hooks sind das Stellrad, das aus einem hoffnungsvollen AI Coding Setup ein zuverlässiges Engineering Werkzeug macht. Sie laufen automatisch vor oder nach jedem Tool Call von Claude Code — validieren, loggen, blockieren, oder reagieren. Wer pre commit hooks aus dem klassischen Git Workflow kennt, kennt das Prinzip. Dieser Cookbook zeigt 12 production erprobte Patterns mit Konfigurationsbeispielen, die ihr in eurem Team direkt einsetzen könnt. </p

Wie Hooks technisch funktionieren

Hooks werden in der settings.json eines Projekts (oder global in /.claude/settings.json) konfiguriert. Sie matchen auf Tool Namen oder Tool Pattern und führen ein Skript aus — entweder vor oder nach der Tool Ausführung. Konfigurationsschnitt sieht so aus:

Drei Dinge sind wichtig:

Matcher ist ein Regex auf den Tool Namen. Bash, Edit|Write, . — alles funktioniert. Skripte liegen typisch in .claude/hooks/ und werden ins Git committed. Exit Code entscheidet bei Pre Hooks, ob die Aktion durchgehen darf (Exit 0 = erlaubt, alles andere = blockiert).

Jetzt zu den 12 Patterns.

Pattern 1: Pre Commit Test Run vor git commit

Use Case: Verhindert, dass Claude einen Commit durchführt, der lokale Tests bricht.

```bash !/bin/bash .claude/hooks/pre bash git commit.sh TOOL INPUT=$(cat) COMMAND=$(echo "$TOOL INPUT" | jq r '.tool input.command // empty')

if [[ "$COMMAND" == "git commit" ]]; then echo "Running tests before commit..." npm test || fi exit 0 ```

Settings.json Eintrag matcht auf Bash und ruft das Skript. Wenn Tests fehlschlagen, exit 1, Commit wird verhindert.

Pattern 2: Post Edit Type Check

Use Case: Nach jeder Datei Änderung in einem TypeScript Projekt automatisch tsc noEmit laufen, um Type Fehler sofort zu fangen.

```bash !/bin/bash .claude/hooks/post edit tsc.sh TOOL INPUT=$(cat) FILE=$(echo "$TOOL INPUT" | jq r '.tool input.file path // empty')

if [[ "$FILE" == .ts || "$FILE" == .tsx ]]; then npx tsc noEmit 2 &1 | head 30 &2 fi ```

Hinweis: Hier kein Exit 1 — Post Hook kann ohnehin nicht mehr blockieren. Aber der Type Fehler erscheint sofort im Agent Context.

Pattern 3: Pre Deploy Diff Anzeige bei kubectl apply

Use Case: Sicherheitsnetz für DevOps Tasks. Bevor kubectl apply läuft, automatisch kubectl diff anzeigen.

```bash !/bin/bash TOOL INPUT=$(cat) COMMAND=$(echo "$TOOL INPUT" | jq r '.tool input.command // empty')

if [[ "$COMMAND" == "kubectl apply" ]]; then FILE=$(echo "$COMMAND" | grep oP '(?<= f )[^ ]+') if [ n "$FILE" ]; then echo "=== kubectl diff for $FILE ===" kubectl diff f "$FILE" 2 &1 || true echo "=============================" fi fi ```

Verhindert nichts, aber zwingt zur bewussten Entscheidung.

Pattern 4: Audit Log pro Tool Call

Use Case: Compliance Anforderung — jeder Tool Call wird strukturiert geloggt.

```bash !/bin/bash .claude/hooks/audit log.sh TOOL INPUT=$(cat) TIMESTAMP=$(date Iseconds) TOOL NAME=$(echo "$TOOL INPUT" | jq r '.tool name') USER=$(whoami) REPO=$(basename "$PWD")

echo " " \ /.claude/audit.log ```

Einfacher Append Log. In Production schickt der gleiche Hook strukturierte Logs an SIEM (Splunk, Datadog, CloudWatch).

Pattern 5: Pre Bash Block für gefährliche Befehle

Use Case: Bestimmte Befehle (z.B. rm rf /, kubectl delete ns prod, aws s3 rm recursive) hart blockieren.

```bash !/bin/bash TOOL INPUT=$(cat) COMMAND=$(echo "$TOOL INPUT" | jq r '.tool input.command // empty')

DANGEROUS=( "rm rf /" "kubectl delete ns prod" "aws s3 rm recursive" "DROP DATABASE" "TRUNCATE TABLE" )

for pattern in "$ "; do if [[ "$COMMAND" == "$pattern" ]]; then echo "BLOCKED: command matches dangerous pattern '$pattern'" &2 exit 1 fi done exit 0 ```

Macht aus „Agent darf alles" ein „Agent darf alles außer den 5 schlimmsten Dingen".

Pattern 6: Post Write Format Enforcement

Use Case: Wenn Claude eine Datei schreibt, automatisch Prettier drüberlaufen lassen.

```bash !/bin/bash TOOL INPUT=$(cat) FILE=$(echo "$TOOL INPUT" | jq r '.tool input.file path // empty')

if [ n "$FILE" ] && [ f "$FILE" ]; then case "$FILE" in .ts| .tsx| .js| .jsx| .json| .md) npx prettier write "$FILE" 2 /dev/null ;; esac fi ```

Resultat: alle vom Agent geschriebenen Dateien folgen dem Projektstandard, ohne dass der Agent Prettier Regeln im Kontext halten muss.

Pattern 7: Pre Edit Permission Check pro Pfad

Use Case: Bestimmte Verzeichnisse (z.B. secrets/, infra/prod/) für Claude blockieren.

```bash !/bin/bash TOOL INPUT=$(cat) FILE=$(echo "$TOOL INPUT" | jq r '.tool input.file path // empty')

PROTECTED=( "secrets/" "infra/prod/" ".env.production" )

for prefix in "$ "; do if [[ "$FILE" == "$prefix" ]]; then echo "BLOCKED: $FILE is in protected path '$prefix'" &2 exit 1 fi done exit 0 ```

Komplementär zum permissions Feld in der settings.json — gibt feinere Kontrolle.

Pattern 8: Post Install Security Audit

Use Case: Nach npm install oder pnpm add automatisch Security Audit auf neue Dependencies.

```bash !/bin/bash TOOL INPUT=$(cat) COMMAND=$(echo "$TOOL INPUT" | jq r '.tool input.command // empty')

if [[ "$COMMAND" == "npm install" || "$COMMAND" == "pnpm add" ]]; then echo "=== Security audit ===" npm audit audit level=moderate 2 &1 | tail 20 &2 fi ```

Findet bekannte CVEs in neuen Dependencies, bevor sie ins Git landen.