Claude Code Berechtigungsregeln (allow/ask/deny) und settings.json: der Leitfaden

Die Berechtigungsregeln von Claude Code legen mit allow / ask / deny in settings.json fest, welche Werkzeuge, Befehle, Dateien und Domains ohne Bestätigung erlaubt sind, nachfragen oder verboten sind. Teams können sie teilen, um passende Aufrufe abzulehnen und Genehmigungen für zuvor geprüfte Routinearbeit zu reduzieren. Andere Schreibweisen desselben Programms oder Zugriffe über Skripte werden dadurch nicht einheitlich blockiert.

Dieser Leitfaden behandelt, was Berechtigungsregeln sind (und wie sie sich von Berechtigungsmodi unterscheiden), die allow/ask/deny-Reihenfolge, die Regelsyntax, die settings.json-Hierarchie sowie praktische Rezepte — alles auf Basis der offiziellen Spezifikation.

1. Was Berechtigungsregeln sind (vs. Modi)

Claude Code nutzt ein mehrstufiges Berechtigungssystem. In Manual benötigen Arbeitsbereichslesezugriffe normalerweise keine Bestätigung, Bearbeitungen und Bash-Ausführung normalerweise schon; Ausnahmen sind integrierte reine Lesebefehle und allow-Regeln. Darauf aufbauend legen Regeln einzelne Ausnahmen fest (Quelle: offizielle Claude-Code-Dokumentation „Configure permissions“).

Regeln werden leicht mit Berechtigungsmodi verwechselt. Modi bestimmen die allgemeine Bestätigungspolitik (default, acceptEdits, auto usw.); Regeln bestimmen einzelne Werkzeuge und Befehle. Sie wirken zusammen: Modi legen die Grundlage fest, Regeln ändern sie mit Vorgaben wie „immer erlauben“ oder „diesen Aufruf ablehnen“.

2. allow / ask / deny und die Reihenfolge

Es gibt drei Regeltypen. Der Befehl /permissions listet und bearbeitet sie (und zeigt an, aus welcher settings.json jede stammt).

Regeln werden in der Reihenfolge deny → ask → allow ausgewertet. Unter normalen Einstellungsregeln entscheidet der erste Treffer; Spezifität verändert die Reihenfolge nicht. Ein breites deny für Bash(aws *) sperrt auch ein spezifischeres allow für Bash(aws s3 ls). Entscheidend: allow kann ein passendes deny nicht überschreiben. Negation bei relativen Read/Edit-Pfaden ist eine separate Funktion.

3. Regelsyntax (Tool(specifier))

Das Format lautet Tool (alles) oder Tool(specifier) (spezifisch). Jedes Tool hat seinen eigenen Specifier-Stil.

MCP-Regeln gelten nur für den Server, den sie nennen. Ab v2.1.299 (14. Oktober 2026) erlaubt mcp__a keine anderen Server namens a__b oder a_. Für Server, deren Name __ enthält oder mit _ endet, schreibe den vollständigen normalisierten Namen gefolgt von __*, etwa mcp__reports__v2__* (offizielle Doku und Änderungsprotokoll, am 18. Oktober 2026 geprüft).

Bash-Wildcards dürfen überall stehen. Bash(ls *) (Leerzeichen + *) passt auf ls -la, aber nicht auf lsof (Wortgrenze); Bash(ls*) (ohne Leerzeichen) passt auf beides. Ein abschließendes :* ist gleichbedeutend mit *.

// Bestimmte Aufrufe erlauben oder ablehnen; das blockiert nicht jeden Weg zum selben Programm
{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

Zusammengesetzte Befehle werden pro Teilbefehl geprüft; erkannte Wrapper werden vor der Auswertung entfernt. Allerdings passen andere Schreibweisen desselben Programms nicht zwangsläufig: Bash(git push *) passt nicht auf git -C . push. Integrierte reine Lesebefehle laufen normalerweise ohne Bestätigung, doch Lesebeschränkungen außerhalb des Arbeitsbereichs und Wartezeiten auf den auto-Klassifikator gelten gesondert.

Read/Edit-Pfade folgen der gitignore-Semantik mit vier Ankern:

* /Users/... ist NICHT absolut — es ist relativ zum Anker der Einstellungsdatei (bei Projekteinstellungen die Projektwurzel). In den Benutzereinstellungen meint Read(/secrets/**) daher ~/.claude/secrets/**; für eine Regel, die in jedem Projekt gilt, verwende // oder ~/. Verwende //Users/... (doppelter Schrägstrich) für absolute Pfade. Read(.env) entspricht Read(**/.env) und passt auf jede .env darunter.

4. settings.json-Hierarchie und Vorrang

Einstellungswerte werden über die Hierarchie aufgelöst. Bei Berechtigungsregeln wird ein passendes deny vor allow ausgewertet. Die folgende Tabelle beschreibt die Rangfolge zwischen Einstellungsdatei- und CLI-Regeln; sie ist keine absolute Garantie einschließlich Entscheidungsänderungen durch Mods.

// .claude/settings.json (im Team geteilt)
{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": ["Bash(npm run *)", "WebFetch(domain:docs.example.com)"],
    "deny": ["Read(.env)", "Read(**/secrets/**)", "Bash(git push *)"],
    "additionalDirectories": ["../shared-lib"]
  }
}

Der Standard-Berechtigungsmodus wird hier ebenfalls gesetzt, als defaultMode (Details zu Modi). auto und bypassPermissions wirken allerdings nicht in Projekteinstellungen (.claude/settings.json, .claude/settings.local.json); trage sie in die Benutzer- oder verwalteten Einstellungen ein. Um außerhalb des Arbeitsverzeichnisses zu lesen/bearbeiten, füge Pfade zu additionalDirectories hinzu.

5. Praktische Rezepte

Beginne damit, allow auf geprüfte Routineaufrufe zu begrenzen und ask/deny für einzuschränkende Aufrufe zu nutzen. Das kontrolliert nicht automatisch andere Schreibweisen derselben Aktion oder alle Vorgänge in einem erlaubten Skript.

Bash-Argumentabgleich reicht nicht aus, um URL-Beschränkungen durchzusetzen. Auch bei Verbot von curl/wget und Nutzung von WebFetch bleiben absolute Pfade, sh -c und Kommunikation durch andere Programme. WebFetch-Domainregeln kontrollieren dieses Werkzeug, nicht den gesamten Bash-Verkehr. Kombiniere für erzwungene Ziele Kontrollen wie die Netzwerk-Allowlist der Sandbox und verwalte Werkzeuge sowie Wiederholungen außerhalb der Sandbox gesondert.

6. Stolperfallen und häufige Verwechslungen

• Deny wird von Claude Code durchgesetzt, nicht vom Modell. „Lies das nicht“ in deinem Prompt oder in CLAUDE.md zu schreiben hält es ohne Regel nicht auf.
• Read/Edit-deny stoppt indirekten Zugriff nicht. Es gilt für integrierte Dateiwerkzeuge und cat/head/sed, nicht aber für Python- oder Node-Skripte, die Dateien selbst öffnen. Rekursive Aktionen wie grep -r pattern . ohne Nennung der Zieldatei sind eine weitere Ausnahme. Betriebssystembeschränkungen gelten für Prozesse in der Sandbox; integriertes Read, MCP und andere Wege benötigen separate Kontrollen.
• Achte auf Umgebungs-Runner. devbox run *, npx und docker exec führen ihre Argumente als Befehl aus, sodass Bash(devbox run *) auch devbox run rm -rf . zulässt. Schreibe Regeln, die den inneren Befehl einschließen.
• Hooks überschreiben Regeln nicht. Ein PreToolUse-Hook kann Berechtigungen erweitern, aber deny/ask werden unabhängig von seinem Ergebnis geprüft. Ein Mod kann dagegen mit tool.check die Entscheidung später ersetzen. Er kann ask genehmigen und in persönlichen Umgebungen ohne verwaltete Einstellungen auch deny. Auf verwalteten Rechnern und in Team/Enterprise hat deny standardmäßig Vorrang; Organisationseinstellungen können das ändern. Du musst entscheiden, ob du installierten Mods vertraust.
• Im Auto-Modus kann selbst ein Befehl aus deiner allow-Liste beim Klassifizierungsmodell landen. Beim Wechsel in den Auto-Modus werden breite allow-Regeln, die beliebige Codeausführung erlauben (pauschales Bash(*), Interpreter mit Platzhalter wie Bash(python*), run-Befehle von Paketmanagern, Agent-Regeln usw.), ausgesetzt und beim Verlassen des Modus wiederhergestellt; enge Regeln wie Bash(npm test) bleiben wirksam. Regeln greifen nur so, wie sie geschrieben sind: Bash(git push *) passt nicht auf git -C . push, und über einen Befehl, auf den keine Regel passt, entscheidet das Klassifizierungsmodell. Schreibzugriffe auf geschützte Pfade gehen ebenfalls an das Klassifizierungsmodell, auch wenn eine allow-Regel passt. Wird eine berechtigte Aktion blockiert, kannst du sie in /permissions unter Recently blocked (vor v2.1.314 Recently denied) erneut versuchen (siehe Berechtigungsmodi). Auf GitHub gibt es auch Issues, nach denen Befehle aus der allow-Liste blockiert wurden (z. B. #95996). Dieser Punkt folgt der offiziellen Doku (Choose a permission mode), Stand 9. Oktober 2026.

* Das Verhalten entspricht der offiziellen Claude-Code-Dokumentation (Configure permissions / Settings files and precedence / Choose a permission mode), Stand 9. Oktober 2026. Es kann sich ändern; prüfe die offiziellen Dokumente für den aktuellen Stand.

Zusammenfassung

Drei Kernaussagen zu den Berechtigungsregeln von Claude Code.

• Was sie sind: allow/ask/deny in der settings.json, um pro Tool, Befehl, Datei und Domain zu erlauben/nachzufragen/zu verbieten. Modi legen das Grundverhalten fest; Regeln kümmern sich um die Details.
• Rangfolge: deny → ask → allow (erster Treffer entscheidet; Spezifität ist irrelevant). Unter Einstellungsregeln kann allow ein passendes deny nicht überschreiben. Ebenen: managed > CLI > local > project > user.
• Syntax: Tool(specifier). Bash nutzt Wildcards (Leerzeichen + * ist eine Wortgrenze), Read/Edit nutzen Pfade im gitignore-Stil, WebFetch nutzt domain:. Zusammengesetzte Befehle erfordern, dass jeder Teilbefehl zutrifft.

Verstehe, worauf jede Regel passt, und reduziere nur die nötigen Genehmigungen. Kombiniere Regeln mit Berechtigungsmodi und Hooks. Erwäge eine Sandbox, wenn du erzwungene Datei- oder Netzwerkbeschränkungen benötigst. Unterscheide, welche Ebene welchen Weg abdeckt.

Wenn du den aktuellen Zustand ohne Codeänderungen untersuchen und nur Empfehlungen erhalten möchtest, lies die Anleitung zur reinen Untersuchung mit Codex und Claude Code. Sie erklärt die Schritte in App, IDE und CLI sowie einen Auftrag, der mit dem Bericht endet und keine Umsetzung verlangt.

FAQ

Geltungsbereich und Ausnahmebedingungen von Berechtigungen und Isolation wurden am 9. Oktober 2026 erneut mit offiziellen Originaldokumenten abgeglichen. Geräteeinstellungen wurden nicht geändert und Startversuche nicht durchgeführt.