Berechtigungen konfigurieren

Kontrollieren Sie, worauf Claude Code zugreifen kann und was es mit granularen Berechtigungsregeln, Modi und verwalteten Richtlinien tun kann.

Claude Code unterstützt granulare Berechtigungen, sodass Sie genau angeben können, was der Agent tun darf und was nicht. Sie können Berechtigungseinstellungen in die Versionskontrolle einchecken, um sie mit jedem Entwickler in Ihrer Organisation zu teilen, und jeder Entwickler kann seine eigenen Einstellungen anpassen.

Berechtigungssystem

Claude Code verwendet ein gestuftes Berechtigungssystem, um Leistung und Sicherheit auszugleichen. Die Tabelle zeigt für jeden Werkzeugtyp, ob der manuelle Modus vor der Ausführung der Aktion fragt. Die anderen Berechtigungsmodi ändern, welche dieser Aufforderungen Sie sehen; im automatischen Modus überprüft ein Klassifizierer Aktionen statt Ihnen, und wie der Klassifizierer Aktionen bewertet listet auf, welche er sieht.

Wenn Sie „Ja, nicht mehr fragen" wählen und die Genehmigung dauerhaft gespeichert wird, z. B. für einen Bash-Befehl oder eine WebFetch-Domäne, speichert Claude Code die Regel in .claude/settings.local.json im Stammverzeichnis des Git-Repositorys, aufgelöst durch Worktrees zum Haupt-Checkout. Die Regel gilt für zukünftige Sitzungen überall in diesem Projektverzeichnis, einschließlich Sitzungen, die in Unterverzeichnissen und in Worktrees gestartet werden. Eine Dateiänderungsgenehmigung wird nicht in der Datei gespeichert: wie die Tabelle zeigt, gilt sie bis zum Ende der Sitzung. In einigen Fällen, z. B. außerhalb eines Git-Repositorys oder unter Windows, verwendet Claude Code nicht das Projektverzeichnis-Stammverzeichnis; Wo Claude Code nach jeder Datei sucht listet diese Fälle auf und wo es die Regel stattdessen speichert.

Vor v2.1.211 speicherte Claude Code die Regel immer im Startverzeichnis, sodass eine in einem Worktree oder Unterverzeichnis gewährte Genehmigung nicht auf den Rest des Repositorys angewendet wurde. Regeln, die frühere Versionen in einem Unterverzeichnis oder Worktree gespeichert haben, gelten weiterhin für Sitzungen, die dort gestartet werden.

Manchmal bietet eine Berechtigungsaufforderung nur eine einmalige Genehmigung an, ohne Option „nicht mehr fragen" und ohne Option, die Aktion für den Rest der Sitzung zuzulassen. Claude Code bietet diese Optionen nur an, wenn die Aufforderung Ihnen alles zeigen kann, was sie zulassen würden, sodass eine Regel, die Sie aus einer Aufforderung speichern, nur das abdeckt, was ihre benannte Option zulässt. Wenn eine Aufforderung nur die einmalige Genehmigung bietet, genehmigen Sie die Aktion einmal, oder fügen Sie die Regel selbst in /permissions hinzu.

Fügen Sie einen Kommentar hinzu, wenn Sie auf eine Berechtigungsaufforderung antworten

Sie können Claude eine Notiz anhängen, wenn Sie eine einzelne Aktion genehmigen oder ablehnen. Bei den meisten Berechtigungsaufforderungen, einschließlich Bash-, PowerShell-, Datei- und MCP-Tool-Aufforderungen, wechseln Sie zu Ja oder Nein und drücken Tab, um ein Kommentarfeld für diese Option zu öffnen. WebFetch- und Browser-Aufforderungen bieten das Feld nicht an. Die Optionen, die die Aktion für den Rest der Sitzung zulassen oder eine Regel speichern, akzeptieren auch keine.

Wenn das Feld offen ist, geben Sie den Kommentar ein und drücken dann eine dieser Tasten:

• Enter: sendet Ihre Antwort mit dem angehängten Kommentar. Wenn Sie das Feld leer lassen, sendet Claude Code die Antwort ohne Kommentar.
• Tab: schließt das Feld ohne Antwort. Claude Code behält den eingegebenen Text und sendet ihn immer noch, wenn Sie mit dieser Option antworten.
• Shift+Tab: bei einer Datei-Aufforderung, z. B. einer Bearbeitungs- oder Schreib-Aufforderung, schließt das Feld genauso wie Tab. Vor v2.1.235 wählte das Drücken von Shift+Tab im Feld stattdessen die Option aus, die die Aktion für den Rest der Sitzung zulässt, sodass Claude Code die Aktion für den Rest der Sitzung genehmigte und den Kommentar verwarf.

Claude Code liefert den Kommentar unterschiedlich, je nachdem, wie Sie geantwortet haben:

• Ja: Claude Code führt die Aktion aus und sendet dann Ihren Kommentar an Claude nach dem Ergebnis.
• Nein: Claude Code sendet Ihren Kommentar an Claude als Grund für die Ablehnung, und Claude arbeitet weiter. Wenn Sie Nein ohne Kommentar bei einer Aufforderung aus der Hauptkonversation wählen, stoppt Claude Code den Zug.

Berechtigungen verwalten

Sie können Claude Code's Werkzeugberechtigungen mit /permissions anzeigen und verwalten. Diese Benutzeroberfläche listet alle Berechtigungsregeln und die settings.json-Dateien auf, aus denen sie stammen. Sie können den Dialog öffnen, während Claude arbeitet: Wenn Sie eine Regel hinzufügen oder entfernen, wendet Claude Code die Änderung ab Claude's nächstem Werkzeugaufruf in demselben Zug an. Vor v2.1.234 stellte Claude Code den Befehl in die Warteschlange, bis der Zug beendet war.

• Allow-Regeln ermöglichen Claude Code, das angegebene Werkzeug ohne manuelle Genehmigung zu verwenden.
• Ask-Regeln fordern eine Bestätigung auf, wenn Claude Code versucht, das angegebene Werkzeug zu verwenden.
• Deny-Regeln verhindern, dass Claude Code das angegebene Werkzeug verwendet.

Regeln werden in dieser Reihenfolge ausgewertet: deny, dann ask, dann allow. Die erste Übereinstimmung in dieser Reihenfolge bestimmt das Ergebnis, und die Regelspezifität ändert die Reihenfolge nicht.

Eine breite deny-Regel wie Bash(aws *) blockiert jeden übereinstimmenden Aufruf, einschließlich Aufrufen, die auch einer engeren allow-Regel wie Bash(aws s3 ls) entsprechen. Eine allow-Regel kann keine Ausnahme aus einer deny-Regel herausschneiden. Die gleiche Priorität gilt zwischen ask und allow: eine übereinstimmende ask-Regel fordert eine Bestätigung auf, auch wenn eine spezifischere allow-Regel denselben Aufruf ebenfalls erfüllt.

Deny-Regeln verhalten sich unterschiedlich, je nachdem, ob sie ein Werkzeug benennen oder ein Muster darin eingrenzen. Ein einfacher Werkzeugname wie Bash entfernt das Werkzeug vollständig aus Claudes Kontext, sodass Claude es nie sieht. Wenn Sie eine solche Regel während einer Sitzung hinzufügen, kann Claude das Werkzeug ab seinem nächsten Werkzeugaufruf nicht mehr aufrufen; Ein ganzes Werkzeug ablehnen behandelt, was mit einer Definition geschieht, die Claude bereits gesehen hat. Eine eingegrenzte Regel wie Bash(rm *) lässt das Werkzeug verfügbar und blockiert übereinstimmende Aufrufe, wenn Claude sie versucht.

Die Entfernung mit einfachem Namen gilt für jedes Werkzeug außer EndConversation: eine deny-Regel kann es nicht entfernen, während ein anderes Werkzeug verbleibt, und eine ask-Regel fordert nie eine Bestätigung dafür auf.

Wenn der Auto-Modus für Ihre Sitzung verfügbar ist, enthält der Dialog auch die Auto-Modus-Klassifiziererregeln. Wählen Sie die Registerkarte Auto mode aus, um sie anzuzeigen.

Berechtigungsmodi

Claude Code unterstützt mehrere Berechtigungsmodi, die steuern, wie Werkzeugaufrufe genehmigt werden. Siehe Berechtigungsmodi für den Zeitpunkt der Verwendung jedes Modus. Um den Modus zu ändern, in dem Sitzungen starten, legen Sie defaultMode in Ihren Einstellungsdateien fest. Welcher Modus eine Sitzung startet behandelt die integrierte Standardeinstellung für jeden Plan und was die VS Code-Erweiterung liest.

Um zu verhindern, dass der Modus bypassPermissions oder auto verwendet wird, legen Sie permissions.disableBypassPermissionsMode oder permissions.disableAutoMode auf "disable" in einer beliebigen Einstellungsdatei fest. Diese sind am nützlichsten in verwalteten Einstellungen, wo sie nicht überschrieben werden können.

Berechtigungsregelsyntax

Berechtigungsregeln folgen dem Format Tool oder Tool(specifier). Klammern innerhalb des Spezifizierers sind literal, daher benötigt ein Befehl oder Pfad, der sie enthält, keine Escapezeichen.

Alle Verwendungen eines Werkzeugs abgleichen

Um alle Verwendungen eines Werkzeugs abzugleichen, verwenden Sie einfach den Werkzeugnamen ohne Klammern:

Bash(*) ist gleichwertig mit Bash und gleicht alle Bash-Befehle ab. Als Ablehnungsregel entfernen beide Formen das Werkzeug aus Claudes Kontext.

Verwenden Sie Spezifizierer für granulare Kontrolle

Fügen Sie einen Spezifizierer in Klammern hinzu, um bestimmte Werkzeugverwendungen abzugleichen:

Abgleich nach Eingabeparameter

Ablehnungs- und Anfrage-Regeln können einen Eingabeparameter auf oberster Ebene auf jedem integrierten Werkzeug mit Tool(param:value) abgleichen.

Um einen Parameter auf einem MCP-Werkzeug abzugleichen, übergeben Sie eine Ablehnungsregel mit --disallowedTools. Wenn Claude Code eine Einstellungsdatei lädt, überspringt es alle mcp__-Regeln, die Klammern haben. Claude Code listet die übersprungene Regel im Dialog für ungültige Einstellungen auf, wenn eine interaktive Sitzung startet, und in der Ausgabe von claude doctor.

Eine Parameterregel passt, wenn Claude das Werkzeug mit diesem Parameter aufruft, der auf diesen genauen Wert gesetzt ist. Eine Zulassungsregel für einen Parameterwert würde nicht feststellen, dass der Aufruf insgesamt sicher ist, daher verwenden Zulassungsregeln weiterhin die eigene Spezifizierer-Syntax jedes Werkzeugs. Dies funktioniert für jeden Skalarparameter, den das Werkzeug akzeptiert:

Der Parameterabgleich folgt diesen Regeln:

• Der Parametername muss ein direktes Feld der Werkzeugeingabe sein, wie model auf dem Agent-Werkzeug. Felder, die in einem Objekt oder Array verschachtelt sind, können nicht abgeglichen werden
• Jede Regel benennt einen Parameter. Um sowohl model als auch isolation zu steuern, schreiben Sie zwei Regeln, Agent(model:opus) und Agent(isolation:worktree), anstatt sie in einer Regel zu kombinieren
• Der Wert unterstützt * als Platzhalter, der jede Zeichenfolge abgleicht, daher gleicht Agent(isolation:*) jeden expliziten Isolationswert ab. Ohne * ist der Abgleich exakt
• Ein Parameter, den das Modell auslässt, wird nie abgeglichen, daher gleicht Agent(model:*) einen Aufruf nicht ab, der model nicht gesetzt lässt
• Der Wert wird mit der literalen Eingabe verglichen, die Claude sendet, bevor eine Normalisierung erfolgt. Agent(model:opus) gleicht den Alias opus ab, aber nicht eine vollständige Modell-ID. Führen Sie mit --verbose aus, um die genauen Parameternamen und Werte in jedem Werkzeugaufruf zu sehen
• Leerzeichen um den Doppelpunkt werden ignoriert

Sie können ein primäres Inhaltsfeld eines Werkzeugs auf diese Weise nicht abgleichen: command für Bash und PowerShell, file_path für Read, Edit und Write, path für Grep und Glob, notebook_path für NotebookEdit und url für WebFetch. Eine Regel wie Bash(command:rm *) könnte durch einen zusammengesetzten Befehl umgangen werden, daher ignoriert Claude Code sie und gibt eine Startwarnmeldung aus. Verwenden Sie stattdessen Bash(rm *), Read(./path) oder WebFetch(domain:host).

Wildcard-Muster

Ein * in einer Bash-Regel gleicht jeden Text ab, einschließlich Leerzeichen, daher deckt eine Regel eine Familie von Befehlen ab. Eine Regel ohne * gleicht einen genauen Befehl ab.

Schreiben Sie den Befehl, den Claude ausführen soll, ohne zu fragen, und ersetzen Sie die Teile, die variieren, durch *. Mit dieser Konfiguration führt Claude Code npm-Skripte und git-Commits aus, ohne zu fragen, und lehnt Befehle ab, die mit git push beginnen. Ein Push, der auf andere Weise geschrieben ist, wie git -C . push, wird nicht abgeglichen; siehe was eine Bash-Regel nicht abgleicht.

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

Ein * kann überall in der Regel stehen: am Anfang, in der Mitte oder am Ende. Jede Zeile zeigt eine Regel, Befehle, die sie abgleicht, und nahegelegene Befehle, die sie nicht abgleicht:

Drei Abgleichsregeln erzeugen diese Zeilen:

• Das * steht für den Text an seiner Stelle. In Bash(git * main) steht es für den Unterbefehl, daher gleicht Claude Code jeden git-Unterbefehl und jede Option davor ab. Das schließt -c ein, das git veranlasst, ein Programm auszuführen, das Sie benennen. In Bash(* --version) steht das * für das Programm, daher passt jedes Programm.
• Ein * am Ende mit einem Leerzeichen davor gleicht auch den bloßen Befehl ab. Bash(ls *) gleicht ls ab, und Bash(git log *) gleicht git log ab. Das gilt nur, wenn das nachgestellte * der einzige Platzhalter der Regel ist: Bash(* --help *) gleicht npm --help x ab, aber nicht npm --help.
• Das Leerzeichen vor einem nachgestellten * ist Teil der Regel. Bash(ls *) erfordert ein Leerzeichen nach ls, daher passt lsof nicht. Bash(ls*) hat kein Leerzeichen, daher passt es auch zu lsof.

Das Suffix :* ist eine gleichwertige Möglichkeit, einen nachgestellten Platzhalter zu schreiben, daher gleicht Bash(ls:*) die gleichen Befehle ab wie Bash(ls *).

Der Berechtigungsdialog schreibt die durch Leerzeichen getrennte Form, wenn Sie „Ja, nicht mehr fragen" für ein Befehlspräfix auswählen. Die Form :* wird nur am Ende eines Musters erkannt. In einem Muster wie Bash(git:* push) wird der Doppelpunkt als Literalzeichen behandelt und passt nicht zu git-Befehlen.

Werkzeugnamen-Wildcards

Ablehnungs- und Anfrage-Regeln akzeptieren auch Glob-Muster in der Werkzeugnamen-Position. Das Muster muss dem vollständigen Werkzeugnamen entsprechen: "*" gleicht jedes Werkzeug ab, und "mcp__*" gleicht jedes MCP-Werkzeug über alle Server hinweg ab. Ein Werkzeug, das durch eine Ablehnungsregel mit bloßem Namen abgeglichen wird, wird aus Claudes Kontext entfernt, genauso wie ein bloßer Werkzeugname, einschließlich der EndConversation-Ausnahme: eine Glob-Ablehnung kann sie nicht entfernen, während ein anderes Werkzeug verbleibt, und eine Glob-Anfrage fordert sie nie auf. Diese Konfiguration lehnt jedes MCP-Werkzeug ab:

{
  "permissions": {
    "deny": [
      "mcp__*"
    ]
  }
}

Zulassungsregeln akzeptieren Werkzeugnamen-Globs nur nach einem literalen mcp__<server>__-Präfix. Das Server-Segment muss glob-frei sein, damit die Regel einen bestimmten Server benennt, den Sie konfiguriert haben. mcp__puppeteer__* gleicht jedes Werkzeug vom puppeteer-Server ab, und mcp__github__get_* gleicht seine get_-Werkzeuge ab. Ein unverankerte Zulassungs-Glob wie "*", "B*" oder "mcp__*" wird mit einer Warnung übersprungen und genehmigt nichts automatisch.

Eine Ablehnungs- oder Anfrage-Regel, deren Werkzeugname mit keinem bekannten Werkzeug übereinstimmt, erzeugt eine Startwarnmeldung, um Tippfehler zu erfassen. Werkzeugnamen, die _ oder * enthalten, sind von der Überprüfung ausgenommen, und ebenso die Namen von Werkzeugen, die Claude Code entfernt hat, wie TaskOutput.

Das Etikett, das für ein Werkzeug im Transkript und im Berechtigungsdialog angezeigt wird, kann sich vom kanonischen Namen unterscheiden. Beispielsweise hat das Werkzeug mit der Bezeichnung Stop Task im Transkript den kanonischen Namen TaskStop. Berechtigungsregeln und Hook-Matcher gleichen das Etikett nicht ab, daher passt eine Regel, die als Stop Task geschrieben ist, nicht. Für Ablehnungs- und Anfrage-Regeln erfasst die obige Startwarnmeldung die Nichtübereinstimmung. Verwenden Sie die kanonischen Namen, die in der Werkzeugreferenz aufgelistet sind.

Werkzeugspezifische Berechtigungsregeln

Bash

Bash-Berechtigungsregeln gleichen den gesamten Befehlstext ab, wobei * für beliebigen Text steht. Wildcard-Muster zeigt, welche Befehle jede Regelform abgleicht und wo * platziert werden sollte. Der Rest dieses Abschnitts behandelt, wie Claude Code zusammengesetzte Befehle und Wrapper abgleicht, was eine Regel nicht abgleicht, schreibgeschützte Befehle und Umleitungen.

Zusammengesetzte Befehle

Deny- und Ask-Regeln gelten, wenn ein beliebiger Unterbefehl sie abgleicht, einschließlich eines Befehls, der in einer Subshell verschachtelt ist, einer Befehlsersetzung oder eines Kontrollfluss-Bodys wie einer for-Schleife. Eine Ask-Regel wie Bash(git clean *) fordert Sie immer noch auf für cd /tmp && git clean -f oder echo "$(git clean -f)", auch im Auto-Modus.

Wenn && oder || nichts danach hat, wie in npm test &&, behandelt Claude Code den Befehl als nicht analysierbar und teilt ihn nicht in Unterbefehle für Allow-Regel-Abgleich auf, daher genehmigt eine Regel wie Bash(npm *) ihn nicht.

Wenn Sie einen zusammengesetzten Befehl mit „Ja, nicht mehr fragen" genehmigen, speichert Claude Code eine separate Regel für jeden Unterbefehl, der Genehmigung erfordert, anstelle einer einzelnen Regel für die vollständige zusammengesetzte Zeichenkette. Zum Beispiel speichert das Genehmigen von git status && npm test eine Regel für npm test, sodass zukünftige npm test-Aufrufe erkannt werden, unabhängig davon, was dem && vorausgeht. Unterbefehle wie cd in ein Unterverzeichnis generieren ihre eigene Read-Regel für diesen Pfad. Für einen einzelnen zusammengesetzten Befehl können bis zu 5 Regeln gespeichert werden.

Wrapper

Vor dem Abgleich von Bash-Regeln entfernt Claude Code einen festen Satz von Wrappern, daher gleicht eine Regel wie Bash(npm test *) auch timeout 30 npm test ab. Die entfernten Wrapper sind timeout, time, nice, nohup und stdbuf, plus die Shell-Builtins command und builtin sowie zsh's noglob. Jeder führt sein Argument als den tatsächlichen Befehl aus. Zwei verwandte Formen werden nicht entfernt: die Abfrageform command -v, die einen Befehl nachschlägt, anstatt ihn auszuführen, und zsh's nocorrect.

Claude Code entfernt auch eine führende Zuweisung bestimmter bekannter sicherer Umgebungsvariablen, daher gleicht Bash(npm test *) NODE_ENV=test npm test ab. Eine Allow-Regel gleicht nicht über eine Zuweisung einer anderen Variablen hinweg ab. Eine Deny- oder Ask-Regel gleicht über jede führende Zuweisung hinweg ab, daher gleicht Bash(rm *) in Deny immer noch FOO=bar rm -rf tmp/ ab.

Bloßes xargs wird auch entfernt, daher gleicht Bash(grep *) xargs grep pattern ab. Das Entfernen gilt nur, wenn xargs keine Flags hat: Ein Aufruf wie xargs -n1 grep pattern wird als xargs-Befehl abgeglichen, daher decken Regeln, die für den inneren Befehl geschrieben wurden, ihn nicht ab.

Diese Wrapper-Liste ist integriert und nicht konfigurierbar. Entwicklungsumgebungs-Runner wie direnv exec, devbox run, mise exec, npx und docker exec sind nicht in der Liste. Da diese Tools ihre Argumente als Befehl ausführen, gleicht eine Regel wie Bash(devbox run *) alles ab, was nach run kommt, einschließlich devbox run rm -rf .. Um Arbeit innerhalb eines Umgebungs-Runners zu genehmigen, schreiben Sie eine spezifische Regel, die sowohl den Runner als auch den inneren Befehl enthält, wie Bash(devbox run npm test). Fügen Sie eine Regel pro innerem Befehl hinzu, den Sie zulassen möchten.

Exec-Wrapper wie watch, setsid, ionice und flock können nicht durch eine Präfixregel wie Bash(watch *) automatisch genehmigt werden, daher fordern sie im Manual-Modus immer auf. Das gleiche gilt für find mit -exec oder -delete: Eine Bash(find *) Regel deckt diese Formen nicht ab. Um einen spezifischen Aufruf zu genehmigen, schreiben Sie eine exakte Übereinstimmungsregel für die vollständige Befehlszeichenkette.

Was eine Bash-Regel nicht abgleicht

Eine Bash-Regel gleicht den Befehlstext ab, den Claude schreibt, nachdem Claude Code zusammengesetzte Befehle aufgeteilt und Wrapper entfernt hat. Sie gleicht nicht das gleiche Programm ab, das in einer anderen Form aufgerufen wird, daher deckt eine Deny- oder Ask-Regel den Aufruf ab, den Claude normalerweise erzeugt, und ist keine Sicherheitsgrenze um das Programm. Diese Regeln in deny oder ask stoppen die erste Form und nicht die anderen:

Ihre anderen Regeln und der Berechtigungsmodus entscheiden über die Befehle in der letzten Spalte.

Für Dateisystem- und Netzwerkdurchsetzung, die nicht vom Befehlstext abhängt, verwenden Sie Sandboxing. Um den vollständigen Befehlstext mit Ihrer eigenen Logik vor der Ausführung zu überprüfen, verwenden Sie einen PreToolUse-Hook.

Schreibgeschützte Befehle

Claude Code erkennt einen integrierten Satz von Bash-Befehlen als schreibgeschützt und führt sie ohne Berechtigungsaufforderung in jedem Modus aus, außer für einen Pfad, den permissions.blockReadsOutsideWorkingDirectories einschränkt. Der Satz umfasst ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd und schreibgeschützte Formen von git. Der Satz ist nicht konfigurierbar; um eine Aufforderung für einen dieser Befehle zu erfordern, fügen Sie eine ask- oder deny-Regel dafür hinzu.

Eine Umleitung wie ls > out.txt fügt eine Überprüfung des Ziels hinzu. Siehe Umleitungen.

Unquotierte Glob-Muster sind für Befehle zulässig, deren jedes Flag schreibgeschützt ist, daher laufen ls *.ts und wc -l src/*.py ohne Aufforderung.

Im Manual-Modus fordern Befehle aus diesem Satz immer noch in diesen Fällen auf:

• Unquotierte Globs für Befehle mit schreibfähigen Flags: Befehle mit schreibfähigen oder ausführungsfähigen Flags, wie find, sort, sed und git, fordern auf, wenn ein unquotiertes Glob vorhanden ist, da das Glob zu einem Flag wie -delete expandieren könnte.
• docker auf einen anderen Daemon ausgerichtet: Schreibgeschützte Formen von docker fordern auf, wenn der Befehl ein Flag trägt, das einen anderen Daemon auswählt, wie -H, --context oder Podman's --url und --connection.
• file mit Pfad-öffnenden Flags: file fordert auf, wenn es -m/--magic-file oder -f/--files-from übergibt, da diese Flags file veranlassen, die in der Flag-Wert benannten Pfade zu öffnen.
• Netzwerkpfade unter Windows: Ein Befehl, dessen Argumente einen Netzwerk-(UNC-)Pfad enthalten, wie \\server\share\file, fordert auf, da der Zugriff auf einen Netzwerkpfad Ihre Windows-Anmeldedaten an den Host senden kann, den er benennt. Die gleiche Überprüfung gilt für PowerShell-Werkzeug-Befehle.
• Befehle, die die Analyse nicht analysieren kann: Wenn Claude Code einen Befehl nicht vollständig analysieren kann, fordert es zur Genehmigung auf, anstatt den Befehl als schreibgeschützt zu behandeln. Befehle, die länger als 10.000 Zeichen sind, fordern immer auf, da sie das überschreiten, was die Analyse analysiert.

Ein cd in einen Pfad innerhalb Ihres Arbeitsverzeichnisses oder eines zusätzlichen Verzeichnisses ist auch schreibgeschützt, und ein zusammengesetzter Befehl wie cd packages/api && ls läuft ohne Aufforderung, wenn jeder Teil auf eigene Faust qualifiziert. Diese Kombinationen fordern auf, auch wenn jeder Teil schreibgeschützt ist:

• cd mit git: fordert auf, wenn die cd in ein anderes Verzeichnis wechselt, da das Ausführen von git in einem neuen Verzeichnis die Hooks dieses Verzeichnisses ausführen kann. Ein cd dessen Ziel zum aktuellen Arbeitsverzeichnis aufgelöst wird, ist ein No-Op und löst die Aufforderung nicht aus.
• cd mit einer Umleitung: fordert auf, wenn Claude Code nicht bestimmen kann, in welches Verzeichnis das Umleitungsziel nach der Ausführung von cd aufgelöst wird. Ein Befehl, dessen einziges Umleitungsziel /dev/null ist, wie cd app; grep -r pattern . 2>/dev/null, fordert nicht auf, da /dev/null nicht vom Arbeitsverzeichnis abhängt.

Umleitungen

Wenn ein Befehl Ausgabe oder Eingabe umleitet, überprüft Claude Code das Umleitungsziel gegen Ihre Dateiregelns, als hätte Claude diese Datei direkt geschrieben oder gelesen:

• Ausgabeumleitungen: für > file, >> file oder 2> file deckt die Überprüfung Ihre Edit Allow- und Deny-Regeln, geschützte Pfade und die Arbeitsverzeichnisse ab. Eine Regel wie Bash(git commit *) genehmigt den Befehl, nicht das Ziel. Ein Ziel, das mit ~ beginnt oder ein Glob-Zeichen enthält, benötigt Ihre Genehmigung.
• Eingabeumleitungen: für < file deckt die Überprüfung Ihre Read Allow- und Deny-Regeln und die Arbeitsverzeichnisse ab. Ein Ziel außerhalb der Arbeitsverzeichnisse benötigt Ihre Genehmigung, es sei denn, eine Allow-Regel deckt es ab. Ein Ziel, das ein Glob-Muster enthält, oder einen relativen Pfad, der einer cd im gleichen Befehl folgt, benötigt Ihre Genehmigung, auch wenn eine Allow-Regel es deckt. Claude Code überprüft Eingabeziele in v2.1.257 und später.

Ziele ohne Datei dahinter werden nicht überprüft: /dev/null, Dateideskriptor-Formen wie 2>&1 und <&3, und Here-Docs und Here-Strings.

Claude Code überprüft auch die Dateien, die ein tee-Befehl schreibt, einschließlich in einer Pipeline wie make | tee build.log. Die Überprüfung deckt Ihre Edit Allow- und Deny-Regeln, geschützte Pfade und die Arbeitsverzeichnisse ab. Eine Allow-Regel wie Bash(tee *) deckt ein Ziel außerhalb der Arbeitsverzeichnisse nicht ab. Claude Code überprüft tee-Ziele in v2.1.269 und später.

PowerShell

PowerShell-Berechtigungsregeln verwenden die gleiche Form wie Bash-Regeln. Platzhalter mit * gleichen an jeder Position ab, das Suffix :* ist gleichwertig mit einem nachgestellten *, und ein bloßes PowerShell oder PowerShell(*) gleicht jeden Befehl ab. Diese Konfiguration ermöglicht Get-ChildItem- und git commit-Befehle, blockiert aber Remove-Item:

{
  "permissions": {
    "allow": [
      "PowerShell(Get-ChildItem *)",
      "PowerShell(git commit *)"
    ],
    "deny": [
      "PowerShell(Remove-Item *)"
    ]
  }
}

Häufige Aliase werden vor dem Abgleich kanonisiert. Eine Regel, die für den Cmdlet-Namen geschrieben wurde, gleicht auch seine Aliase ab, daher gleicht PowerShell(Get-ChildItem *) auch gci, ls und dir ab. Der Abgleich ist nicht case-sensitiv.

Claude Code analysiert die PowerShell-AST und überprüft jeden Befehl in einem zusammengesetzten Befehl unabhängig. Pipeline-Operatoren |, Anweisungstrennzeichen ; und auf PowerShell 7+ die Kettenoperatoren && und || teilen einen zusammengesetzten Befehl in Unterbefehle auf. Eine Regel muss jeden Unterbefehl abgleichen, damit der zusammengesetzte Befehl zulässig ist.

Read und Edit

Um Claude's Dateiwerkzeuge daran zu hindern, eine Datei oder ein Verzeichnis zu lesen, fügen Sie eine Read Deny-Regel für seinen Pfad hinzu, wie Read(./.env) oder Read(./secrets/**); Sensible Dateien ausschließen hat ein einfügendes Beispiel.

Edit-Regeln gelten für alle integrierten Werkzeuge, die Dateien bearbeiten. Claude versucht nach besten Kräften, Read-Regeln auf alle integrierten Werkzeuge anzuwenden, die Dateien lesen, wie Grep und Glob, auf @file-Erwähnungen in Ihren Eingabeaufforderungen und auf die Auswahl und offene Datei-Kontexte, die ein verbundener IDE mit Claude teilt.

Eine Read Deny-Regel blockiert auch das Edit- und Write-Werkzeug auf demselben Pfad, einschließlich der Erstellung einer neuen Datei dort. NotebookEdit ist nicht abgedeckt, daher fügen Sie eine Edit Deny-Regel für Pfade hinzu, die kein Werkzeug ändern darf. Die Überprüfung erfordert Claude Code v2.1.208 oder später bei Bearbeitungen, und v2.1.228 oder später bei Schreibvorgängen.

Claude Code überprüft Dateiberechtigungen nur gegen Edit(path) und Read(path) Regeln. Wenn Sie eine Pfadregel für Write, NotebookEdit, Glob oder das veraltete MultiEdit-Werkzeug schreiben, akzeptiert Claude Code die Regel, konsultiert sie aber nie, und warnt beim Start, außer für eine Glob-Regel, die in --allowedTools übergeben wird. Verwenden Sie Edit(docs/**) anstelle von Write(docs/**), NotebookEdit(docs/**) oder MultiEdit(docs/**), und Read(docs/**) anstelle von Glob(docs/**). Claude Code warnt nicht vor einer Werkzeugnamen-Regel ohne Pfad, wie einer Deny-Regel für Write; sie passt diese Regel überall auf Werkzeugebene an. Erfordert Claude Code v2.1.210 oder später.

Read- und Edit-Regeln folgen beide der gitignore-Spezifikation mit vier unterschiedlichen Mustertypen; für Muster mit einzelnem Verzeichnissegment hängt die Abgleichtiefe auch vom Regeltyp ab, der später in diesem Abschnitt beschrieben wird:

Ein /path-Muster verankert sich an einem Verzeichnis, das der Einstellungsquelle zugeordnet ist, die es definiert, daher gleicht die gleiche Regel verschiedene Orte ab, je nachdem, wo Sie sie platzieren:

Eine Regel, die Sie über /permissions hinzufügen, folgt der Zeile für die Einstellungsdatei, in der Sie sie speichern.

Lokale Einstellungsregeln verankern sich am primären Arbeitsverzeichnis der Sitzung, nicht am Repository-Root, wo Claude Code die Datei speichert in v2.1.211 und später. In einer Sitzung, die am Repository-Root gestartet wird, sind die beiden Verzeichnisse gleich; in einer Worktree-Sitzung gleicht eine gemeinsame Regel wie Edit(/src/**) das eigene src/-Verzeichnis dieser Worktree.

Eine Deny-Regel wie Read(/secrets/**) in Benutzereinstellungen blockiert ~/.claude/secrets/**, nicht ein secrets-Verzeichnis in Ihrem Projekt. Um eine Regel in Benutzereinstellungen zu schreiben, die sich in jedem Projekt anwendet, verwenden Sie stattdessen einen // absoluten Pfad oder einen ~/ Home-relativen Pfad.

Unter Windows werden Pfade vor dem Abgleich in POSIX-Form normalisiert. C:\Users\alice wird zu /c/Users/alice, verwenden Sie also //c/**/.env, um .env-Dateien überall auf diesem Laufwerk abzugleichen. Um über alle Laufwerke hinweg abzugleichen, verwenden Sie //**/.env.

Beispiele:

• Edit(/docs/**): Bearbeitungen in <primary working directory>/docs/, nicht /docs/ oder <primary working directory>/.claude/docs/
• Read(~/.zshrc): liest die .zshrc Ihres Home-Verzeichnisses
• Edit(//tmp/scratch.txt): bearbeitet den absoluten Pfad /tmp/scratch.txt
• Read(src/**): als Allow-Regel liest aus <current-directory>/src/ nur; als Deny- oder Ask-Regel gleicht ein src-Verzeichnis in jeder Tiefe unter dem aktuellen Verzeichnis ab

Eine Regel gleicht nur Dateien unter ihrem Anker ab; innerhalb dieser Grenze hängt die Abgleichtiefe vom Mustermuster und, für Muster mit einzelnem Verzeichnissegment, vom Regeltyp ab, der unten beschrieben wird. Bare Dateinamen folgen gitignore-Semantik und gleichen in jeder Tiefe ab, daher sind Read(.env) und Read(**/.env) gleichwertig:

Ein relatives Muster mit einem einzelnen Verzeichnissegment, wie src/**, gleicht in verschiedenen Tiefen ab, je nach Regeltyp:

• Allow-Regeln: Edit(src/**) gleicht nur <cwd>/src und die Dateien darunter ab. Um einen Verzeichnisnamen in jeder Tiefe zuzulassen, schreiben Sie Edit(**/src/**).
• Deny- und Ask-Regeln: Read(secrets/**) gleicht ein Verzeichnis namens secrets in jeder Tiefe unter dem aktuellen Verzeichnis ab, daher gilt die Regel auch für verschachtelte Kopien.

Jede andere Mustermuster gleicht in jeder Regeltyp in der gleichen Tiefe ab: Edit(/src/**) und Edit(src/components/**) gleichen nur an ihrer verankerten Position ab, während Edit(**/src/**) in jeder Tiefe gleicht.

Das folgende Beispiel zeigt jede Mustermuster gegen ein Projekt mit einem Top-Level-src/-Verzeichnis und einer verschachtelte Kopie unter vendor/:

<current-directory>/
├── src/
│   └── app.ts
└── vendor/
    └── pkg/
        └── src/
            └── lib.js

Wenn Sie einen Dateipfad mit „Ja, nicht mehr fragen" genehmigen, entweicht Claude Code gitignore-Mustzeichen in diesem Pfad, wie [, ] und *, daher gleicht die generierte Regel nur den wörtlichen Pfad, den Sie genehmigt haben. Regeln, die Sie selbst schreiben, werden nicht entweicht. Vor v2.1.202 speicherte Claude Code den Pfad unentweicht, daher konnte eine generierte Regel für ein Verzeichnis namens [2024-06] Reports seinen eigenen Pfad nicht abgleichen oder unbeabsichtigte Geschwisterverzeichnisse abgleichen.

Sie müssen Klammern in einem Pfad nicht entweichen, daher gleicht Edit(./Finance (2024)/**) den Finance (2024)-Ordner wie geschrieben ab.

Eine Deny- oder Ask-Regel, deren Pfad nicht als gitignore-Muster verwendbar ist, schützt immer noch diesen genauen Pfad. Eine Allow-Regel mit einem nicht verwendbaren Muster genehmigt nichts.

Eine Deny- oder Ask-Regel, die ein Negationsmuster mit ! beginnt, ist eine gitignore-Negation. Sie schneidet die Pfade, die sie abgleicht, aus den path oder ./path Regeln aus, die davor aufgelistet sind. In einer Einstellungsdatei's deny-Liste blockiert Read(*.env) gefolgt von Read(!sample.env) jede Datei, deren Name mit .env endet, in jeder Tiefe, außer Dateien namens sample.env. Eine !-Regel, die zuerst aufgelistet ist, schneidet nichts aus.

Die Ausschneidung erreicht nur Regeln aus der gleichen Quelle. Ein Read(!.env) in Projekteinstellungen oder in --disallowedTools hebt ein Read(./.env) Deny aus verwalteten Einstellungen oder einer anderen Einstellungsdatei nicht auf.

Zwei Grenzen verengen, was ein !-Muster ausschneiden kann:

• Claude Code liest ein !-Muster relativ zum aktuellen Verzeichnis, auch wenn /, ~/ oder // dem ! folgt, daher kann das Muster eine Regel, die mit einem dieser Präfixe verankert ist, nicht erreichen. Read(!~/notes/public/**) schneidet nichts aus Read(~/notes/**) aus.
• Ein Ausschnitt kann eine Datei innerhalb eines Verzeichnisses, das eine Regel als Ganzes blockiert, nicht wieder öffnen. Mit Read(secrets/**) und Read(!secrets/public/**) blockiert Claude Code immer noch secrets/public zusammen mit dem Rest von secrets.

Wenn Claude auf einen Symlink zugreift, überprüfen Berechtigungsregeln zwei Pfade: den Symlink selbst und die Datei, auf die er verweist. Allow- und Deny-Regeln behandeln dieses Paar unterschiedlich: Allow-Regeln fallen auf Aufforderungen zurück, während Deny-Regeln direkt blockieren.

• Allow-Regeln: gelten nur, wenn sowohl der Symlink-Pfad als auch sein Ziel übereinstimmen. Ein Symlink in einem zulässigen Verzeichnis, der außerhalb davon verweist, fordert Sie immer noch auf.
• Deny-Regeln: gelten, wenn entweder der Symlink-Pfad oder sein Ziel übereinstimmt. Ein Symlink, der auf eine verweigerte Datei verweist, ist selbst verweigert. Zum Beispiel mit Read(./project/**) zulässig und Read(~/.ssh/**) verweigert, wird ein Symlink bei ./project/key, der auf ~/.ssh/id_rsa verweist, blockiert: Das Ziel schlägt die Allow-Regel fehl und passt zur Deny-Regel.

Auf macOS und Linux gilt eine Deny- oder Ask-Regel, die durch ein symverlinktes Verzeichnis mit einem //, ~/ oder / Muster geschrieben wurde, auch am echten Ort des Verzeichnisses. Zum Beispiel auf macOS, wo /etc zu /private/etc aufgelöst wird, blockiert Read(//etc/**) auch /private/etc/hosts. Vor v2.1.268 galt eine Deny- oder Ask-Regel, die durch ein symverlinktes Verzeichnis geschrieben wurde, nicht für einen Pfad, der durch seinen echten Ort gegeben wurde.

Wenn ein Werkzeug eine genehmigte Datei öffnet, bestätigt Claude Code, dass der Pfad immer noch zum Ort aufgelöst wird, den die Berechtigungsprüfung genehmigt hat.

Grep und Glob durchsuchen das Verzeichnis, zu dem das path-Argument aufgelöst wird. Claude Code wendet Read Deny-Regeln auf dieses Verzeichnis an.

WebFetch

WebFetch-Regeln verwenden ein domain:-Präfix und gleichen gegen den Hostnamen der angeforderten URL ab. Der Abgleich ist case-insensitiv, unterstützt *-Platzhalter und entfernt einen nachgestellten . sowohl aus der Regel als auch aus dem Hostnamen, daher werden example.com. und example.com gleich behandelt.

• WebFetch(domain:example.com) gleicht Anfragen an example.com ab
• WebFetch(domain:*.example.com) gleicht jede Subdomain in jeder Tiefe ab, wie api.example.com oder a.b.example.com, aber nicht example.com selbst
• WebFetch(domain:*) gleicht jede Domain ab. Es ist nicht das gleiche wie eine bare WebFetch-Regel; siehe Jeden Abruf zulassen oder verweigern

An jeder Position außer einem führenden *. oder einem bloßen * gleicht der Platzhalter nur den Text zwischen zwei Punkten. WebFetch(domain:example.*) gleicht example.org ab, wobei * zu org wird, aber nicht example.evil.com, wobei * zu evil.com werden müsste und einen Punkt überschreiten würde. Dies verhindert, dass ein nachgestellter Platzhalter Domänen abgleicht, die ein Angreifer registrieren könnte.

Platzhalter in WebFetch-Regeln erfordern Claude Code v2.1.172 oder später, um Abrufe abzugleichen.

Jeden Abruf zulassen oder verweigern

Eine bare WebFetch-Regel ist der Werkzeugname ohne domain:-Teil, wie "deny": ["WebFetch"]. Sowohl sie als auch WebFetch(domain:*) decken jede URL ab, aber Claude Code wendet sie unterschiedlich an, und nur die domain:-Form fügt ihre Domain auch zur zulässigen oder verweigerten Domain-Liste der Sandbox hinzu. Dieser Abschnitt listet die Wildcard-Formen auf, die die Sandbox ehrt, und die Version, die bare * hinzugefügt hat.

Jede Zeile zeigt, was eine Regel in der allow-Liste und in der deny-Liste tut:

Die beiden Formen unterscheiden sich auch bei Lesevorgängen von Artefakten, den Seiten, die das Artifact-Werkzeug auf claude.ai veröffentlicht. Eine bare WebFetch Deny- oder Ask-Regel gilt nicht für diese Lesevorgänge. Eine domain:-Regel, die claude.ai oder den *.claudeusercontent.com Content-Host abdeckt, wie WebFetch(domain:claude.ai) oder WebFetch(domain:*), verweigert jeden Lesevorgang oder fordert davor auf. Eine Artifact-Regel tut das gleiche.

Wenn eine Regel einen Lesevorgang blockiert, benennt die Ablehnung die Regel. Vor v2.1.268 blockierte eine bare WebFetch Deny-Regel jeden Artefakt-Lesevorgang, und eine bare Ask-Regel forderte vor jedem auf.

Um Claude frei abrufen zu lassen, während die Sandbox-Allowlist wie sie ist bleibt, verwenden Sie die bare Form. Diese settings.json tut das:

{
  "permissions": {
    "allow": ["WebFetch"]
  }
}

Wenn Sie Claude bitten, eine Seite abzurufen, ruft es ab, ohne Sie aufzufordern. Wenn Sie es bitten, einen sandboxed curl gegen einen Host außerhalb der Sandbox-Allowlist auszuführen, fordert Claude Code Sie immer noch für diesen Host auf, da die bare Regel den Host nicht zur Allowlist hinzugefügt hat. Im Auto-Modus benennt Claude stattdessen den Host in den pro-Befehl zulässigen Domänen des Befehls für den Klassifizierer zur Überprüfung.

MCP

MCP-Regeln verwenden den Servernamen wie in Claude Code konfiguriert, optional gefolgt vom Namen eines Werkzeugs von diesem Server.

• mcp__puppeteer gleicht jedes Werkzeug ab, das vom puppeteer-Server bereitgestellt wird
• mcp__puppeteer__* verwendet Wildcard-Syntax und gleicht auch alle Werkzeuge vom puppeteer-Server ab
• mcp__puppeteer__puppeteer_navigate gleicht das puppeteer_navigate-Werkzeug ab, das vom puppeteer-Server bereitgestellt wird

Wenn Ihre Organisation ein claude.ai-Connector-Werkzeug auf ask gesetzt hat und diese Einstellung Claude Code in Ihrer Sitzung erreicht, nehmen Allow-Regeln für dieses Werkzeug keine Wirkung: Claude Code fordert bei jedem Aufruf auf, auch in auto- und bypassPermissions-Modi. Im dontAsk-Modus, der niemals auffordert, verweigert Claude Code den Aufruf stattdessen. Werkzeuge von Connectoren, die Claude Code selbst abruft, erscheinen als mcp__claude_ai_<server>__<tool>.

In einer Cowork-Sitzung in der Claude Desktop-App führt Claude Shell-Befehle über Cowork's mcp__workspace__bash-Werkzeug anstelle des integrierten Bash-Werkzeugs aus, und Cowork stellt ebenso mcp__workspace__web_fetch für Web-Abrufe bereit. Claude Code wendet auch Deny-Regeln an, die das ganze Bash- oder WebFetch-Werkzeug benennen, auf diese Cowork-Werkzeuge an, daher stoppt eine verwaltete Bash-Deny-Regel Claude daran, Shell-Befehle in Cowork auszuführen. Wenn Claude Code einen solchen Aufruf blockiert, benennt die Nachricht das Cowork-Werkzeug: Permission to use mcp__workspace__bash has been denied. Allow-Regeln tragen nicht über: Claude Code wendet nie eine Bash-Allow-Regel auf mcp__workspace__bash an.

Agent (Subagents)

Verwenden Sie Agent(AgentName)-Regeln, um zu steuern, welche Subagents Claude verwenden kann:

• Agent(Explore) gleicht den Explore-Subagent ab
• Agent(Plan) gleicht den Plan-Subagent ab
• Agent(my-custom-agent) gleicht einen benutzerdefinierten Subagent namens my-custom-agent ab

Fügen Sie diese Regeln zum deny-Array in Ihren Einstellungen hinzu oder verwenden Sie das --disallowedTools-CLI-Flag, um bestimmte Agenten zu deaktivieren. Um den Explore-Agenten zu deaktivieren:

{
  "permissions": {
    "deny": ["Agent(Explore)"]
  }
}

Cd

Cd-Regeln steuern, in welche Verzeichnisse der /cd-Befehl die Sitzung verschieben kann. Cd ist kein vom Modell aufzurufendes Werkzeug: Claude kann es nicht aufrufen, und die Regeln gelten nur, wenn Sie /cd selbst ausführen.

Eine bare Cd-Deny-Regel deaktiviert /cd vollständig. Eine Cd(<path-pattern>)-Deny-Regel blockiert übereinstimmende Ziele. Deny-Regeln überprüfen jede Schreibweise des Ziels, einschließlich jedes Symlink-Hops, durch den es sich auflöst, daher blockiert eine Regel, die für einen Pfad geschrieben wurde, auch Ziele, die sich darin auflösen.

Das Hinzufügen einer Cd-Allow-Regel schaltet /cd in den Allowlist-Modus: Das aufgelöste Zielverzeichnis muss einer Ihrer Allow-Regeln entsprechen, oder /cd weigert sich. Ohne konfigurierte Cd-Regeln behält /cd sein Standardverhalten bei und fordert Sie auf, einem unbekannten Verzeichnis zu vertrauen.

Pfadmuster teilen die //, ~/ und / Anker von Read- und Edit-Regeln, aber der Abgleich ist am gesamten Verzeichnispfad verankert, nicht im gitignore-Stil. * gleicht genau ein Pfadsegment ab und ** gleicht über Segmente hinweg ab. Ein nachgestelltes /** gleicht auch seinen benannten Root ab.

Berechtigungen mit Hooks erweitern

Claude Code Hooks ermöglichen es Ihnen, benutzerdefinierte Shell-Befehle zu registrieren, die Berechtigungen zur Laufzeit evaluieren. Wenn Claude Code einen Werkzeugaufruf tätigt, werden PreToolUse-Hooks vor dem Berechtigungssystem ausgeführt, für jedes Werkzeug außer EndConversation. Die Hook-Ausgabe kann den Werkzeugaufruf verweigern, eine Aufforderung erzwingen oder die Aufforderung überspringen, um den Aufruf fortzufahren.

Hook-Entscheidungen umgehen keine Berechtigungsregeln. Claude Code evaluiert Deny- und Ask-Regeln unabhängig davon, was ein PreToolUse-Hook zurückgibt: Eine übereinstimmende Deny-Regel blockiert den Aufruf, und eine übereinstimmende Ask-Regel fordert immer noch auf, selbst wenn der Hook "allow" oder "ask" zurückgegeben hat. Dies bewahrt die Deny-First-Priorität, die in Berechtigungen verwalten beschrieben ist, einschließlich Deny-Regeln, die in verwalteten Einstellungen festgelegt sind.

MCP-Tools, die mit requiresUserInteraction gekennzeichnet sind, werden auch weiterhin aufgefordert, wenn ein Hook "allow" zurückgibt, ebenso wie Connector-Tools, die Ihre Organisation auf ask gesetzt hat in Sitzungen, in denen diese Einstellung Claude Code erreicht.

Ein blockierender Hook hat auch Vorrang vor Allow-Regeln. Ein Hook, der mit Code 2 beendet wird, stoppt den Werkzeugaufruf, bevor Berechtigungsregeln evaluiert werden, daher gilt die Blockierung auch dann, wenn eine Allow-Regel den Aufruf sonst zulassen würde. Um alle Bash-Befehle ohne Aufforderungen auszuführen, außer für einige, die Sie blockieren möchten, fügen Sie "Bash" zu Ihrer Allow-Liste hinzu und registrieren Sie einen PreToolUse-Hook, der diese spezifischen Befehle ablehnt. Siehe Bearbeitungen geschützter Dateien blockieren für ein Hook-Skript, das Sie anpassen können.

Arbeitsverzeichnisse

Standardmäßig hat Claude Zugriff auf Dateien in dem Verzeichnis, in dem Sie es gestartet haben. Dieses Verzeichnis ist das primäre Arbeitsverzeichnis der Sitzung, bis Sie die Sitzung mit /cd verschieben. Sie können diesen Zugriff erweitern:

• Beim Start: Verwenden Sie das CLI-Argument --add-dir <path>
• Während der Sitzung: Verwenden Sie den Befehl /add-dir
• Persistente Konfiguration: Fügen Sie zu additionalDirectories in Einstellungsdateien hinzu

Dateien in zusätzlichen Verzeichnissen folgen den gleichen Berechtigungsregeln wie das ursprüngliche Arbeitsverzeichnis: Sie werden lesbar ohne Aufforderungen, und Dateiberechtigungen folgen dem aktuellen Berechtigungsmodus.

Sie können die meisten Netzwerkpfade, wie die UNC-Freigabe \\server\share, nicht als Arbeitsverzeichnisse hinzufügen, da das Nachschlagen einen Kontakt zum benannten Host verursachen kann. Unter Windows ordnen Sie die Freigabe stattdessen einem Laufwerksbuchstaben zu und übergeben das Laufwerk mit --add-dir beim Start.

Setzen Sie permissions.blockReadsOutsideWorkingDirectories, um die Dateiwerkzeuge zu veranlassen, die Pfade, die es einzäunt, in jedem Berechtigungsmodus abzulehnen. Im Auto-Modus bietet Claude Code an, es beim ersten Mal einzuschalten, wenn Claude außerhalb der Arbeitsverzeichnisse liest.

In Hintergrund-Sitzungen auf macOS fordert der Sitzungs-Host Zugriff auf geschützte Ordner wie ~/Desktop, ~/Documents und ~/Downloads separat von Ihrem Terminal an, wenn Claude dort Dateien lesen oder schreiben muss; wenn Lesevorgänge dort mit Operation not permitted fehlschlagen, siehe wie man Ordnerzugriff auf Hintergrund-Sitzungen auf macOS gewährt.

Sitzung in ein anderes Verzeichnis verschieben

Um die Sitzung in ein anderes primäres Arbeitsverzeichnis zu verschieben, anstatt ein Verzeichnis hinzuzufügen neben dem aktuellen, führen Sie /cd <path> aus. Claude Code behält die Konversation bei, lädt die CLAUDE.md des neuen Verzeichnisses und fordert Sie auf, dem Arbeitsbereich zu vertrauen, wenn Sie darin noch nicht gearbeitet haben. Danach findet Claude Code die verschobene Sitzung, wenn Sie --resume aus dem neuen Verzeichnis ausführen.

Sobald Sie verschieben, wendet Claude Code die Projektkonfiguration des neuen Verzeichnisses an:

• Seine Projekteinstellungen, einschließlich ihrer Berechtigungsregeln und Hooks
• Seine .mcp.json-Server, unterliegen der gleichen Server-Genehmigung wie beim Start, und die lokalen MCP-Server, die Sie darin registriert haben
• Die Plugins, die seine Einstellungen aktivieren, seine Skills und seine Subagents
• Seine env-Werte, angewendet auf die Umgebungsvariablen aus den Einstellungen des vorherigen Verzeichnisses, die weiterhin gültig sind

Claude Code trennt auch die MCP-Server des vorherigen Verzeichnisses und lokalen ab, sowie die Server von Plugins, die nach dem Verschieben nicht mehr aktiviert sind. Es nimmt zusätzliche Verzeichnisse aus den Einstellungen des neuen Verzeichnisses statt aus denen des vorherigen, und behält die Verzeichnisse bei, die Sie mit --add-dir oder /add-dir hinzugefügt haben. Hooks, die das Verschieben aktiviert, erhalten immer noch ${CLAUDE_PROJECT_DIR} auf das Projektverzeichnis gesetzt, in dem die Sitzung gestartet wurde.

Wenn das neue Verzeichnis noch nicht vertraut ist, listet Claude Code in der Vertrauensaufforderung die Allow-Regeln, zusätzlichen Verzeichnisse, Hooks und Hilfsbefehle auf, die die Einstellungen des Verzeichnisses aktivieren würden, damit Sie diese überprüfen können, bevor Sie akzeptieren. Wenn Sie ablehnen, bleibt die Sitzung dort, wo sie ist. Vor v2.1.246 wendete /cd die Einstellungen, Hooks, MCP-Server oder Skills des neuen Verzeichnisses nicht an, bis Sie die Sitzung wiederaufnahmen, und die Vertrauensaufforderung listete nicht auf, was die Einstellungen des Verzeichnisses aktivieren würden.

Beschränken oder deaktivieren Sie /cd-Ziele mit Cd-Berechtigungsregeln.

Zusätzliche Verzeichnisse gewähren Dateizugriff, keine Konfiguration

Das Hinzufügen eines Verzeichnisses erweitert, wo Claude Dateien lesen und bearbeiten kann. Es macht dieses Verzeichnis nicht zu einem vollständigen Konfigurationsroot: Die meisten .claude/-Konfigurationen werden nicht aus zusätzlichen Verzeichnissen erkannt, obwohl einige Typen als Ausnahmen geladen werden.

Diese Ausnahmen gelten nur für Verzeichnisse, die mit dem Flag --add-dir oder dem Befehl /add-dir hinzugefügt wurden, einschließlich Verzeichnisse, die das Agent SDK durch das Flag hinzufügt. Verzeichnisse, die in permissions.additionalDirectories in einer Einstellungsdatei aufgelistet sind, gewähren nur Dateizugriff und laden keine der folgenden Konfigurationen.

Das Agent SDK's additionalDirectories-Option in TypeScript und add_dirs-Option in Python erhalten die Ausnahmen ebenfalls, obwohl die TypeScript-Option ihren Namen mit dem Einstellungsschlüssel teilt. Das SDK übergibt jeden Eintrag an Claude Code als --add-dir, sodass diese Verzeichnisse sich wie Flag-hinzugefügte Verzeichnisse verhalten. Skills, Befehle und Subagents aus jedem Flag-hinzugefügten Verzeichnis werden durch die project-Einstellungsquelle geladen, sodass sie nicht geladen werden, wenn Sie diese Quelle mit --setting-sources in der CLI oder settingSources im SDK ausschließen, und Bare Mode überspringt die Befehle und Subagents unter ihnen.

Die folgenden Konfigurationstypen werden aus --add-dir-Verzeichnissen geladen:

Um die Skills, Befehle und Subagents aus einem Unterverzeichnis Ihres primären Arbeitsverzeichnisses während der Sitzung zu laden, führen Sie /add-dir mit dem Pfad dieses Unterverzeichnisses aus. Claude Code lädt sie für den Rest der Sitzung, ohne Sie aufzufordern oder ein Arbeitsverzeichnis hinzuzufügen, da das Unterverzeichnis bereits lesbar ist. Dies erfordert Claude Code v2.1.257 oder später.

Claude Code erkennt Ausgabestile aus dem aktuellen Arbeitsverzeichnis und seinen übergeordneten Verzeichnissen, Ihrem Benutzerverzeichnis unter ~/.claude/ und verwalteten Einstellungen. Hooks und andere .claude/settings.json-Schlüssel werden aus dem .claude/-Ordner des aktuellen Arbeitsverzeichnisses ohne Fallback für übergeordnete Verzeichnisse geladen, zusammen mit Ihren Benutzer-~/.claude/settings.json und verwalteten Einstellungen. .claude/settings.local.json wird stattdessen aus dem Git-Repository-Root geladen, auch wenn Sie Claude Code in einem Unterverzeichnis starten, außer in den Fällen, in denen Claude Code den Repository-Root nicht verwendet, wie unter Windows; vor v2.1.211 wurde es auch nur aus dem aktuellen Arbeitsverzeichnis geladen. Agent SDK-Sitzungen laden es in allen Versionen aus dem Arbeitsverzeichnis.

Um diese Konfiguration über Projekte hinweg zu teilen, verwenden Sie einen dieser Ansätze:

• Benutzergesteuerte Konfiguration: Platzieren Sie Dateien in ~/.claude/agents/, ~/.claude/output-styles/ oder ~/.claude/settings.json, um sie in jedem Projekt verfügbar zu machen
• Plugins: Verpacken und verteilen Sie Konfiguration als Plugin, das Teams installieren können
• Starten Sie aus dem Konfigurationsverzeichnis: Führen Sie Claude Code aus dem Verzeichnis aus, das die .claude/-Konfiguration enthält, die Sie verwenden möchten

Wie Berechtigungen mit Sandboxing interagieren

Berechtigungen und Sandboxing sind komplementäre Sicherheitsebenen:

• Berechtigungen steuern, welche Werkzeuge Claude Code verwenden kann und auf welche Dateien oder Domänen es zugreifen kann. Sie gelten für Bash, Read, Edit, WebFetch, MCP und alle anderen Werkzeuge, außer dass eine Deny- oder Ask-Regel EndConversation nicht blockieren kann, während ein anderes Werkzeug aktiv bleibt.
• Sandboxing bietet OS-Ebenen-Durchsetzung, die den Zugriff von Shell-Befehlen auf das Dateisystem und das Netzwerk einschränkt. Es gilt nur für Bash, PowerShell und Monitor Befehle und ihre untergeordneten Prozesse.

Verwenden Sie beide für Defense-in-Depth, da Sandbox-Einschränkungen weiterhin gelten, selbst wenn eine Prompt-Injection Claude's Entscheidungsfindung umgeht. Pfade und Domänen sowohl aus Sandbox-Einstellungen als auch aus Berechtigungsregeln werden in die endgültige Sandbox-Konfiguration zusammengeführt.

Wenn Sie Sandboxing aktivieren und autoAllowBashIfSandboxed auf seinen Standardwert von true belassen, laufen sandboxed Bash-Befehle ohne Aufforderung, selbst wenn Ihre Berechtigungen eine einfache Bash Ask-Regel oder die äquivalente Bash(*) Form enthalten: die Sandbox-Grenze ersetzt diese Ganz-Werkzeug-Aufforderung.

Im Plan Mode überspringt Claude Code diese Substitution. Ohne eine Ask-Regel laufen die integrierten schreibgeschützten Befehle weiterhin ohne Aufforderung, und alle anderen Shell-Befehle durchlaufen den regulären Berechtigungsfluss, während Sie noch planen; siehe Plan Mode für die Gating-Mechanismen von Claude Code dort. Mit einer einfachen Bash Ask-Regel wird jeder Bash-Befehl aufgefordert, einschließlich sandboxed schreibgeschützter Befehle, genauso wie außerhalb von Sandboxing. Vor v2.1.212 galt die Substitution auch im Plan Mode.

Diese Überprüfungen gelten weiterhin:

• Inhaltsgebundene Ask-Regeln wie Bash(git push *) erzwingen weiterhin eine Aufforderung
• Explizite Deny-Regeln gelten weiterhin
• rm- oder rmdir-Befehle, die auf einen kritischen Pfad abzielen, durchlaufen weiterhin den regulären Berechtigungsfluss

Befehle, die nicht sandboxed ausgeführt werden können, wie ausgeschlossene Befehle, respektieren die einfache Bash Ask-Regel wie gewöhnlich. Siehe Sandbox-Modi, um dieses Verhalten zu ändern.