Berechtigungsregeln in Claude Code werden von der Agent-Laufzeit erzwungen, nicht vom Modell selbst. Dieser Unterschied ist wichtiger als er klingt. Anweisungen in Ihrem Prompt oder CLAUDE.md prägen, was Claude versucht zu tun, aber sie ändern nicht, was Claude Code tatsächlich erlaubt, wie die offizielle Berechtigungsdokumentation verdeutlicht. Um Zugriff zu gewähren oder zu widerrufen, verwenden Sie /permissions, die unten beschriebenen Einstellungsdateien, einen Berechtigungsmodus oder einen PreToolUse Hook. Dieser Beitrag durchläuft jede Ebene: Auswahl eines Modus, Verständnis von Precedence, Schreiben einer funktionierenden Richtliniendatei, Testen und Wissen, wo das gesamte System Ihnen nicht helfen kann.
Wählen Sie einen Berechtigungsmodus
Der Modus, den Sie wählen, legt die Grundlage für alles andere fest. Es gibt fünf.
Manual stoppt Claude Code vor den meisten Dateibearbeitungen, Shell-Befehlen und Netzwerkaufrufen. Sie bestätigen jeden einzeln. Langsam, aber nichts überrascht Sie.
Auto übergibt die Genehmigung an ein Klassifizierungsmodell, das Aktionen in Ihrem Namen überprüft. Bei Pro-, Max- und Team-Plänen ist dies der standardmäßig verfügbare Modus, gemäß der Berechtigungsmodus-Dokumentation. Der Klassifizierer hat seine eigenen Regeln darüber, welche Aktionen er überprüft und welche er überspringt, daher ist Auto nicht dasselbe wie „alles genehmigen".
Accept Edits genehmigt Dateivorgänge automatisch, fragt aber weiterhin nach Shell-Befehlen. Ein vernünftiger Mittelweg für Solo-Arbeit an einer Codebasis, die Sie verstehen.
Plan blockiert Dateibearbeitungen und Shell-Schreibvorgänge vollständig. Claude kann lesen, begründen und einen Plan ausgeben, kann aber nicht handeln. Gut für Bewertungen in frühen Phasen, wenn Sie den Ansatz sehen möchten, bevor sich etwas ändert.
dontAsk verweigert automatisch jedes Tool, das nicht auf Ihrer expliziten Allow-Liste steht. Keine Eingabeaufforderung, nur eine stille Verweigerung. Dies ist der richtige Modus für CI/CD-Pipelines, bei denen niemand zusieht.
bypassPermissions überspringt alle Prüfungen. Claude führt aus, was es will. Nützlich in Sandbox-Wurf-Umgebungen; nicht etwas, das gegen ein Production-Repo läuft.
Um den Startmodus in VS Code festzulegen, setzen Sie claudeCode.initialPermissionMode in Ihren Benutzereinstellungen auf default, manual, acceptEdits, plan oder bypassPermissions. Hinweis: Die Einstellung akzeptiert nicht auto. Um in Auto zu starten, lassen Sie sie ungesetzt und wählen Sie sie einmal aus dem Modus-Indikator; die Erweiterung merkt sich diese Wahl für nachfolgende Gespräche.
Setzen Sie für Terminal-Sitzungen permissions.defaultMode in ~/.claude/settings.json oder in verwalteten Einstellungen. Dieser Wert gilt für Pro-, Max- und Team-Pläne, wenn Feature-Flag-Abruf verfügbar ist.
Ein bekannter Grenzfall: Wenn Ihre Organisation ein claude.ai Connector-Tool auf ask gesetzt hat, treten Allow-Regeln für dieses Tool nicht einmal in auto oder bypassPermissions Modi in Kraft. Claude Code fordert bei jedem Aufruf auf. Im dontAsk Modus wird der Aufruf stattdessen verweigert.
Wie Regeln und Einstellungs-Precedence funktionieren
Fünf Ebenen, von oben nach unten ausgewertet. Eine höhere Ebene gewinnt.
- Verwaltete Einstellungen (
managed-settings.json): IT-bereitgestellt, nicht überschreibbar. Wenn Ihre Organisation SSH hier blockiert, ist das endgültig. - Lokale Einstellungen (
.claude/settings.local.json): pro-Maschine, standardmäßig gitignored. Persönliche oder sicherheitsempfindliche Overrides gehen hier hin. - Projekteinstellungen (
.claude/settings.json): committed ins Repository. Werden im ganzen Team für dieses Projekt geteilt. - Benutzereinstellungen (
~/.claude/settings.json): globale Standardwerte, angewendet auf jedes Projekt, sofern eine höhere Ebene sie nicht überschreibt. - Session-Flags:
--dangerously-skip-permissionsund ähnliche Runtime-Argumente.
Die Admin-Setup-Dokumentation enthält zwei Lockdown-Controls, die es wert sind, bekannt zu sein: allowManagedPermissionRulesOnly (macht verwaltete Einstellungen zur einzigen Quelle von Berechtigungsregeln und ignoriert Benutzer- und Projektdateien) und permissions.disableBypassPermissionsMode (entfernt die Bypass-Option vollständig). Wenn Sie eine Agentur mit Vertragsnehmern betreiben, die Client-Repos berühren, geben Ihnen diese beiden Einstellungen zusammen eine harte Obergrenze, die kein Entwickler stillschweigend rückgängig machen kann.
Jede Ebene akzeptiert drei Regeltypen: allow, deny und ask. Innerhalb einer Ebene schlägt deny allow. Shell-Pattern-Matching wird unterstützt (zum Beispiel Bash(git *)), aber seien Sie präzise: Ein Pattern, das in Tests wasserdicht aussieht, hat oft Lücken, wenn sich die tatsächlichen Befehlszeichenfolgen von dem unterscheiden, was Sie erwartet haben.
Eine Sache, die die Docs explizit kennzeichnen: WebFetch zu verweigern blockiert Claudes Fetch-Tool, aber wenn Bash erlaubt ist, können curl und wget trotzdem jede URL erreichen. Sandboxing (über /sandbox) schließt diese Lücke mit einer auf OS-Ebene erzwungenen Domain-Allowlist. Berechtigungen und Sandboxing decken verschiedene Schichten ab und Sie möchten im Normalfall beides für alles, das ernsthaft ist.
Ein Client-Repository-Policy-Beispiel
Hier ist eine veranschaulichende .claude/settings.json für ein Client-Projekt, in dem das Team Builds ausführen und die Datenbank lesen kann, aber Deployment-Skripte oder Secrets nicht anfassen sollte. Das ist eine beispielhafte Struktur, keine Copy-Paste-Produktionspolicy.
{
"permissions": {
"defaultMode": "auto",
"allow": [
"Bash(npm run build)",
"Bash(npm run test*)",
"Bash(git log*)",
"Bash(git diff*)",
"Bash(git status)",
"Read(**)"
],
"deny": [
"Bash(rm -rf*)",
"Bash(git push*)",
"Bash(kubectl*)",
"Edit(.env*)",
"Edit(deploy/**)"
]
}
}
Daneben kümmert sich eine ~/.claude/settings.json auf dem Machine jedes Entwicklers um persönliches globales Vertrauen, wie das Erlauben von curl für allgemeine Nutzung. Sensitive Credentials oder Machine-spezifische Pfade gehören in .claude/settings.local.json, die git nicht committed.
Für die CLAUDE.md-Seite, auf der Sie Konventionen und Projektkontext statt Durchsetzungsregeln setzen, behandelt der Agentur-Leitfaden zu CLAUDE.md den Authoring-Workflow im Detail.
Testen Sie die Policy mit realistischen Befehlen
Legen Sie die Policy in ein wegwerfbares Repository (ein bloßes git init in einem Temp-Verzeichnis funktioniert gut), dann führen Sie eine Handvoll Befehle aus, die alle drei Regelkategorien trainieren. Das Ziel ist zu sehen, welche einen Prompt erzeugen, welche stillen Ausführen und welche ohne Prompt verweigert werden.
Eine beispielhafte Test-Sequenz:
npm run build(sollte Auto-Genehmigung erhalten, es steht auf der Allow-Liste)git diff HEAD~1(sollte Auto-Genehmigung erhalten)git push origin main(sollte verweigert werden)rm -rf node_modules(sollte verweigert werden)- Eine Datei in
deploy/bearbeiten (sollte verweigert werden) src/index.jsbearbeiten (keine Deny-Regel, kein explizites Allow: Verhalten hängt vom Modus ab)- Ein curl-Aufruf zu einer externen URL (testet, wie sich
Bash-Allow-Regeln und Sandbox interagieren)
Achten Sie besonders auf Fall 6. Im auto-Modus prüft der Klassifizier ihn. Im dontAsk-Modus wird er stillschweigend verweigert, weil er nicht auf der Allow-Liste steht. Dieser Unterschied wird Entwickler überraschen, die in einem Modus testen und in einem anderen bereitstellen.
Wenn Sie Event-Level-Automation auf diesem aufbauen (Linter auf Datei-Speichern ausführen, Benachrichtigungen bei bestimmten Tool-Aufrufen auslösen), ist das eher ein Hooks-Anliegen als ein Berechtigungs-Anliegen. Der Hooks-Leitfaden behandelt PreToolUse und PostToolUse vollständig.
Für Teams, die unbeaufsichtigte Ausführungen oder CI-Integration benötigen, sollten Sie erwägen, das Claude Code Agency Setup zu verwenden, um die Konfigurationsgrundlage von Anfang an richtig zu setzen.
Verwaltete Einstellungen und unbeaufsichtigte Aufträge
Wenn kein Mensch da ist, um „genehmigen" anzuklicken, muss das Berechtigungsmodell vollständig vorab deklariert werden. Das führt zu dontAsk-Modus mit einer expliziten Whitelist in verwalteten Einstellungen.
Die Admin-Setup-Dokumentation zeigt Ihnen permissions.defaultMode als verwalteten Schlüssel dafür. Setzen Sie ihn auf dontAsk, und zählen Sie dann genau auf, was der Auftrag in permissions.allow benötigt. Alles, was nicht aufgelistet ist, wird stillschweigend abgelehnt. Das ist das, was Sie in einer Pipeline wollen.
Ein paar Dinge, die die offizielle Dokumentation für Agent-Team-Szenarien vermerkt (wo eine Lead-Session Teamkollegen erzeugt):
- Teammates starten mit den Berechtigungseinstellungen des Leads. Wenn der Lead mit
--dangerously-skip-permissionsläuft, tun das alle Teammates auch. - Sie können individuelle Teammate-Modi nach der Erzeugung ändern, aber nicht zum Zeitpunkt der Erzeugung.
- Teammate-Berechtigungseingabeaufforderungen erscheinen in der Lead-Session. Plan-Genehmigungen sind die konzipierte Ausnahme: Der Lead gewährt diese ohne eine separate Eingabeaufforderung.
Managed Agents (der Orchestrierungsdienst auf Plattformebene) ist derzeit in Beta laut der Managed Agents-Übersicht. Entwerfen Sie keine Produktions-Pipelines um Beta-Features ohne Fallback.
Für die Flagge permissions.disableAutoMode: Das Setzen entfernt Auto-Modus als Option für Entwickler in dieser Organisation. Nützlich, wenn Sie möchten, dass alle Sessions in einem Modus bleiben, in dem ein Mensch oder eine explizite Whitelist jeden Aufruf tätigt, anstatt eines Klassifizierers.
Was Berechtigungen nicht garantieren können
Ehrliche Antwort: Ziemlich viel.
Shell-Pattern-Ablehnungsregeln sind keine Sicherheitsgrenze. Sie werden mit der Befehlszeichenkette verglichen, die Claude Code konstruiert, aber eine hinreichend kreative Prompt-Injection oder eine geschickte Umformulierung eines Shell-Befehls kann Zeichenketten erzeugen, die Ihre Muster nicht erfassen. Die Berechtigungsdokumentation ist explizit: Ablehnungsregeln und Sandboxing decken unterschiedliche Ebenen ab. Sie brauchen beides, und selbst dann reduzieren Sie das Risiko, eliminieren es nicht.
bypassPermissions-Modus macht zugelassenen Code nicht harmlos. Wenn Claude Code ausführt, der einen Bug enthält oder etwas Unerwartetes tut, bedeutet das Überspringen von Berechtigungsprüfungen, dass es kein Tor zwischen „Claude beschloss, es zu tun" und „es passierte" gab.
Berechtigungen prüfen auch nicht, was sich im Code befindet, den Claude schreibt oder ausführt. Eine Abhängigkeit, die es installiert, ein Skript, das es ausführt, der Inhalt einer Datei, die es erstellt: nichts davon wird vom Berechtigungssystem überprüft. Das ist ein separates Anliegen, näher an Supply-Chain-Hygiene als an Laufzeitrichtlinie.
Und das Modell selbst ist nicht die Durchsetzungsebene. Sie können CLAUDE.md-Anweisungen schreiben, die sagen „berühre niemals Production Secrets." Diese Anweisungen prägen Claudes Absicht. Sie verhindern nicht, dass eine falsch konfigurierte Whitelist-Regel es sowieso zulässt. Die Laufzeitumgebung ist die Durchsetzungsebene. Die Einstellungsdateien sind, wie Sie die Laufzeitumgebung konfigurieren. Behandeln Sie sie entsprechend.
FAQ
Synchronisieren sich Berechtigungseinstellungen automatisch zwischen Maschinen?
Nein. Benutzereinstellungen (~/.claude/settings.json) sind auf jede Maschine beschränkt. Projekteinstellungen (.claude/settings.json) werden per Git synchronisiert. Verwaltete Einstellungen werden von Ihrer IT-Infrastruktur verteilt. Es gibt keine integrierte Synchronisierung für Dateien auf Benutzerebene; jeder Entwickler muss seine eigenen konfigurieren.
Können Entwickler verwaltete Einstellungen außer Kraft setzen?
Nur innerhalb der Grenzen, die verwaltete Einstellungen zulassen. Wenn allowManagedPermissionRulesOnly gesetzt ist, werden Benutzer- und Projektberechtigungsregeln vollständig ignoriert. Ohne dieses Flag können Benutzer- und Projekteinstellungen Whitelist-Regeln hinzufügen, können aber einen verwalteten Deny nicht außer Kraft setzen.
Was passiert mit Berechtigungseingabeaufforderungen in Headless- oder CI-Umgebungen?
Im dontAsk-Modus wird alles, was nicht auf der Whitelist steht, stillschweigend abgelehnt. Es erscheint keine Eingabeaufforderung, weil es kein Terminal gibt, um eine anzuzeigen. Das ist Absicht. Im auto-Modus in einer Headless-Umgebung wird der Klassifizierer weiterhin ausgeführt, aber wenn er eine Eingabeaufforderung nicht auflösen kann (kein TTY), hängt das Verhalten von der Runner-Konfiguration ab. Verwenden Sie dontAsk mit einer expliziten Whitelist für unbeaufsichtigte Aufträge.
Gilt der Berechtigungsmodus für MCP-Tools auf die gleiche Weise wie für integrierte Tools?
Größtenteils ja, aber mit Unterschieden. MCP-Tools, die Claude Code direkt abruft, erscheinen als mcp__claude_ai_<server>__<tool>. Allow- und Deny-Regeln können sie unter diesem Namen ansprechen. Tools von Connectoren, die deine Organisation auf „immer fragen" eingestellt hat, fordern dich auf, unabhängig vom Modus – mit Ausnahme des „dontAsk"-Modus, wo sie stattdessen verweigert werden.
Ist es sicher, `.claude/settings.json` in ein öffentliches Repository zu committen?
Die Datei selbst ist nur JSON mit Tool-Namen und Mustern, keine Secrets. Aber eine öffentliche Allow-Liste zeigt jedem, der dein Repository liest, genau, welche Operationen Claude Code ohne Abfrage ausführt. Bei Open-Source-Projekten ist das wahrscheinlich kein Problem. Bei allem, das proprietär ist, überprüfe, was du committen wirst. Secrets und API-Keys sollten niemals in irgendeiner Settings-Datei auftauchen; diese gehören in Umgebungsvariablen außerhalb von Claude Codes Konfiguration.
Das Wichtigste zum Mitnehmen: Deny-Regeln und Sandboxing lösen unterschiedliche Probleme, und keines ersetzt das andere. Richte beides ein, wenn du Claude Code in einer Umgebung einsetzt, in der der Preis eines Fehlers real ist.