Claude Code Permissions und Sicherheitsmodell verstehen

1. Warum das Berechtigungsmodell im Zentrum von Claude Code steht

Claude Code kann Dateien lesen, ändern, löschen, Bash-Befehle ausführen und auf ein Netzwerk zugreifen - im Grunde alles, wozu der aufrufende Benutzer selbst berechtigt ist. Genau deshalb ist das Berechtigungsmodell keine Nebenfunktion, sondern die zentrale Sicherheitsschicht zwischen einem sprachbasierten Assistenten und einem produktiven Entwicklungssystem. Ohne diese Schicht müsste jedem Vorschlag blind vertraut werden, bevor er ausgeführt wird - ein Modell, das weder für Solo-Entwickler noch für Teams tragbar ist.

Der Grundgedanke ist einfach: Aktionen mit geringem Risiko und hoher Reversibilität, etwa das Lesen einer Datei, sollen den Arbeitsfluss nicht ausbremsen. Aktionen mit hohem Risiko oder schwerer Reversibilität, etwa das Löschen eines Verzeichnisses oder ein Force-Push, sollen eine bewusste menschliche Entscheidung erzwingen. Diese Abwägung zwischen Sicherheit und Tempo zieht sich durch jede Konfigurationsebene von Claude Code - von der Kommandozeile über settings.json bis zu projektweiten Hooks, die in den folgenden Abschnitten im Detail behandelt werden.

2. Die Permission-Modi im Überblick: Default, Auto-Accept, Plan, Bypass

Claude Code kennt mehrere Permission-Modi, die sich in ihrer Grundhaltung gegenüber Rückfragen unterscheiden. Der Default-Modus fragt vor jeder Datei-Änderung und jedem Bash-Befehl einzeln nach, mit der Option, eine Aktion, alle Aktionen dieses Typs oder alle Aktionen dieser Sitzung freizugeben. Der Auto-Accept-Modus (acceptEdits) übernimmt Datei-Bearbeitungen automatisch, verlangt aber weiterhin eine Bestätigung für Bash-Befehle - sinnvoll bei Refactoring-Aufgaben, bei denen viele kleine Edits anfallen, aber keine Shell-Aktionen nötig sind.

Der Plan-Modus führt gar keine Änderungen aus, sondern erstellt ausschließlich einen Plan zur Überprüfung - ideal für explorative Aufgaben oder Codebasen, die noch unbekannt sind. Der Bypass-Modus (--dangerously-skip-permissions) deaktiviert sämtliche Rückfragen und sollte ausschließlich in isolierten Umgebungen wie Containern oder CI-Pipelines ohne Zugriff auf produktive Systeme verwendet werden. Der Name ist bewusst gewählt: Wer diesen Modus in einer normalen Entwicklungsumgebung aktiviert, gibt die letzte Kontrollinstanz vollständig auf.

#!/usr/bin/env bash
# Claude Code CLI: permission mode per session

# Default mode: every file edit and every Bash command needs approval
claude

# Auto-accept file edits, but Bash commands still require approval
claude --permission-mode acceptEdits

# Planning only: no edits or commands are executed, only a plan is produced
claude --permission-mode plan

# Skip all permission prompts entirely (dangerous, use only in sandboxes/CI)
claude --dangerously-skip-permissions

# Headless mode with an explicit allow-list for a CI pipeline
claude -p "Update the changelog for this release" \
  --allowedTools "Read" "Grep" "Edit(CHANGELOG.md)"

3. Was ohne Rückfrage laufen darf: Lesen, Suchen, Analysieren

Lesende Operationen sind der klarste Fall für eine Automatisierung ohne Rückfrage. Read, Grep und Glob verändern keinen Zustand, sind beliebig oft wiederholbar und liefern lediglich Informationen zurück, auf deren Basis Claude Code weitere Schritte plant. Ein Entwickler, der bei jedem Lesevorgang manuell bestätigen müsste, würde den eigentlichen Vorteil des Werkzeugs - schnelle Exploration großer Codebasen - faktisch zunichtemachen.

Auch reine Analysebefehle wie statische Codeprüfungen (phpstan, phpcs) oder das Ausführen einer bestehenden Testsuite in einer isolierten Umgebung gehören in diese risikoarme Kategorie, sofern sie keine Produktionsdaten oder externen Systeme berühren. Wichtig ist die Unterscheidung zwischen einem Befehl, der Informationen liefert, und einem Befehl, der einen Nebeneffekt erzeugt: git status und git diff sind unbedenklich, git commit verändert bereits den Projektzustand und gehört in eine andere Kategorie. Diese Trennschärfe ist die Grundlage jeder sinnvollen Allow-Liste.

4. Datei-Änderungen freigeben: Edit, Write und MultiEdit

Datei-Änderungen liegen in einer Grauzone zwischen risikoarm und risikoreich. Innerhalb eines Git-Repositorys sind sie durch die Versionskontrolle grundsätzlich reversibel - ein fehlerhafter Edit lässt sich mit git diff prüfen und mit git checkout rückgängig machen, solange er noch nicht committet wurde. Genau deshalb ist der Auto-Accept-Modus für Datei-Bearbeitungen in vielen Teams akzeptabel, während Bash-Befehle weiterhin einzeln bestätigt werden.

Die Sicherheitsgrenze verschiebt sich jedoch, sobald Änderungen außerhalb des Arbeitsverzeichnisses erfolgen, Konfigurationsdateien mit Zugangsdaten betroffen sind oder ein Edit unmittelbar vor einem automatischen Commit steht. In settings.json lassen sich Edit-Regeln pfadspezifisch einschränken, etwa mit Edit(src/app/code/**) als Freigabe und einer expliziten Ask-Regel für .env- oder *.pem-Dateien. Diese Granularität erlaubt es, produktiven Code frei bearbeiten zu lassen, während sensible Konfigurationsdateien weiterhin eine bewusste Bestätigung erfordern.

5. Bash-Befehle kontrollieren: Allow-, Ask- und Deny-Regeln

Bash-Befehle sind die mächtigste und zugleich riskanteste Werkzeugkategorie, weil sie Claude Code Zugriff auf das gesamte System geben, nicht nur auf einzelne Dateien. Claude Code unterscheidet deshalb drei Regelebenen: allow für Befehle, die ohne Rückfrage laufen dürfen, ask für Befehle, die explizit bestätigt werden müssen, und deny für Befehle, die unabhängig vom Kontext blockiert werden. Deny-Regeln haben immer Vorrang vor Allow-Regeln - ein Befehl, der beiden Listen entspricht, wird blockiert.

In der Praxis bewährt sich eine Kombination aus großzügigen Allow-Regeln für wiederkehrende, harmlose Befehle (npm test, git status, bin/magento cache:status) und expliziten Deny-Regeln für bekannte Gefahrenmuster. Wildcard-Muster wie Bash(git push --force*) greifen dabei auch bei Varianten mit zusätzlichen Flags. Wichtig: Eine Allow-Liste ersetzt keine Deny-Liste, denn sie deckt nur bekannte, gute Fälle ab - unbekannte Befehle landen ohnehin im Ask-Modus und müssen dort bewusst geprüft werden.

{
  "permissions": {
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm test)",
      "Bash(php bin/phpunit *)",
      "Bash(git status)",
      "Bash(git diff*)",
      "Bash(git log*)"
    ],
    "ask": [
      "Bash(npm install*)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Edit",
      "Write"
    ],
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Bash(git reset --hard*)",
      "Bash(DROP TABLE*)"
    ]
  }
}

6. Git und Remote-Operationen: Wann eine Pause zwingend ist

Git-Operationen verdienen eine gesonderte Betrachtung, weil sie zwischen rein lokalen und teamweiten Auswirkungen unterscheiden. Ein lokaler Commit betrifft nur das eigene Arbeitsverzeichnis und lässt sich mit git reset oder git commit --amend korrigieren, solange er nicht gepusht wurde. Ein git push auf einen Feature-Branch ist bereits weitreichender, aber in der Regel noch reversibel. Ein git push --force auf einen geteilten Branch oder direkt auf main hingegen überschreibt die Historie für das gesamte Team und kann fremde Commits unwiederbringlich verlieren.

Die praktische Konsequenz: Lokale Commits können in vertrauenswürdigen Projekten in den Auto-Accept-Bereich fallen, während jeder Push-Befehl grundsätzlich in der Ask-Kategorie bleiben sollte - unabhängig davon, wie routiniert der jeweilige Workflow erscheint. Besonders kritisch sind Befehle, die Historie umschreiben (rebase -i auf geteilten Branches), Tags löschen oder Remote-Branches entfernen. Diese Operationen sind aus gutem Grund in vielen Team-Konfigurationen explizit auf der Deny-Liste, selbst wenn ein einzelner Entwickler sie gelegentlich bewusst braucht - in solchen Fällen ist eine manuelle Ausführung außerhalb von Claude Code die sicherere Wahl.

7. settings.json und Hooks: Regeln projektweit durchsetzen

Während Permission-Modi das Verhalten einer einzelnen Sitzung steuern, wirken die Regeln in .claude/settings.json projektweit und werden bei jedem Start neu geladen. Diese Datei lässt sich versionieren und damit gemeinsam mit dem Code im Repository pflegen - Änderungen an der Sicherheitspolitik durchlaufen dieselbe Code-Review wie jede andere Änderung auch. Für Fälle, die über statische Allow/Deny-Muster hinausgehen, bietet Claude Code Hooks: Skripte, die vor (PreToolUse) oder nach (PostToolUse) einer Werkzeugausführung automatisch laufen und den Aufruf anhand beliebiger Logik blockieren können.

Ein PreToolUse-Hook erhält den geplanten Werkzeugaufruf als JSON auf stdin und kann mit einem bestimmten Exit-Code die Ausführung verhindern. Das erlaubt Prüfungen, die reine Musterabgleiche nicht abdecken - etwa das Verbieten von Schreibzugriffen außerhalb eines bestimmten Verzeichnisses, unabhängig vom genauen Befehlstext. Hooks sind damit die flexiblere, aber auch wartungsintensivere Ergänzung zu den deklarativen Regeln in settings.json.

#!/usr/bin/env python3
"""PreToolUse hook: block destructive Bash commands before execution.
Reads the tool call as JSON from stdin, exits 2 to block with a message.
"""
import json
import re
import sys

DANGEROUS_PATTERNS = [
    r"rm\s+-rf\s+/(?!home|tmp)",
    r"git\s+push\s+.*--force",
    r"git\s+reset\s+--hard",
    r"DROP\s+TABLE",
    r">\s*/dev/sd[a-z]",
]

payload = json.load(sys.stdin)
if payload.get("tool_name") != "Bash":
    sys.exit(0)

command = payload.get("tool_input", {}).get("command", "")

for pattern in DANGEROUS_PATTERNS:
    if re.search(pattern, command, re.IGNORECASE):
        print(f"Blocked: command matches dangerous pattern '{pattern}'", file=sys.stderr)
        sys.exit(2)

sys.exit(0)

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "python3 .claude/hooks/block-dangerous-commands.py"
          }
        ]
      }
    ]
  }
}

8. Team-Policies: gemeinsame Konfiguration und Onboarding

Sobald mehrere Entwickler Claude Code im selben Projekt einsetzen, wird aus einer individuellen Einstellung eine Team-Frage. Eine projektweite .claude/settings.json im Repository sorgt dafür, dass alle Beteiligten dieselben Grundregeln erhalten, ohne sie einzeln konfigurieren zu müssen - neue Teammitglieder erben die Policy automatisch beim Klonen des Repositories. Persönliche Ergänzungen lassen sich zusätzlich in einer nicht versionierten settings.local.json ablegen, etwa für individuelle Zugangsdaten oder projektfremde Hilfswerkzeuge.

Für Teams mit unterschiedlichem Erfahrungsstand empfiehlt sich eine konservative Basiskonfiguration, die schrittweise gelockert wird, statt umgekehrt. Kritisch ist zudem die Frage, wer Änderungen an der Permission-Konfiguration selbst freigeben darf: Wenn settings.json über einen normalen Pull-Request geändert werden kann, sollte diese Datei denselben Review-Anforderungen unterliegen wie Deployment-Skripte oder CI-Konfiguration - schließlich definiert sie direkt, welche automatisierten Aktionen im Namen des Teams ausgeführt werden dürfen.

// ci-review.js: invoke Claude Code headlessly with a strict allow-list
const { spawnSync } = require('node:child_process');

const result = spawnSync('claude', [
  '-p', 'Review the diff for obvious bugs and report findings only',
  '--permission-mode', 'plan',
  '--allowedTools', 'Read', 'Grep', 'Glob',
], { encoding: 'utf-8' });

if (result.status !== 0) {
  console.error('Claude Code review failed:', result.stderr);
  process.exit(1);
}

console.log(result.stdout);

9. Grenzen des Modells: falsches Sicherheitsgefühl und Restrisiken

Das Permission-System reduziert Risiko, beseitigt es aber nicht vollständig. Eine Allow-Regel wie Bash(npm install*) wirkt harmlos, kann aber ein Paket mit einem bösartigen postinstall-Skript installieren, ohne dass eine weitere Rückfrage erfolgt. Auch Prompt-Injection über Inhalte, die Claude Code während der Arbeit liest - etwa eine manipulierte README-Datei oder ein kompromittierter Kommentar in einer Abhängigkeit - kann versuchen, das Modell zu Aktionen zu bewegen, die außerhalb der eigentlichen Aufgabe liegen. Die Deny-Liste ist deshalb kein Ersatz für grundsätzliche Vorsicht bei unbekannten Abhängigkeiten oder Repositories.

Realistisch betrachtet ist das Berechtigungsmodell eine Verteidigungsschicht unter mehreren, nicht die einzige. Sandboxing auf Betriebssystem- oder Container-Ebene, eingeschränkte Datenbankrechte für Entwicklungsumgebungen und regelmäßige Audits der settings.json-Regeln ergänzen die eingebauten Schutzmechanismen. Die folgende Übersicht ordnet typische Aktionen danach ein, ob eine automatische Freigabe vertretbar ist oder eine bewusste Bestätigung zwingend bleibt.

10. Zusammenfassung

Das Permission-System von Claude Code löst ein Grundproblem KI-gestützter Entwicklung: Automatisierung soll Tempo bringen, ohne die Kontrolle über produktive Systeme aufzugeben. Der Default-Modus fragt bei jeder Datei-Änderung und jedem Bash-Befehl nach, der Auto-Accept-Modus beschleunigt Datei-Bearbeitungen, der Plan-Modus führt gar nichts aus, und der Bypass-Modus gehört ausschließlich in isolierte Umgebungen. Lesende Operationen lassen sich bedenkenlos automatisieren, während destruktive Befehle wie rm -rf, git push --force und Produktionsmigrationen grundsätzlich eine bewusste Bestätigung verdienen.

Projektweite Regeln in settings.json und flexible PreToolUse-Hooks machen diese Policy reproduzierbar und teamweit gültig, statt von individuellen Einstellungen abhängig zu sein. Wichtig bleibt das Bewusstsein, dass das Berechtigungsmodell Risiko reduziert, aber nicht eliminiert - Prompt-Injection und manipulierte Abhängigkeiten erfordern zusätzliche Vorsicht jenseits reiner Allow- und Deny-Listen.

11. FAQ: Claude Code Permissions und Sicherheitsmodell