Claude-Code-Berechtigungen: Allow-, Deny- und Ask-Regeln erklärt
Ein Durchblick Bild für Bild, wie Claude Code um Erlaubnis bittet: die drei Prompt-Optionen, die Allow-Regeln in settings.local.json, die Auswertungsreihenfolge mit Deny zuerst, die Berechtigungsmodi und die Rezepte, die den Coding-Alltag und die CI seltener anhalten — mit der offiziellen Doku, die jede Lücke der Aufzeichnung füllt.
Claude-Code-Berechtigungen in 60 Sekunden
- Claude Code fragt vor Bash, Edit, WebFetch und Write; Read, Glob, Grep und LS laufen ohne Nachfragen.
- „Yes, and don't ask again“ speichert eine Regel wie Bash(git add:*) in .claude/settings.local.json — Ihr persönliches, aus Git ausgeschlossenes Regelwerk für dieses Repo.
- Regeln werden deny → ask → allow ausgewertet: Ein Deny aus jeder Settings-Datei gewinnt, und keine Allow-Regel kann darin eine Ausnahme herausschneiden.
- Modi dosieren Vertrauen: acceptEdits (alt+m) für editlastige Arbeit, plan für Nur-Lese-Recon, bypassPermissions für die CI via --permission-mode — und defaultMode-Werte auto und bypassPermissions greifen nur aus User- oder Managed-Settings.
Claude Code Tutorial #4 - Tools & Permissions
Video:The Net Ninja4:55
Permission Modes Head to Head
Video:ttywood6:20
Permissions — Claude Code documentation
Docs:code.claude.com
Settings files — Claude Code documentation
Docs:code.claude.com
Jeder Still stammt aus der Net-Ninja-Aufzeichnung, einer sauberen Bildschirmaufnahme ohne Kamera oder Overlays. Die ttywood-Episode, die Berechtigungsmodi direkt vergleicht, diente als Gegenprobe für die Modus- und Rezept-Abschnitte, steuerte aber keine Frames bei — ihre Frames tragen eingebrannte Untertitel. Regel-Syntax, Auswertungsreihenfolge, Modusverhalten und Settings-Priorität sind gegen die beiden offiziellen Dokuseiten geprüft.
Videos © The Net Ninja und ttywood, nur verlinkt. Dokumentation © Anthropic. Screenshots werden in diesem Guide zu Kommentierzwecken referenziert.
Claude-Code-Berechtigungen konfigurieren, Schritt für Schritt
Wonach Claude Code fragt, bevor es handelt
- 1
Sehen Sie, welche Tools einen Berechtigungs-Prompt auslösen
Claude Code wählt seine Tools selbst — Read zum Öffnen von Dateien, Edit zum Ändern, Bash für Shell-Befehle. Anthropics Settings-Doku gibt jedem eine Spalte Permission Required: Bash, Edit, WebFetch und Write halten an und fragen, während Read, Glob, Grep und LS einfach laufen. Tool-Namen tippen Sie nie selbst ein; entscheidend ist, im Voraus zu wissen, welche Aktionen auf Sie warten.
Die Claude-Code-Settings-Doku listet jedes eingebaute Tool mit seinem Permission-Required-Urteil.Ansehen bei 1:05 - 2
Fordern Sie eine Änderung an und sehen Sie zu, wie zuerst gelesen wird
In dem Video ist die Anfrage bewusst klein: eine pastellgelbe --highlight-Variable in src/app/globals.css ergänzen. Claude Code liest die Datei zuerst — Read braucht nie eine Erlaubnis — und hält erst an, wenn es sie ändern will. Diese Trennung ist das gesamte Berechtigungsmodell im Kleinen: Ansehen ist gratis, Anfassen fragt.
Die Highlight-Variable-Anfrage, eingetippt in die Claude-Code-Eingabe in VS Code.Ansehen bei 1:45 - 3
Lesen Sie die drei Optionen, bevor Sie antworten
Jeder Edit-Prompt bietet drei Antworten. 1. Yes genehmigt diese eine Änderung. 2. Yes, and don't ask again this session genehmigt die restlichen Änderungen der Sitzung (alt+m im gezeigten Build). 3. No, and tell Claude what to do differently (esc) lehnt die Änderung ab und lässt Sie steuern. Option 3 ist kein Versagen — so korrigieren Sie den Kurs, bevor Code landet.
Der Edit-Prompt für globals.css mit allen drei Berechtigungsoptionen sichtbar.Ansehen bei 2:17
Einmal Ja sagen: eine Allow-Regel speichern
- 4
Rechnen Sie mit einem Prompt pro Änderung, nicht pro Aufgabe
Die Genehmigung überträgt sich nicht auf die nächste Änderung. Die Demo brauchte drei Yes-Klicks für drei getrennte Änderungen an derselben Datei, und die nächste Änderung fragte wieder. Jedes-mal-fragen funktioniert, skaliert aber schlecht über eine Zwei-Zeilen-Aufgabe hinaus — genau deshalb gibt es Allow-Regeln und Modi.
Eine zweite globals.css-Änderung fragt erneut, direkt nachdem die erste genehmigt wurde.Ansehen bei 2:32 - 5
Bash-Befehle fragen separat
Shell-Befehle bekommen ihr eigenes Tor. Als die Demo Claude einen Commit machen lässt, steht Bash(git add src/app/globals.css) im Zustand Waiting, bis Sie antworten. Ein Ja für einen Befehl ist kein Ja für den nächsten — der folgende git commit fragt eigenständig.
Der git-add-Befehl wartet auf Genehmigung, während frühere Git-Ausgaben darüber wegscrollen.Ansehen bei 3:16 - 6
Lassen Sie „don't ask again“ die Regel für Sie schreiben
Yes, and don't ask again bei git-add-Befehlen zu wählen erledigt zwei Dinge auf einmal: Es entblockt den aktuellen Befehl und speichert eine Regel. Die entstehende Datei ist .claude/settings.local.json im Repo-Root, mit einem permissions-Objekt und einem allow-Array — hier "Bash(git add:*)" — plus leeren deny- und ask-Arrays. Künftige git adds in diesem Projekt laufen ohne Prompt.
settings.local.json unter .claude erstellt, mit der gespeicherten Bash(git add:*)-Allow-Regel.Ansehen bei 3:40 - 7
Regeln von Hand bearbeiten, wenn der Dialog es nicht kann
Das allow-Array ist pures JSON, Sie können also selbst Regeln ergänzen. Nutzen Sie einen exakten String für einen einzelnen Befehl — Bash(npm run test) — und ein angehängtes :* für alles, was genauso beginnt — Bash(npm run test:*). Die Doku bestätigt: :* ist die Kurzform für den End-Wildcard. Halten Sie die Datei persönlich: Claude Code schließt settings.local.json automatisch aus Git aus, und das Video sagt dasselbe — sie ist für Ihren Workflow, nicht fürs Repo.
Die gespeicherte Regel, in permissions.allow markiert, während die Datei von Hand bearbeitet wird.Ansehen bei 4:22
Delegation mit Modi hoch- und runterregeln
- 8
Für editlastige Phasen auf accept edits umschalten
alt+m (shift+tab rotiert die Modi in aktuellen Builds) schaltet das Sitzungs-Badge auf accept edits on. Datei-Änderungen landen jetzt ohne Prompts, und die Doku ergänzt, dass gängige Dateisystem-Befehle — mkdir, touch, mv, cp — ebenfalls automatisch akzeptiert werden. Die Gnade gilt nur für die Sitzung: Neue Sitzung, zurück zum Prompt pro Änderung, bis Sie wieder zuschlagen.
Das accept-edits-on-Badge, während die erlaubten Git-Befehle den Commit abschließen.Ansehen bei 4:35 - 9
Kennen Sie die ganze Modus-Leiter, bevor Sie hochklettern
Modi setzen die Grundhaltung einer Sitzung. default fragt bei der ersten Nutzung jedes Tools; plan ist Nur-Lese-Erkundung, die nichts ändert; acceptEdits akzeptiert Datei-Änderungen automatisch; dontAsk lehnt automatisch ab, was sonst fragen würde; auto genehmigt Tool-Aufrufe mit Sicherheitschecks im Hintergrund; bypassPermissions überspringt Prompts, außer für die kleine Menge von Aktionen, die kein Modus automatisch freigeben darf. Pro Sitzung wählen Sie einen mit --permission-mode, dauerhaft mit permissions.defaultMode.
- 10
defaultMode in die richtige Datei legen
Die Settings-Doku ist deutlich: defaultMode-Werte auto und bypassPermissions greifen nicht aus Projekt- oder lokalen Settings — setzen Sie sie in User- (~/.claude/settings.json) oder Managed-Settings, oder übergeben Sie --permission-mode für eine einzige Sitzung. Die Priorität läuft managed → CLI --settings → .claude/settings.local.json → .claude/settings.json → user, und ein Deny auf jeder Ebene schlägt jedes Allow darunter.
Copy-Paste-Rezepte für echte Projekte
- 11
Rezept: Tests erlauben, Zerstörung verbieten
In der teamgeteilten .claude/settings.json erlauben Sie die Testschleife mit "Bash(npm run test:*)" und zäunen die gefährlichen Teile mit "Bash(rm -rf *)" und "Read(./.env)" ein, damit Secrets nie lesbar sind. Die Webrecherche zementiert dasselbe Muster: "WebFetch(domain:example.com)" für eine Domain, "WebFetch(domain:*.example.com)" für eine ganze Subdomain. Weil Deny zuerst ausgewertet wird, kann keine Allow-Regel eine Ausnahme herausschneiden.
- 12
Rezept: Prompts in der CI sicher überspringen
Nicht-interaktive Läufe brauchen eine bewusste, keine zufällige Haltung: Übergeben Sie --permission-mode bypassPermissions am CI-Job oder setzen Sie defaultMode in User- oder Managed-Settings — eine Projektdatei kann es nicht gewähren. Damit der Schutzrahmen permanent ist: permissions.disableBypassPermissionsMode auf "disable" in Managed-Settings, und jede Maschine mit /permissions auditieren, das jede aktive Regel samt Herkunftsdatei listet.
deny → ask → allow: wie Regeln wirklich ausgewertet werden
Die Permissions-Doku stellt es nüchtern fest: Regeln werden in dieser Reihenfolge ausgewertet — deny, dann ask, dann allow — der erste Treffer entscheidet, und die Spezifität einer Regel ändert diese Reihenfolge nie. Eine Allow-Regel kann aus einer Deny-Regel keine Ausnahme herausschneiden, so präzise sie auch ist.
Deny ist auch dateiübergreifend global. Wenn User-Settings einen Befehl erlauben und Projekt-Settings ihn verbieten, gewinnt das Deny, denn Deny-Regeln aus jedem Scope werden vor Allow-Regeln ausgewertet — und ein Deny aus Managed-Settings lässt sich nicht einmal über Kommandozeilen-Flags überstimmen. Ein Deny auf den nackten Tool-Namen wie "Bash" geht noch weiter: Die Doku sagt, es entfernt das Tool vollständig aus Claudes Kontext.
Praktische Folge: Liefern Sie Ihre Sicherheitsregeln — deny rm, deny .env-Lesezugriff, deny Force-Pushs — in der projektweiten .claude/settings.json, die mit dem Repo reist, und behandeln Sie Allow-Listen als Komfort, der sich darauf stapelt. Allow-Listen verschmelzen über Scopes, statt sich zu überschreiben, deshalb kann Ihre persönliche settings.local.json Erleichterungen ergänzen, ohne irgendjemandes Denials zu schwächen.
Drei Rezepte zum Mitnehmen
Jedes Rezept nennt die Datei, in die es gehört. Eine Konstante gilt für alle: Deny gewinnt überall, immer.
Tests frei laufen lassen, rm und .env zuschließen
In .claude/settings.json: "permissions.allow": ["Bash(npm run test:*)"] (tauschen Sie "Bash(npx vitest:*)" oder "Bash(uv run pytest:*)" je nach Stack ein), "permissions.deny": ["Bash(rm -rf *)", "Read(./.env)"]. Tests und ihre Callbacks laufen freihändig; destruktive Löschungen und Secret-Lesezugriffe werden blockiert, bevor die Auswertung Ihre Allow-Liste überhaupt erreicht.
Recherche auf die Domains pinnen, denen Sie vertrauen
Für Doku-lastige Arbeit: "WebFetch(domain:developer.mozilla.org)" und "WebFetch(domain:claude.com)" im Allow, oder "WebFetch(domain:*.example.com)" für eine ganze Subdomain. Das nackte Tool "WebFetch" zu denyen schaltet Web-Lesen komplett ab — nützlich für reproduzierbare Läufe, die beim lokalen Kontext bleiben müssen.
CI headless machen, ohne die Kontrolle zu verlieren
Der CI-Job übergibt --permission-mode bypassPermissions, oder Sie setzen "permissions.defaultMode": "bypassPermissions" in User- oder Managed-Settings — Projekt- und lokale Settings können das nicht gewähren. Um den Modus rundheraus zu verbieten, sperrt "permissions.disableBypassPermissionsMode": "disable" in Managed-Settings jedes Repo und jedes Flag aus. Selbst dann blockiert bypassPermissions weiter die kurze Liste von Aktionen, die kein Modus automatisch freigeben darf.
Regel wirkt nicht? Diese vier Dinge prüfen
Die meisten Meldungen „meine Allow-Regel wird ignoriert“ laufen darauf hinaus, in welcher Datei die Regel gelandet ist und welche Datei gewinnt.
- 1Richtige Regel, falsche Datei. Sitzungs-Genehmigungen landen in .claude/settings.local.json; Team-Regeln gehören in .claude/settings.json; maschinenweite Regeln in ~/.claude/settings.json. Führen Sie /permissions aus — es listet jede aktive Regel und die Settings-Datei, aus der sie kommt.
- 2Eine höhere Ebene verbietet sie. Werte überschreiben nach unten, aber ein Deny aus jeder Ebene wird vor Allow ausgewertet, deshalb rettet ein User-Level-Allow nie ein Projekt-Level-Deny — und Managed-Settings schlagen alles, auch Kommandozeilen-Flags.
- 3Die Allow-Regel wartet auf Vertrauen. Deny- und Ask-Regeln greifen sofort, aber Allow-Regeln aus einer committeten Projektdatei werden erst wirksam, nachdem Sie dem Workspace-Ordner vertraut haben — eine bewusste Sperre für geklonte Repos.
- 4Modus in die falsche Datei gelegt. defaultMode-Werte auto und bypassPermissions werden aus Projekt- und lokalen Settings ignoriert (die Doku vermerkt, dass sich das in v2.1.257 änderte — vorher griff bypassPermissions aus jeder Datei). Verschieben Sie sie in User- oder Managed-Settings oder nutzen Sie --permission-mode für eine einzelne Sitzung.