Vollständiger Leitfaden zu Claude Code Berechtigungen | settings.json, Hooks & Allowlist erklärt

Claude Code besitzt äußerst leistungsstarke Dateioperations- und Befehlsausführungsfähigkeiten. Berechtigungen (permissions) ermöglichen es, diese Kraft sicher zu kontrollieren. Gehen Sie über den „irgendwie funktioniert es schon”-Zustand hinaus und entwerfen Sie einen Claude Code, der genau wie beabsichtigt arbeitet.

Dieser Artikel erklärt alle Einstellungsoptionen in .claude/settings.json, Hook-Implementierungsmuster und umgebungsspezifisches Berechtigungsdesign anhand von funktionierendem Code.

Überblick über Berechtigungen

Claude Code-Berechtigungen werden auf 3 Ebenen gesteuert.

Ebene	Schlüssel	Verhalten
Erlauben	`allow`	Wird automatisch ohne Bestätigungsdialog ausgeführt
Fragen	`ask`	Erfordert jedes Mal eine Benutzergenehmigung
Verweigern	`deny`	Kann überhaupt nicht ausgeführt werden (wird mit Fehler abgewiesen)

Einstellungen werden offiziell über settings.json verwaltet. Nutzen Sie ~/.claude/settings.json für benutzerweite Einstellungen, .claude/settings.json für teamgeteilte Projekteinstellungen und .claude/settings.local.json für persönliche Overrides. ~/.claude.json kann weiterhin Zustand wie MCP enthalten, aber Berechtigungsregeln sollten als settings.json-Konfiguration behandelt werden.

Priorität (höchste zuerst):
Managed settings
    > Kommandozeilenargumente
        > Local .claude/settings.local.json
            > Project .claude/settings.json
                > User ~/.claude/settings.json

Permission rules werden über Scopes hinweg zusammengeführt und in der Reihenfolge deny -> ask -> allow ausgewertet

Grundstruktur von settings.json

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm run *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force*)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)"
    ]
  },
  "hooks": {
    "PreToolUse": [],
    "PostToolUse": []
  }
}

Toolnamen und Mustersyntax

Berechtigungen werden im Format „Toolname(Argumentmuster)” geschrieben.

Wichtigste Tool-Liste

Toolname	Beschreibung
`Read`	Datei lesen
`Write`	Neue Dateien erstellen
`Edit`	Teilweise Änderung bestehender Dateien
`Bash`	Shell-Befehlsausführung
`Glob`	Dateimustersuche
`Grep`	Inhaltssuche
`WebFetch`	URL abrufen
`Agent`	Sub-Agenten starten

Mustersyntax

"Read(**)"          // Lesen aller Dateien erlauben
"Read(src/**)"      // Nur unter src/ erlauben
"Read(*.md)"        // Nur .md-Dateien erlauben
"Bash(npm run *)"   // Nur Befehle erlauben, die mit npm run beginnen
"Bash(git *)"       // Alle git-Befehle erlauben
"Bash(rm -rf *)"    // rm -rf verweigern

** passt auf alle Pfade einschließlich Verzeichnisse; * passt auf ein einzelnes Segment.

Praktische Muster

Muster 1: Solo-Entwicklung (relativ freizügig)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm *)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(git add*)",
      "Bash(node *)",
      "Bash(echo *)",
      "Bash(cat *)",
      "Bash(ls *)"
    ],
    "deny": [
      "Bash(rm -rf /)",
      "Bash(rm -rf ~*)",
      "Bash(git push --force *main*)",
      "Bash(git push --force *master*)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Bash(rm *)"
    ]
  }
}

Muster 2: Team-Entwicklung (sicherheitsorientiert)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm run lint)",
      "Bash(npm run test)",
      "Bash(npm run typecheck)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(git branch*)"
    ],
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Bash(git push -f*)",
      "Bash(git reset --hard*)",
      "Bash(git rebase *main*)",
      "Bash(git rebase *master*)",
      "Bash(DROP *)",
      "Bash(TRUNCATE *)",
      "Bash(curl * | bash)",
      "Bash(wget * | sh)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Bash(git add*)",
      "Bash(npm install*)",
      "Bash(*deploy*)"
    ]
  }
}

Muster 3: Produktionsumgebung (nur lesen)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(git show*)",
      "Bash(cat *)",
      "Bash(ls *)",
      "Bash(ps *)",
      "Bash(df *)",
      "Bash(top *)"
    ],
    "deny": [
      "Write(**)",
      "Edit(**)",
      "Bash(git push*)",
      "Bash(git commit*)",
      "Bash(git reset*)",
      "Bash(rm *)",
      "Bash(mv *)",
      "Bash(*deploy*)",
      "Bash(*restart*)",
      "Bash(*kill *)"
    ],
    "ask": []
  }
}

Für produktionsnahe Worktrees oder Repositories legen Sie diese Konfiguration als aktives .claude/settings.json ab und starten mit claude --permission-mode plan oder einem vorab genehmigten dontAsk. Das folgt dem offiziellen Scope- und Permission-Mode-Modell besser als ein alternatives Settings-File per Umgebungsvariable auszutauschen.

Muster 4: Nur Inhaltserstellung (das auf dieser Website verwendete Muster)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Write(site/src/content/**)",
      "Write(content/**)",
      "Edit(site/src/content/**)",
      "Edit(content/**)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(node scripts/*)",
      "Bash(QIITA_TOKEN=* node scripts/qiita-publish.mjs)"
    ],
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Edit(.env*)",
      "Read(.env*)"
    ],
    "ask": [
      "Bash(git add*)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Bash(bash scripts/deploy.sh*)"
    ]
  }
}

Der Schlüssel ist, Schreibzugriffe auf ein bestimmtes Verzeichnis zu beschränken, wie bei Write(site/src/content/**).

Hooks: Prozesse vor und nach Berechtigungen ausführen

Hooks sind ein Mechanismus, der vor und nach der Tool-Ausführung automatisch Befehle ausführt. Sie können für Sicherheitsprüfungen und automatische Formatierung verwendet werden.

PreToolUse: Hook vor der Ausführung

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git add*)",
        "hooks": [{
          "type": "command",
          "command": "git diff --cached --name-only | grep -E '^\\.env' && echo '🚨 .env-Hinzufügung erkannt!' && exit 1 || exit 0"
        }]
      },
      {
        "matcher": "Bash(git commit*)",
        "hooks": [{
          "type": "command",
          "command": "node scripts/secret-scan.mjs"
        }]
      },
      {
        "matcher": "Bash(rm*)",
        "hooks": [{
          "type": "command",
          "command": "echo '⚠️ Löschbefehl erkannt. Ausführung in 5 Sekunden. Ctrl+C zum Abbrechen.' && sleep 5"
        }]
      }
    ]
  }
}

Wenn ein Hook-Befehl Exit-Code 1 zurückgibt, wird die Tool-Ausführung blockiert. Das ist der wichtigste Punkt.

PostToolUse: Hook nach der Ausführung

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "npx tsc --noEmit 2>&1 | head -20 || true"
        }]
      },
      {
        "matcher": "Bash(git commit*)",
        "hooks": [{
          "type": "command",
          "command": "git log --oneline -3"
        }]
      }
    ]
  }
}

PostToolUse wird für Prüfungen nach der Ausführung und Nebeneffekte verwendet – zum Beispiel automatische Typprüfung nach Dateibearbeitungen oder Anzeige der letzten 3 Log-Einträge nach einem Commit.

Praktische Hooks-Rezeptsammlung

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(npm install*)",
        "hooks": [{
          "type": "command",
          "command": "echo '📦 Paket wird hinzugefügt. Bitte package.json prüfen.'"
        }]
      },
      {
        "matcher": "Bash(*deploy*)",
        "hooks": [{
          "type": "command",
          "command": "read -p '🚀 Deployment wird gestartet. Fortfahren? [y/N] ' ans && [ \"$ans\" = 'y' ] || exit 1"
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write(*.ts)|Edit(*.ts)",
        "hooks": [{
          "type": "command",
          "command": "npx eslint --fix $CLAUDE_TOOL_INPUT_FILE_PATH 2>/dev/null || true"
        }]
      }
    ]
  }
}

Berechtigungsmodi: Berechtigungsebene beim Start

Sie können den Modus auch beim Starten des claude-Befehls angeben.

# Normaler Modus (folgt settings.json)
claude

# Alle Operationen automatisch genehmigen (gefährlich! nur für vertrauenswürdige Umgebungen)
claude --dangerously-skip-permissions

# Nur bestimmte Operationen überspringen
claude --allowedTools "Read,Grep,Glob"

# Nicht-interaktiver Modus (in CI/CD verwendet)
claude -p "Tests ausführen und Ergebnisse melden" --dangerously-skip-permissions

--dangerously-skip-permissions sollte nur für CI/CD-Automatisierung oder vollständig verstandene Automatisierungsskripte verwendet werden und in der täglichen interaktiven Nutzung vermieden werden.

2026: Sicheres Permission Budget und Team-Review

Permission Budget ist hier kein offizieller Funktionsname. Gemeint ist die enge Grenze dessen, was Claude Code in der ersten realen Nutzungswoche automatisch ausführen darf. Nach den offiziellen Docs vom 1. Juni 2026 werden permission rules in der Reihenfolge deny -> ask -> allow ausgewertet. PreToolUse-Hooks können Laufzeitprüfungen ergänzen, überschreiben aber keine bereits passende deny- oder ask-Regel. Das erste Budget sollte deshalb Rückrollbarkeit vor Tempo stellen.

Ein sicheres Startbudget ist klein. In allow gehören nur Lesen und Verifikation: Read, Glob, Grep, git status, git diff, git log, npm run lint und npm run test. In ask gehören Operationen mit Absichtswechsel: Edit, Write, git add, git commit, git push, npm install und Deploy-Befehle. In deny gehören irreversible oder sensible Aktionen: .env, secrets/**, rm -rf, git reset --hard, git push --force, curl | bash, wget | sh und Produktionsdatenbank-Befehle. bypassPermissions gehört nur in wegwerfbare Container, VMs oder devcontainers.

Im Team wird .claude/settings.json wie Anwendungscode reviewed. Jede PR muss drei Fragen beantworten: Ist jede allow-Regel auch bei wiederholter Ausführung harmlos, markiert jede ask-Regel einen echten menschlichen Kontrollpunkt, und deckt deny Secrets, Force Push, Löschen und Produktion ab? In verwalteten Organisationen können Admins über server-managed settings disableBypassPermissionsMode und disableAutoMode auf "disable" setzen und mit allowManagedPermissionRulesOnly lokale oder Projekt-Regeln blockieren.

Ein gefährliches Fehlmuster ist ein breites Bash(git *) oder Bash(node *), während man glaubt, Read(.env*) reiche für Secrets. Die offiziellen Docs stellen klar, dass Read/Edit-Deny-Regeln für Claude Codes Dateiwerkzeuge und erkannte Dateibefehle gelten, aber nicht für beliebige Unterprozesse, etwa Node- oder Python-Skripte, die Dateien direkt öffnen. Für echte Secret-Sicherheit vermeiden Sie breite Bash-Allows und kombinieren Regeln mit Sandbox, Betriebssystemrechten und PreToolUse-Checks.

Der Rollback-Pfad gehört vor den Vorfall. Bei unerwünschten Edits prüfen Sie zuerst mit /permissions die aktive Regel und Quelle, lesen git diff und setzen mit git restore -p nur die schlechten Hunks zurück. Für untracked files verwenden Sie zuerst git clean -n. Wenn ein Secret gelesen worden sein könnte, reicht eine Settings-Korrektur nicht: der Token muss rotiert werden.

Wenn dieser Artikel zu einer Repo-Policy werden soll, starten Sie mit permission budget loop und permission audit checklist. Für Vorlagen und Lernmaterial vergleichen Sie die Claude Code Produkte. Für Team-Rollout, Permission-Review und sicheres Onboarding ist die Beratung der bessere nächste Schritt als allein Regeln zu erraten.

Priorität und Überschreibung von Konfigurationsdateien

Wenn mehrere Konfigurationsdateien vorhanden sind:

~/.claude/settings.json     ← User (für alle Projekte)
.claude/settings.json       ← Project (git-verwaltet)
.claude/settings.local.json ← Local (persönlich, gitignored)
managed-settings.json       ← Managed (Organisationspolicy, höchste Priorität)

Permission rules werden zusammengeführt, und deny wird immer vor allow ausgewertet

Schreiben Sie persönliche Zusatzeinstellungen in .claude/settings.local.json und fügen Sie es zu gitignore hinzu. Um zu verhindern, dass Team-Deny-Listen durch persönliche Einstellungen überschrieben werden, ist es sicheres Design, Deny-Regeln nur in settings.json zu schreiben.

# Zu .gitignore hinzufügen
.claude/settings.local.json

Die 5 häufigsten Fallstricke

1. Platzhaltermuster falsch verwenden

// ❌ Dies passt nur auf den einzelnen Befehl "git"
"Bash(git)"

// ✅ Passt auch auf git gefolgt von Argumenten
"Bash(git *)"
"Bash(git*)"  // Funktioniert auch ohne Leerzeichen, aber explizites * ist sicherer

2. Vergessen, dass deny Vorrang vor ask hat

// Mit dieser Konfiguration wird Bash(rm -rf /tmp/test) von deny abgefangen und blockiert
// Es erreicht ask nie
{
  "deny": ["Bash(rm -rf*)"],
  "ask": ["Bash(rm*)"]  // ← rm -rf wird von deny behandelt
}

3. Exit-Codes von Hooks nicht beachten

# Wenn der PreToolUse-Hook-Befehl immer exit 0 zurückgibt,
# blockieren Scan-Fehler die Ausführung nicht

# ❌ Läuft auch bei Fehler durch
"command": "node scan.mjs"

# ✅ Exit-Code explizit steuern
"command": "node scan.mjs || exit 1"

4. settings.json versehentlich in .gitignore aufnehmen

Manche Teams fügen settings.json—das sie teilen möchten—versehentlich zu .gitignore hinzu. Der richtige Ansatz ist Projekteinstellungen unter git, nur settings.local.json in gitignore.

5. Vergessen, die Produktionskonfiguration manuell zu wechseln

# ❌ In der Produktion mit Alltagseinstellungen arbeiten

# ✅ Im plan mode starten und das .claude/settings.json des Worktrees produktionssicher halten
claude --permission-mode plan

Ein Alias macht es schwerer zu vergessen:

# ~/.bashrc or ~/.zshrc
alias claude-prod='claude --permission-mode plan'

Konfiguration debuggen

Wenn unklar ist, „warum wird dieser Befehl blockiert”:

# Aktuelle Einstellungen prüfen
claude --print-settings 2>/dev/null || cat .claude/settings.json

# Prüfen, welche Regel übereinstimmt (ausführlicher Modus)
claude --verbose -p "git push ausführen"

Zusammenfassung: Best Practices für das Berechtigungsdesign

1. Zuerst deny festlegen
   → Befehle auflisten, die niemals ausgeführt werden sollen
   → rm -rf, git push --force, DROP TABLE sind unverzichtbar

2. Dann ask konfigurieren
   → Schreib- und Deploy-Operationen, die Bestätigung erfordern

3. Den Rest allow geben
   → Lese- und CI-Operationen: alles allow für Effizienz

4. Sicherheit mit Hooks automatisieren
   → Pre-Commit-Scanning, automatische Typprüfung nach Bearbeitungen

5. Umgebungsspezifische Konfigurationsdateien vorbereiten
   → settings.json (Entwicklung), settings.production.json (Produktion)

Mit richtigen Berechtigungseinstellungen werden Sie aufhören, mechanisch auf Genehmigungsschaltflächen zu klicken, und sich nur noch auf Operationen konzentrieren können, die wirklich überprüft werden müssen. 30 Minuten Design im Voraus machen Hunderte zukünftiger Arbeitsstunden sicherer.