Claude Code Berechtigungen: settings.json sicher einrichten

Claude Code soll nur einen Test ausführen, fragt aber bei jedem Befehl erneut nach. Wird stattdessen ganz Bash freigegeben, können auch ein erzwungener Push oder ein destruktiver Löschbefehl ohne die erwartete Kontrolle in Reichweite geraten.

Zwischen ständigen Rückfragen und unbegrenztem Zugriff gibt es einen praktikablen Mittelweg: Lesen und Tests automatisch erlauben, vor Änderungen und externen Aktionen nachfragen und Zugriffe auf Secrets sowie destruktive Befehle sperren. Diese drei Ebenen werden in settings.json festgelegt.

Das Wichtigste in Kürze

Regeln werden in der Reihenfolge deny → ask → allow ausgewertet. Eine spezifische allow-Regel setzt eine passende deny- oder ask-Regel nicht außer Kraft.
Lesen im Projekt ist bereits ohne Rückfrage möglich. Nur geprüfte Tests gehören in allow, Änderungen, externe Zugriffe und Pushes in ask, Secrets und destruktive Aktionen in deny.
Bash(git *) ist für die meisten Repositories zu weit gefasst. Die Regel erfasst auch git reset --hard und git push --force.
Read(.env) hindert nicht jeden Kindprozess daran, die Datei zu öffnen. Für eine vom Betriebssystem erzwungene Isolation wird zusätzlich die Sandbox benötigt.
Nach einer Änderung zeigen /permissions und /status, welche Regeln und Einstellungsquellen tatsächlich aktiv sind.

Was Claude Code übernehmen darf und was ein Mensch entscheidet

Claude Code überlassen	Menschliche Freigabe	Immer sperren
Dateisuche, Diff-Prüfung, Tests	Dateiänderungen, Commits, Pushes, neue Abhängigkeiten	Secret-Zugriffe, Force Pushes, Hard Resets, massenhaftes Löschen
`Read`, `Grep`, `git diff`	`Edit`, `git commit`, `npm install`	`.env`, `git push --force`, `git reset --hard`, `rm -rf`

Schwer rückgängig zu machende Aktionen, externe Übertragungen und Zugriffe auf Zugangsdaten gehören in ask oder deny.

Mit dieser settings.json beginnen

Legen Sie im Stammverzeichnis des Repositories .claude/settings.json an. Die folgende Konfiguration ist ein bewusst zurückhaltender Ausgangspunkt für ein Team.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(npm test *)",
      "Bash(npm run lint *)"
    ],
    "ask": [
      "Edit",
      "WebFetch",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git push *)",
      "Bash(git clean *)",
      "Bash(git restore *)",
      "Bash(npm install *)",
      "Bash(npm uninstall *)"
    ],
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/secrets/**)",
      "Edit(.env)",
      "Edit(.env.*)",
      "Edit(**/secrets/**)",
      "Bash(git push --force *)",
      "Bash(git reset --hard *)",
      "Bash(rm -rf *)",
      "Bash(rm *)",
      "PowerShell(Remove-Item *)"
    ]
  }
}

Diese Basis setzt voraus, dass Sie die Skripte in package.json geprüft haben. Lassen Sie bei einem unbekannten Repository allow leer, bis klar ist, was der Testbefehl tatsächlich ausführt. Bash(npm test *) erfasst npm test und Varianten mit Argumenten.

Der richtige Ort für settings.json

Geltungsbereich	Pfad	Zweck
User	`~/.claude/settings.json`	Eigene Standardregeln für alle Projekte
Project	`.claude/settings.json`	Mit Git geteilte Teamregeln
Local	`.claude/settings.local.json`	Persönliche Regeln für diesen Rechner; nicht committen
Managed	Von Administratoren verteilte Einstellungen	Organisationsregeln, die nicht überschrieben werden können

Die Reihenfolge lautet Managed, Kommandozeile, Local, Project und User. Arrays wie permissions.allow werden über Quellen hinweg zusammengeführt, nicht komplett ersetzt. Eine passende deny-Regel wird vor ask und allow geprüft. Gemeinsame Schutzregeln gehören in Project, unverhandelbare Richtlinien in Managed Settings.

allow, ask und deny richtig lesen

Regel	Bedeutung
`Read`	Erfasst jeden eingebauten Lesezugriff; ein pauschales allow ist im Projekt normalerweise unnötig
`Bash(npm test)`	Passt exakt auf `npm test`
`Bash(npm test *)`	Passt auf `npm test` mit oder ohne weitere Argumente
`Bash(ls*)`	Passt auf `ls -la`, aber auch auf `lsof`, und ist deshalb unerwartet weit
`Read(//Users/me/secrets/**)`	Verwendet einen absoluten Dateisystempfad
`Edit(/src/*/.ts)`	Bezieht sich in Project Settings auf Dateien unterhalb von `src` im Repository
`WebFetch(domain:docs.anthropic.com)`	Erfasst WebFetch-Aufrufe an diese Domain

Bash(git *) schließt auch git push origin main und git reset --hard ein. Geben Sie sichere Befehle einzeln frei, statt die gesamte Befehlsfamilie zu erlauben.

Warum Read und Edit Secrets nicht vollständig schützen

Pfade in Read- und Edit-Regeln folgen der gitignore-Syntax.

Muster	Bezugspunkt	Beispiel
`//path`	Wurzel des Dateisystems	`Read(//Users/me/secrets/**)`
`~/path`	Home-Verzeichnis	`Read(~/.ssh/**)`
`/path`	Ort der Einstellungsquelle	In Project Settings zielt `Edit(/src/**)` auf `src` im Repository
`path` oder `./path`	Aktuelles Arbeitsverzeichnis	`Read(.env)`

Ein einzelner führender Schrägstrich bezeichnet bei Read- und Edit-Regeln keinen absoluten Dateisystempfad. Noch wichtiger: Die Regeln greifen bei den eingebauten Dateiwerkzeugen von Claude Code und bei erkannten Dateibefehlen. Ein beliebiger Node.js- oder Python-Kindprozess kann eine Datei weiterhin direkt öffnen.

Wenn das Repository Zugangsdaten enthält, kombinieren Sie die Regeln mit dem Leitfaden zu Freigaben und Sandbox in Claude Code. So begrenzt auch das Betriebssystem die Kindprozesse.

Drei Praxisfälle

Use case 1: In einem persönlichen Projekt nur Tests automatisieren

Eingabe: Quellcode, Tests und Git-Diff. Ausgabe: Änderungsvorschlag und Testergebnis. Entscheidung des Menschen: Änderungen, neue Abhängigkeiten, Commit und Push.

Beginnen Sie mit der Basiskonfiguration und lassen Sie Änderungen in ask. Verschieben Sie einen Befehl erst dann nach allow, wenn er wiederholt ohne externe Zustandsänderung gelaufen ist.

Use case 2: Gefährliche Operationen im Team gemeinsam sperren

Eingabe: benötigte Befehle und grundsätzlich unerwünschte Aktionen. Ausgabe: eine mit Git verwaltete Berechtigungsrichtlinie. Entscheidung des Menschen: neue deny-Regeln und Ausnahmefälle bei Wartungsarbeiten.

Die Sperren für .env, Force Push, Hard Reset und rekursives Löschen bleiben in den Project Settings. Regeln, die Teammitglieder nicht verändern dürfen, werden in Managed Settings verschoben.

Use case 3: Ein Produktions-Repository nur untersuchen

Eingabe: Störungsprotokolle und Git-Verlauf. Ausgabe: mögliche Ursachen und ein Maßnahmenplan. Entscheidung des Menschen: Änderungen, Deployment und externe Kommunikation.

Starten Sie die Sitzung im Plan Mode:

claude --permission-mode plan

Wird ein Schreibzugriff nötig, wechseln Sie vor der Freigabe in einen isolierten Worktree oder eine wegwerfbare Umgebung.

Vier konkrete Fehler und ihre Korrektur

Fehler	Ursache	Korrektur
`Bash(git *)` erlauben	Das Muster umfasst auch Push und Hard Reset	Nur Befehle mit geprüften Nebenwirkungen erlauben
`allow: Bash(aws s3 ls)` unter `deny: Bash(aws *)` ergänzen	Deny gewinnt vor ask und allow; Spezifität erzeugt keine Ausnahme	Deny enger fassen oder den sicheren Vorgang hinter einen eigenen Befehl legen
`Read(.env)` als Betriebssystemgrenze behandeln	Beliebige Node.js- oder Python-Prozesse werden nicht vollständig blockiert	Sandbox `denyRead` oder Credentials-Regeln ergänzen
Local allow löschen, Befehl läuft weiter	Arrays aus User, Project und Local werden zusammengeführt	Quelle in `/permissions`, geladene Ebenen in `/status` prüfen

Die Claude Code Sicherheitsfehler zeigen Vorfälle; die Security Best Practices liefern die vollständige Einführungsprüfung.

Den passenden permission mode wählen

Modus	Geeignet für	Wichtige Grenze
`default`	Ein noch unbekanntes Repository	Fragt nach, wenn eine Freigabe erforderlich ist
`acceptEdits`	Entwicklung mit bereits verstandenem Änderungsumfang	Dateiänderungen und übliche Dateisystemoperationen können automatisch freigegeben werden
`plan`	Untersuchung, Planung und lesende Produktionsanalyse	Ändert keine Quelldateien
`auto`	Testbetrieb mit Sicherheitsprüfungen im Hintergrund	Gibt zur Anfrage passende Aufrufe automatisch frei; Verhalten der eingesetzten Version prüfen
`dontAsk`	Unbeaufsichtigte Arbeit mit vorab genehmigten Operationen	Lehnt nicht freigegebene Tools ab, statt nachzufragen
`bypassPermissions`	Wegwerfbarer Container oder VM	Nicht auf einem normalen Arbeitsplatzrechner oder Produktionssystem verwenden

Bei aktivierter Sandbox steht sandbox.autoAllowBashIfSandboxed standardmäßig auf true. Befehle innerhalb der Sandbox können deshalb ohne eine pauschale Bash-Rückfrage laufen. Inhaltsbezogene ask-Regeln wie Bash(git push *) fragen weiterhin nach, ausdrückliche deny-Regeln bleiben wirksam und der Plan Mode behält seine eigenen Einschränkungen.

Pitfall: breite Freigabe mit nur einem Hook absichern

Wer ganz Bash erlaubt und erwartet, dass ein PreToolUse-Hook jede gefährliche Variante erkennt, macht diesen einen Hook zur einzigen Sicherheitsgrenze. Ein falsch geladener Hook oder ein unvollständiges Muster öffnet dann eine sehr große Befehlsfläche.

Ursache: Der erlaubte Bereich ist breit, während eine dynamische Prüfung die einzige Kontrolle darstellt.

Korrektur: Zuerst ausdrückliche deny-Regeln und enge allow-Regeln schreiben. Hooks dienen nur als zusätzliche Schicht für Entscheidungen, die wirklich vom Laufzeitkontext abhängen. Das allow-Ergebnis eines Hooks überschreibt keine passende deny- oder ask-Regel.

Kopierbarer Konfigurationscheck

Das folgende Skript prüft, ob .claude/settings.json gültiges JSON enthält und ob vier grundlegende deny-Regeln vorhanden sind.

// scripts/check-claude-permissions.mjs
import { readFileSync } from "node:fs";

const path = ".claude/settings.json";
const settings = JSON.parse(readFileSync(path, "utf8"));
const deny = new Set(settings.permissions?.deny ?? []);
const required = [
  "Read(.env)",
  "Edit(.env)",
  "Bash(git push --force *)",
  "Bash(git reset --hard *)",
  "Bash(rm *)",
  "PowerShell(Remove-Item *)",
];

const missing = required.filter((rule) => !deny.has(rule));
if (missing.length > 0) {
  console.error(`Fehlende deny-Regeln: ${missing.join(", ")}`);
  process.exit(1);
}

console.log("Mindestprüfung der Berechtigungen: OK");

node scripts/check-claude-permissions.mjs

Der Check beweist nicht, dass die gesamte Konfiguration sicher ist. Er erkennt in CI lediglich, wenn eine der grundlegenden deny-Regeln entfernt wurde.

Wenn die Einstellungen scheinbar nicht greifen

In /permissions jede Regel und ihre Quelldatei prüfen.
Mit /status kontrollieren, welche Einstellungsebenen geladen wurden.
Leerzeichen und Anker wie Bash(ls *) gegenüber Bash(ls*) sowie /path gegenüber //path prüfen.
Die automatische Sandbox-Freigabe und deny- oder ask-Regeln aus höher priorisierten Quellen kontrollieren.
Gemeinsam benötigte Regeln aus temporären CLI-Einstellungen zurück nach .claude/settings.json verschieben.

Zusammenfassung

Legen Sie .claude/settings.json an und prüfen Sie sie mit /permissions. Nur geprüfte Tests kommen in allow, Änderungen und externe Aktionen in ask, Secrets und destruktive Befehle in deny.

Wiederverwendbare Berechtigungsvorlagen zusammen mit weiteren Entwicklungsrichtlinien finden Sie in den Claude Code Produktleitfäden.

Offizielle Quellen

Was tatsächlich getestet wurde

Am 22. Juli 2026 wurden die JSON-Blöcke aller zehn Sprachen mit JSON.parse gelesen und der Node.js-Check in einem temporären Projekt ausgeführt. Mit sechs erforderlichen deny-Regeln war der Exit-Code 0; ohne Bash(git reset --hard *) war er 1 und nannte die fehlende Regel. Der Test erkennt Konfigurationsdrift, beweist aber keine sichere Richtlinie. Prüfen Sie /permissions und /status in Ihrer Umgebung.