SpyBara
Go Premium

permissions.md 2026-10-01 23:59 UTC to 2026-10-02 16:57 UTC

This page contains 135 additions and 124 deletions.

2026
Thu 1 23:59 Fri 2 18:59

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.

Werkzeugtyp Beispiel Genehmigung erforderlich Verhalten „Ja, nicht mehr fragen"
Nur Lesen Dateilesevorgänge, Grep Nein, innerhalb des Arbeitsverzeichnisses und zusätzlicher Verzeichnisse N/A
Bash-Befehle Shell-Ausführung Ja, außer einer integrierten Reihe von schreibgeschützten Befehlen Dauerhaft pro Projektverzeichnis und Befehl
Dateiänderung Dateien bearbeiten/schreiben Ja Bis zum Ende der Sitzung
Web-Abruf WebFetch Ja, außer einer integrierten Reihe von vorab genehmigten Dokumentationsdomänen Dauerhaft pro Projektverzeichnis und Domäne
Websuche WebSearch Ja Dauerhaft pro Projektverzeichnis

Eine Berechtigungsabfrage zeigt, was Claude gerade tun möchte, gefolgt von Ihren Optionen. Dieses Beispiel ist die Abfrage für einen Bash-Befehl aus einer Sitzung im Manual-Modus:

Eine Berechtigungsabfrage von Claude Code mit dem Titel Bash command. Unter einem Tipp zum Auto-Modus zeigt sie die Beschreibung 'Run the test suite', den Befehl npm test und die Zeile 'This command requires approval' und fragt dann 'Do you want to proceed?' mit vier Optionen: Yes; Yes, and don't ask again for: npm test *; Yes, and switch to auto mode; und No. Eine Fußzeile listet zwei Tasten auf: Esc zum Abbrechen und Tab zum Ergänzen. Eine Berechtigungsabfrage von Claude Code mit dem Titel Bash command. Unter einem Tipp zum Auto-Modus zeigt sie die Beschreibung 'Run the test suite', den Befehl npm test und die Zeile 'This command requires approval' und fragt dann 'Do you want to proceed?' mit vier Optionen: Yes; Yes, and don't ask again for: npm test *; Yes, and switch to auto mode; und No. Eine Fußzeile listet zwei Tasten auf: Esc zum Abbrechen und Tab zum Ergänzen.

Die dritte Option, Ja, und zum Auto-Modus wechseln, erscheint nicht bei jeder Abfrage.

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.

Genehmigungsmodi

Claude Code unterstützt mehrere Genehmigungsmodi, die steuern, wie es Werkzeugaufrufe genehmigt. Siehe Genehmigungsmodi für die Verwendung der einzelnen Modi. Um den Modus zu ändern, in dem Sitzungen starten, setzen Sie defaultMode in Ihren Einstellungsdateien. Welcher Modus eine Sitzung startet behandelt den integrierten Standard für jeden Plan und was die VS Code-Erweiterung liest.

Modus Beschreibung
default Fordert Genehmigung bei der ersten Verwendung jedes Werkzeugs an. In der CLI, den VS Code- und JetBrains-Erweiterungen sowie der Desktop-App als „Manual" gekennzeichnet, und Claude Code akzeptiert manual als Alias. Die Bezeichnung und der Alias erfordern Claude Code v2.1.200 oder später. Die Bezeichnung der Desktop-App hängt nicht von Ihrer CLI-Version ab
acceptEdits Akzeptiert automatisch Dateibearbeitungen und häufige Dateisystembefehle wie mkdir, touch, mv und cp für Pfade im Arbeitsverzeichnis oder additionalDirectories
plan Claude liest Dateien und führt schreibgeschützte Shell-Befehle aus, um zu erkunden, bearbeitet aber nicht Ihre Quelldateien; mit Auto-Modus verfügbar, genehmigungsklassifizierte Befehle werden auch ausgeführt. In der CLI und der VS Code-Erweiterung als „Plan" gekennzeichnet
auto Wird ohne routinemäßige Eingabeaufforderungen ausgeführt; bevor Aktionen wie Shell-Befehle und Netzwerkanfragen ausgeführt werden, überprüft ein Hintergrund-Klassifizierer, dass sie mit Ihrer Anfrage übereinstimmen
dontAsk Lehnt automatisch jeden Aufruf ab, der sonst eine Eingabeaufforderung auslösen würde; Dateilesevorgänge in Ihren Arbeitsverzeichnissen und andere Aktionen, die keine Genehmigung benötigen, werden weiterhin ausgeführt, ebenso wie Werkzeuge, die über /permissions oder permissions.allow-Regeln vorab genehmigt wurden. AskUserQuestion, MCP-Werkzeuge, die mit requiresUserInteraction gekennzeichnet sind, und Connector-Werkzeuge, die Ihre Organisation auf ask in Sitzungen gesetzt hat, in denen diese Einstellung Claude Code erreicht, werden verweigert, auch wenn Sie diese zugelassen haben
bypassPermissions Überspringt Genehmigungsaufforderungen, außer für die Aktionen, die kein Modus automatisch genehmigt

Um zu verhindern, dass der bypassPermissions- oder auto-Modus verwendet wird, setzen Sie permissions.disableBypassPermissionsMode oder permissions.disableAutoMode auf "disable" in einer beliebigen Einstellungsdatei. 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:

Regel Effekt
Bash Gleicht alle Bash-Befehle ab
WebFetch Gleicht alle Web-Fetch-Anfragen ab
Read Gleicht alle Dateilesevorgänge ab

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:

Regel Effekt
Bash(npm run build) Gleicht den genauen Befehl npm run build ab
Read(./.env) Gleicht das Lesen der .env-Datei im aktuellen Verzeichnis ab
WebFetch(domain:example.com) Gleicht Fetch-Anfragen an example.com ab

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:

Regel Passt
Agent(model:opus) Agent-Aufrufe, die das Opus-Modell-Tier anfordern
Agent(isolation:worktree) Agent-Aufrufe, die ein Git-Worktree anfordern
Bash(run_in_background:true) Bash-Aufrufe, die im Hintergrund ausgeführt werden

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
  • Eine Skill(skill:<name>)-Ablehnungsregel gleicht stattdessen die Fähigkeit unter jedem ihrer Namen ab, wie ihrem Alias oder Anzeigenamen
  • 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:

Sie schreiben Gleicht ab Gleicht nicht ab
Bash(npm run build) npm run build npm run build --watch
Bash(npm run *) npm run build, npm run test --watch, npm run npm install
Bash(git log * main) git log --oneline main, git log -5 main, git log --output=<file> main git log main, git push origin main
Bash(git * main) git merge main, git push origin main, git -c core.fsmonitor=<script> diff main git log
Bash(* --version) node --version, bash -c 'echo hi' --version node -v
Bash(ls *) ls -la, ls lsof
Bash(ls*) ls -la, lsof
Bash(* --help *) npm --help x npm --help

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.

Toolspezifische Berechtigungsregeln

Bash

Bash-Regeln 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, nur lesende Befehle und Umleitungen.

Zusammengesetzte Befehle

deny- und ask-Regeln gelten, wenn ein beliebiger Unterbefehl sie abgleicht, einschließlich eines Befehls, der in einer Subshell, einer Befehlsersetzung oder einem Kontrollfluss-Body wie einer for-Schleife verschachtelt ist. Eine ask-Regel wie Bash(git clean *) fragt bei cd /tmp && git clean -f oder echo "$(git clean -f)" weiterhin bei Ihnen nach, auch im Auto-Modus.

Wenn nach && oder || nichts folgt, wie in npm test &&, behandelt Claude Code den Befehl als nicht analysierbar und teilt ihn für den Abgleich mit allow-Regeln nicht in Unterbefehle 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 eine 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 Verzeichnis außerhalb Ihrer Arbeitsverzeichnisse erzeugen 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, außerdem die Shell-Builtins command und builtin sowie noglob von zsh. Jeder führt sein Argument als den eigentlichen Befehl aus. Zwei verwandte Formen werden nicht entfernt: die Abfrageform command -v, die einen Befehl nachschlägt, anstatt ihn auszuführen, und nocorrect von zsh.

Claude Code entfernt auch eine führende Zuweisung bestimmter als sicher bekannter Umgebungsvariablen, daher gleicht Bash(npm test *) NODE_ENV=test npm test ab. Eine allow-Regel gleicht nicht über die 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 weiterhin FOO=bar rm -rf tmp/ ab.

Ein bloßes xargs wird ebenfalls 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. Runner für Entwicklungsumgebungen 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 wird im Manual-Modus bei ihnen immer nachgefragt. Dasselbe gilt für find mit -exec oder -delete: Eine Bash(find *)-Regel deckt diese Formen nicht ab. Um einen bestimmten Aufruf zu genehmigen, schreiben Sie eine Regel mit exakter Übereinstimmung 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 dasselbe Programm ab, wenn es 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:

Regel Stoppt Stoppt nicht
Bash(curl *) curl https://example.com /usr/bin/curl https://example.com, sh -c 'curl https://example.com'
Bash(rm *) rm -rf build/ /bin/rm -rf build/, bash -c 'rm -rf build/'
Bash(git push *) git push origin main git -C . push origin main, git -c push.default=current push origin main, git 'push' origin main

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

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

Nur lesende Befehle

Claude Code erkennt einen integrierten Satz von Bash-Befehlen als nur lesend und führt sie in jedem Modus ohne Berechtigungsabfrage aus, außer soweit permissions.blockReadsOutsideWorkingDirectories dies für Pfade außerhalb Ihrer Arbeitsverzeichnisse ändert. Der Satz umfasst ls, cat, echo, pwd, head, tail, grep, find, wc, which, diff, stat, du, cd und nur lesende Formen von git. Der Satz ist nicht konfigurierbar; um für einen dieser Befehle eine Abfrage zu erzwingen, fügen Sie eine ask- oder deny-Regel dafür hinzu. Im Auto-Modus können diese Befehle auch auf die Überprüfung durch den Klassifikator warten; siehe wie der Klassifikator Aktionen bewertet.

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

Nicht in Anführungszeichen gesetzte Glob-Muster sind für Befehle zulässig, deren Flags alle nur lesend sind, daher laufen ls *.ts und wc -l src/*.py ohne Abfrage.

Im Manual-Modus wird bei Befehlen aus diesem Satz in folgenden Fällen dennoch nachgefragt:

  • Nicht in Anführungszeichen gesetzte Globs bei Befehlen mit schreibfähigen Flags: Bei Befehlen mit schreib- oder ausführungsfähigen Flags, wie find, sort, sed und git, wird nachgefragt, wenn ein nicht in Anführungszeichen gesetzter Glob vorhanden ist, da der Glob zu einem Flag wie -delete expandieren könnte.
  • docker mit Verweis auf einen anderen Daemon: Bei nur lesenden Formen von docker wird nachgefragt, wenn der Befehl ein Flag enthält, das einen anderen Daemon auswählt, wie -H, --context oder die Podman-Flags --url und --connection.
  • file mit Flags, die Pfade öffnen: Bei file wird nachgefragt, wenn es -m/--magic-file oder -f/--files-from übergibt, da diese Flags file dazu veranlassen, die im Wert des Flags genannten Pfade zu öffnen.
  • Netzwerkpfade unter Windows: Bei einem Befehl, dessen Argumente einen Netzwerkpfad (UNC-Pfad) wie \\server\share\file enthalten, wird nachgefragt, da der Zugriff auf einen Netzwerkpfad Ihre Windows-Anmeldedaten an den genannten Host senden kann. Dieselbe Prüfung gilt für Befehle des PowerShell-Tools.
  • Schreibzugriffe auf spezielle Shell-Variablen: Bei einem Befehl, der bestimmte spezielle Shell-Variablen wie PATH oder IFS setzt, zurücksetzt oder über sie iteriert, wird nachgefragt, auch wenn der Rest des Befehls nur lesend ist.
  • Befehle, die die Analyse nicht parsen kann: Wenn Claude Code einen Befehl nicht vollständig parsen kann, bittet es um Genehmigung, anstatt den Befehl als nur lesend zu behandeln. Bei Befehlen mit mehr als 10.000 Zeichen wird immer nachgefragt, da sie den Umfang überschreiten, den die Analyse parst.

Ein cd in einen Pfad innerhalb Ihres Arbeitsverzeichnisses oder eines zusätzlichen Verzeichnisses ist ebenfalls nur lesend, und ein zusammengesetzter Befehl wie cd packages/api && ls läuft ohne Abfrage, wenn jeder Teil für sich die Bedingungen erfüllt. Bei diesen Kombinationen wird nachgefragt, auch wenn jeder Teil nur lesend ist:

  • cd mit git: Es wird nachgefragt, wenn das 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 keine Abfrage aus.
  • cd mit einer Umleitung: Es wird nachgefragt, wenn Claude Code nicht bestimmen kann, relativ zu welchem Verzeichnis das Umleitungsziel nach der Ausführung von cd aufgelöst wird. Bei einem Befehl, dessen einziges Umleitungsziel /dev/null ist, wie cd app; grep -r pattern . 2>/dev/null, wird nicht nachgefragt, da /dev/null nicht vom Arbeitsverzeichnis abhängt.

Umleitungen

Wenn ein Befehl Ausgabe oder Eingabe umleitet, prüft Claude Code das Umleitungsziel anhand Ihrer Dateiregeln, als hätte Claude diese Datei direkt geschrieben oder gelesen:

  • Ausgabeumleitungen: Bei > file, >> file oder 2> file umfasst die Prüfung Ihre Edit-allow- und -deny-Regeln, geschützte Pfade und die Arbeitsverzeichnisse. Eine Regel wie Bash(git commit *) erlaubt den Befehl, nicht das Ziel. Ein Ziel, das mit ~ beginnt oder ein Glob-Zeichen enthält, erfordert Ihre Genehmigung.
  • Eingabeumleitungen: Bei < file umfasst die Prüfung Ihre Read-allow- und -deny-Regeln und die Arbeitsverzeichnisse. Ein Ziel außerhalb der Arbeitsverzeichnisse erfordert Ihre Genehmigung, sofern keine allow-Regel es abdeckt. Ein Ziel, das ein Glob-Muster enthält, oder ein relativer Pfad, der auf ein cd im selben Befehl folgt, erfordert Ihre Genehmigung, auch wenn eine allow-Regel es abdeckt. Claude Code prüft Eingabeziele ab v2.1.257.

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

Claude Code prüft auch die Dateien, die ein tee-Befehl schreibt, auch in einer Pipeline wie make | tee build.log. Die Prüfung umfasst Ihre Edit-allow- und -deny-Regeln, geschützte Pfade und die Arbeitsverzeichnisse. Eine allow-Regel wie Bash(tee *) deckt kein Ziel außerhalb der Arbeitsverzeichnisse ab. Claude Code prüft tee-Ziele ab v2.1.269.

PowerShell

PowerShell-Berechtigungsregeln haben dieselbe Form wie Bash-Regeln. Wildcards 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 erlaubt Get-ChildItem- und git commit-Befehle und blockiert Remove-Item:

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

Gängige Aliase werden vor dem Abgleich kanonisiert. Eine Regel, die für den Cmdlet-Namen geschrieben wurde, gleicht auch dessen Aliase ab, daher gleicht PowerShell(Get-ChildItem *) auch gci, ls und dir ab. Beim Abgleich wird die Groß-/Kleinschreibung nicht beachtet.

Claude Code parst den PowerShell-AST und prüft jeden Befehl in einem zusammengesetzten Befehl unabhängig. Pipeline-Operatoren |, Anweisungstrennzeichen ; und unter PowerShell 7+ die Verkettungsoperatoren && 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 zu verhindern, dass die Datei-Tools von Claude eine Datei oder ein Verzeichnis lesen, fügen Sie eine Read-deny-Regel für den Pfad hinzu, wie Read(./.env) oder Read(./secrets/**); Sensible Dateien ausschließen enthält ein Beispiel zum Einfügen. Falls Ihr Projekt eine .claudeignore-Datei hat, bleibt diese wirkungslos; übertragen Sie ihre Einträge daher in Read-deny-Regeln.

Edit-Regeln gelten für alle integrierten Tools, die Dateien bearbeiten. Claude versucht nach bestem Bemühen, Read-Regeln auf alle integrierten Tools anzuwenden, die Dateien lesen, wie Grep und Glob, auf @file-Erwähnungen in Ihren Prompts sowie auf den Auswahl- und Kontext geöffneter Dateien, den eine verbundene IDE mit Claude teilt.

Eine Read-deny-Regel blockiert auch die Edit- und Write-Tools für denselben Pfad, einschließlich des Erstellens einer neuen Datei dort. NotebookEdit ist nicht abgedeckt, daher fügen Sie eine Edit-deny-Regel für Pfade hinzu, die kein Tool ändern darf. Die Prüfung erfordert Claude Code v2.1.208 oder höher für Bearbeitungen und v2.1.228 oder höher für Schreibvorgänge.

Claude Code prüft Dateiberechtigungen nur anhand von Edit(path)- und Read(path)-Regeln. Wenn Sie stattdessen eine Pfadregel für Write, NotebookEdit, Glob oder das veraltete MultiEdit-Tool schreiben, akzeptiert Claude Code die Regel, berücksichtigt sie aber nie und warnt beim Start, außer bei einer 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 Regel mit Tool-Namen ohne Pfad, wie einer deny-Regel für Write; es gleicht diese Regel überall auf Tool-Ebene ab. Erfordert Claude Code v2.1.210 oder höher.

Read- und Edit-Regeln verwenden beide die Mustersyntax von gitignore mit vier unterschiedlichen Mustertypen; bei Verzeichnismustern mit einem einzelnen Segment hängt die Abgleichtiefe zusätzlich vom Regeltyp ab, wie später in diesem Abschnitt beschrieben:

Muster Bedeutung Beispiel Gleicht ab
//path Absoluter Pfad ab dem Dateisystem-Root Read(//Users/alice/secrets/**) /Users/alice/secrets/**
~/path Pfad ab dem Home-Verzeichnis Read(~/Documents/*.pdf) /Users/alice/Documents/*.pdf
/path Pfad relativ zur Einstellungsquelle Edit(/src/**/*.ts) <primary working directory>/src/**/*.ts in Projekteinstellungen
path oder ./path Pfad relativ zum aktuellen Verzeichnis Read(*.env) <cwd>/*.env

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

Regel definiert in /path wird aufgelöst zu
Projekteinstellungen unter .claude/settings.json <primary working directory>/path
Lokale Einstellungen unter .claude/settings.local.json <primary working directory>/path
Benutzereinstellungen unter ~/.claude/settings.json ~/.claude/path
Eine mit --settings <file> übergebene Datei <directory of file>/path
CLI-Flags oder Sitzungsregeln <primary working directory>/path

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

Regeln in lokalen Einstellungen verankern ab v2.1.211 am primären Arbeitsverzeichnis der Sitzung, nicht am Repository-Root, wo Claude Code die Datei speichert. In einer Sitzung, die im Repository-Root gestartet wurde, sind beide Verzeichnisse identisch; in einer Worktree-Sitzung gleicht eine gemeinsam genutzte Regel wie Edit(/src/**) das eigene src/-Verzeichnis dieses Worktrees ab.

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

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 in /docs/ oder <primary working directory>/.claude/docs/
  • Read(~/.zshrc): liest die .zshrc in Ihrem Home-Verzeichnis
  • Edit(//tmp/scratch.txt): bearbeitet den absoluten Pfad /tmp/scratch.txt
  • Read(src/**): als allow-Regel nur Lesezugriffe aus <current-directory>/src/; als deny- oder ask-Regel gleicht sie ein src-Verzeichnis in beliebiger Tiefe unter dem aktuellen Verzeichnis ab

Eine Regel gleicht nur Dateien unterhalb ihres Ankers ab; innerhalb dieser Grenze hängt die Abgleichtiefe von der Musterform und bei Verzeichnismustern mit einem einzelnen Segment vom Regeltyp ab, wie unten beschrieben. Bloße Dateinamen folgen der gitignore-Semantik und gleichen in beliebiger Tiefe ab, daher sind Read(.env) und Read(**/.env) gleichwertig:

deny-Regel Blockiert Blockiert nicht
Read(.env) oder Read(**/.env) jede .env im oder unterhalb des aktuellen Verzeichnisses .env in einem übergeordneten Verzeichnis oder einem anderen Projekt
Read(//**/.env) jede .env an beliebiger Stelle im Dateisystem nichts; die Regel ist am Dateisystem-Root verankert

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

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

Jede andere Musterform gleicht in jedem Regeltyp in derselben Tiefe ab: Edit(/src/**) und Edit(src/components/**) gleichen nur an ihrer verankerten Position ab, während Edit(**/src/**) in beliebiger Tiefe abgleicht.

Das folgende Beispiel zeigt jede Musterform anhand eines Projekts mit einem src/-Verzeichnis auf oberster Ebene und einer verschachtelten Kopie unter vendor/:

<current-directory>/
├── src/
│   └── app.ts
└── vendor/
    └── pkg/
        └── src/
            └── lib.js
Regel Gleicht src/app.ts ab Gleicht vendor/pkg/src/lib.js ab
Edit(src/**) als allow-Regel Ja Nein
Edit(src/**) als deny- oder ask-Regel Ja Ja
Edit(/src/**) in jedem Regeltyp Ja Nein
Edit(**/src/**) in jedem Regeltyp Ja Ja

Wenn Sie einen Dateipfad mit „Ja, nicht mehr fragen" genehmigen, maskiert Claude Code gitignore-Musterzeichen in diesem Pfad, wie [, ] und *, sodass die erzeugte Regel nur den wörtlichen Pfad abgleicht, den Sie genehmigt haben. Regeln, die Sie selbst schreiben, werden nicht maskiert. Vor v2.1.202 speicherte Claude Code den Pfad unmaskiert, sodass eine erzeugte Regel für ein Verzeichnis namens [2024-06] Reports ihren eigenen Pfad möglicherweise nicht abglich oder unbeabsichtigt benachbarte Verzeichnisse abglich.

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

Eine deny- oder ask-Regel, deren Pfad nicht als gitignore-Muster verwendbar ist, schützt dennoch genau diesen Pfad. Eine allow-Regel mit einem nicht verwendbaren Muster genehmigt nichts.

Ein deny- oder ask-Muster, das mit ! beginnt, ist eine gitignore-Negation. Es nimmt die Pfade, die es abgleicht, aus den davor aufgeführten path- oder ./path-Regeln aus. In der deny-Liste einer Einstellungsdatei blockiert Read(*.env) gefolgt von Read(!sample.env) jede Datei in beliebiger Tiefe, deren Name auf .env endet, außer Dateien namens sample.env. Eine !-Regel, die zuerst aufgeführt ist, nimmt nichts aus.

Die Ausnahme wirkt nur auf Regeln aus derselben Quelle. Ein Read(!.env) in Projekteinstellungen oder in --disallowedTools hebt eine Read(./.env)-deny-Regel aus verwalteten Einstellungen oder einer anderen Einstellungsdatei nicht auf.

Zwei Einschränkungen begrenzen, was ein !-Muster ausnehmen kann:

  • Claude Code liest ein !-Muster relativ zum aktuellen Verzeichnis, auch wenn /, ~/ oder // auf das ! folgt, daher kann das Muster keine Regel erreichen, die mit einem dieser Präfixe verankert ist. Read(!~/notes/public/**) nimmt nichts aus Read(~/notes/**) aus.
  • Eine Ausnahme kann keine Datei innerhalb eines Verzeichnisses wieder freigeben, das eine Regel als Ganzes blockiert. Mit Read(secrets/**) und Read(!secrets/public/**) blockiert Claude Code secrets/public weiterhin zusammen mit dem Rest von secrets.

Wenn ein Dateipfad, den Claude anfordert, über einen Symlink führt, umfasst die Berechtigungsprüfung zwei Pfade: den von Claude angeforderten und die Datei, zu der er aufgelöst wird. Dies gilt für symbolische Links unter macOS, Linux und Windows sowie für Verzeichnis-Junctions unter Windows.

Wie Regeln einen Pfad mit Symlink abgleichen

allow- und deny-Regeln behandeln den angeforderten Pfad und die Datei, zu der er aufgelöst wird, unterschiedlich:

  • allow-Regeln: gelten nur, wenn sowohl der angeforderte Pfad als auch die Datei, zu der er aufgelöst wird, übereinstimmen. Ein Lesezugriff über einen Symlink innerhalb eines zulässigen Verzeichnisses, der nach außerhalb davon zeigt, gleicht die Regel nicht ab.
  • deny-Regeln: gelten, wenn entweder der angeforderte Pfad oder die Datei, zu der er aufgelöst wird, übereinstimmt. Ein Symlink, der auf eine verweigerte Datei zeigt, ist selbst verweigert. Wenn beispielsweise Read(./project/**) erlaubt und Read(~/.ssh/**) verweigert ist, wird ein Symlink unter ./project/key, der auf ~/.ssh/id_rsa zeigt, blockiert: Das Ziel erfüllt die allow-Regel nicht und gleicht die deny-Regel ab.

Unter macOS und Linux gilt eine deny- oder ask-Regel, die über ein per Symlink verknüpftes Verzeichnis mit einem //-, ~/- oder /-Muster geschrieben wurde, auch am tatsächlichen Ort des Verzeichnisses. Unter macOS beispielsweise, 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 über ein per Symlink verknüpftes Verzeichnis geschrieben wurde, nicht für einen Pfad, der über dessen tatsächlichen Ort angegeben wurde.

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

Wenn der Pfad, den Claude bearbeiten oder schreiben möchte, selbst ein Symlink ist, verweigern die Edit- und Write-Tools den Schreibvorgang und verweisen Claude auf das Ziel des Links.

Ein Schreibvorgang kann dennoch über einen Symlink erfolgen, wenn ein Verzeichnis auf dem Weg zur Datei ein Symlink ist oder wenn ein Bash- oder PowerShell-Befehl das Schreiben übernimmt. Bei diesen Schreibvorgängen hängt das Ergebnis davon ab, wo die Datei, zu der der Schreibvorgang aufgelöst wird, relativ zu Ihren Arbeitsverzeichnissen und den geschützten Pfaden liegt:

  • Auflösung außerhalb der Arbeitsverzeichnisse: Wenn der angeforderte Pfad innerhalb Ihrer Arbeitsverzeichnisse liegt und die Datei, zu der er aufgelöst wird, nicht, wird der Schreibvorgang im acceptEdits-Modus nicht automatisch genehmigt. Im Auto-Modus werden Sie, sofern keine allow-Regel den Schreibvorgang genehmigt, um Bestätigung gebeten, anstatt dass der Klassifikator entscheidet. Die Abfrage nennt den Pfad, zu dem der Schreibvorgang aufgelöst wird.
  • Auflösung zu einem geschützten Pfad, den der angeforderte Pfad nicht nennt: Die Tabelle der geschützten Pfade gibt das Ergebnis für jeden Berechtigungsmodus an, mit der Ausnahme, dass dort, wo die Tabelle den Schreibvorgang an den Klassifikator weiterleitet, stattdessen bei Ihnen nachgefragt wird.
Pfade, die nicht aufgelöst werden können oder die sich ändern

Wenn Claude Code nicht bestimmen kann, wohin ein Pfad auf dem Datenträger führt, zum Beispiel weil Symlinks darin eine Schleife bilden, verweigern die Read-, Edit- und Write-Tools den Vorgang.

Wenn ein Tool anschließend die genehmigte Datei öffnet, bestätigt es, dass der Pfad weiterhin zu dem Ort aufgelöst wird, den die Berechtigungsprüfung genehmigt hat.

WebFetch

WebFetch-Regeln verwenden ein domain:-Präfix und gleichen den Hostnamen der angeforderten URL ab. Beim Abgleich wird die Groß-/Kleinschreibung nicht beachtet, *-Wildcards werden unterstützt, und ein nachgestellter . wird sowohl aus der Regel als auch aus dem Hostnamen entfernt, sodass example.com. und example.com gleich behandelt werden.

  • WebFetch(domain:example.com) gleicht Anfragen an example.com ab
  • WebFetch(domain:*.example.com) gleicht jede Subdomain in beliebiger 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 dasselbe wie eine bloße WebFetch-Regel; siehe Jeden Abruf zulassen oder verweigern

An jeder Position außer einem führenden *. oder einem bloßen * gleicht die Wildcard nur den Text zwischen zwei Punkten ab. WebFetch(domain:example.*) gleicht example.org ab, wobei * zu org wird, aber nicht example.evil.com, wobei * zu evil.com werden und einen Punkt überschreiten müsste. So wird verhindert, dass eine nachgestellte Wildcard Domains abgleicht, die ein Angreifer registrieren könnte.

Wildcards in WebFetch-Regeln erfordern Claude Code v2.1.172 oder höher, um Abrufe abzugleichen.

Jeden Abruf zulassen oder verweigern

Eine bloße WebFetch-Regel ist der Tool-Name 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 zusätzlich zur Liste erlaubter oder verweigerter Domains der Sandbox hinzu. Dieser Abschnitt listet die Wildcard-Formen auf, die die Sandbox berücksichtigt, sowie die Version, mit der das bloße * hinzukam.

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

Regel In allow In deny
WebFetch Claude ruft ohne Nachfrage ab. Ändert nicht, welche Hosts in der Sandbox ausgeführte Befehle erreichen können. Claude Code entfernt das WebFetch-Tool, sodass Claude überhaupt nicht abrufen kann. Ändert nicht, welche Hosts in der Sandbox ausgeführte Befehle erreichen können.
WebFetch(domain:*) Claude ruft ohne Nachfrage ab, und in der Sandbox ausgeführte Befehle können jeden Host erreichen. Claude Code behält das Tool bei und verweigert jeden Abruf, und in der Sandbox ausgeführte Befehle können keinen Host erreichen.

Die beiden Formen unterscheiden sich auch beim Lesen von Artefakten, den Seiten, die das Artifact-Tool auf claude.ai veröffentlicht. Eine bloße WebFetch-deny- oder -ask-Regel gilt nicht für diese Lesevorgänge. Eine domain:-Regel, die claude.ai oder den Content-Host *.claudeusercontent.com abdeckt, wie WebFetch(domain:claude.ai) oder WebFetch(domain:*), verweigert jeden Lesevorgang oder fragt vorher nach. Eine Artifact-Regel bewirkt dasselbe.

Wenn eine Regel einen Lesevorgang blockiert, nennt die Ablehnung die Regel. Vor v2.1.268 blockierte eine bloße WebFetch-deny-Regel jeden Artefakt-Lesevorgang, und eine bloße ask-Regel fragte vor jedem nach.

Um Claude frei abrufen zu lassen und die Allowlist der Sandbox unverändert zu lassen, verwenden Sie die bloße Form. Diese settings.json bewirkt das:

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

Wenn Sie Claude bitten, eine Seite abzurufen, ruft es sie ohne Nachfrage ab. Wenn Sie es bitten, ein in der Sandbox ausgeführtes curl gegen einen Host außerhalb der Allowlist der Sandbox auszuführen, fragt Claude Code für diesen Host weiterhin bei Ihnen nach, da die bloße Regel den Host nicht zur Allowlist hinzugefügt hat.

Im Auto-Modus nennt Claude den Host stattdessen in den pro Befehl zulässigen Domains des Befehls, damit der Klassifikator ihn prüft.

MCP

MCP-Regeln verwenden den Servernamen, wie er in Claude Code konfiguriert ist, optional gefolgt vom Namen eines Tools dieses Servers.

  • mcp__puppeteer gleicht jedes Tool ab, das der puppeteer-Server bereitstellt
  • mcp__puppeteer__* verwendet Wildcard-Syntax und gleicht ebenfalls alle Tools des puppeteer-Servers ab
  • mcp__puppeteer__puppeteer_navigate gleicht das Tool puppeteer_navigate ab, das der puppeteer-Server bereitstellt

Wenn Ihre Organisation ein Tool eines claude.ai-Konnektors auf ask gesetzt hat und diese Einstellung in Ihrer Sitzung bei Claude Code ankommt, werden allow-Regeln für dieses Tool nicht wirksam: Claude Code fragt bei jedem Aufruf nach, auch in den Modi auto und bypassPermissions. Im dontAsk-Modus, der nie nachfragt, verweigert Claude Code den Aufruf stattdessen. Tools von Konnektoren, 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 das Cowork-Tool mcp__workspace__bash statt über das integrierte Bash-Tool aus, und Cowork stellt ebenso mcp__workspace__web_fetch für Webabrufe bereit. Claude Code wendet deny-Regeln, die das gesamte Bash- oder WebFetch-Tool benennen, auch auf diese Cowork-Tools an, sodass eine verwaltete Bash-deny-Regel Claude daran hindert, in Cowork Shell-Befehle auszuführen. Wenn Claude Code einen solchen Aufruf blockiert, nennt die Meldung das Cowork-Tool: Permission to use mcp__workspace__bash has been denied. allow-Regeln werden nicht übertragen: Claude Code wendet eine Bash-allow-Regel nie auf mcp__workspace__bash an.

Agent (Subagenten)

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

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

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

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

Cd

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

Eine bloße Cd-deny-Regel deaktiviert /cd vollständig. Eine Cd(<path-pattern>)-deny-Regel blockiert übereinstimmende Ziele. deny-Regeln prüfen jede Schreibweise des Ziels, einschließlich jedes Symlink-Schritts, über den es aufgelöst wird, sodass eine für einen Pfad geschriebene Regel auch Ziele blockiert, die zu diesem Pfad aufgelöst werden.

Das Hinzufügen einer beliebigen Cd-allow-Regel schaltet /cd in den Allowlist-Modus: Das aufgelöste Zielverzeichnis muss einer Ihrer allow-Regeln entsprechen, sonst verweigert /cd den Wechsel. Ohne konfigurierte Cd-Regeln behält /cd sein Standardverhalten bei und fragt Sie, ob Sie einem unbekannten Verzeichnis vertrauen.

Pfadmuster verwenden dieselben Anker //, ~/ und / wie Read- und Edit-Regeln, aber der Abgleich ist am gesamten Verzeichnispfad verankert und nicht im gitignore-Stil. * gleicht genau ein Pfadsegment ab, und ** gleicht über Segmente hinweg ab. Ein nachgestelltes /** gleicht auch das benannte Stammverzeichnis selbst ab.

Regel Gleicht ab Gleicht nicht ab
Cd(~/code/*) ~/code/app ~/code/app/src, ~/code
Cd(~/code/**) ~/code und jedes Verzeichnis darunter Verzeichnisse außerhalb von ~/code
Cd(**/node_modules) jedes node_modules-Verzeichnis in beliebiger Tiefe unter dem aktuellen Verzeichnis node_modules/pkg

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.

PreToolUse-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.

Dieser Vorrang gilt für Hooks in Einstellungsdateien und in der hooks/hooks.json eines Plugins. Ein Mod, den Sie installieren und der tool.check verarbeitet, antwortet, nachdem die Regeln und die PreToolUse-Hooks entschieden haben, und seine Antwort kann deren Antwort ersetzen:

  • Ask-Regeln: Der Mod kann einen Aufruf genehmigen, für den eine Ask-Regel eine Aufforderung anzeigen würde
  • Eine Blockierung durch einen PreToolUse-Hook: Der Mod kann den Aufruf genehmigen, es sei denn, der Hook befindet sich in verwalteten Einstellungen
  • Der Auto-Modus-Klassifizierer: Im Auto-Modus wird ein Aufruf, den der Mod genehmigt, ohne eine Klassifizierer-Überprüfung ausgeführt
  • Deny-Regeln: Auf einem Computer mit verwalteten Einstellungen oder wenn Sie mit einem Team- oder Enterprise-Plan angemeldet sind, haben Deny-Regeln standardmäßig Vorrang vor dem Mod, und Ihre Organisation kann dies ändern. Überall sonst kann der Mod einen Aufruf genehmigen, den eine Deny-Regel ablehnt.

Siehe Entscheiden Sie, ob Sie einem Mod vertrauen, oder Verwalten Sie Mods für Ihre Organisation, wenn Sie verwaltete Einstellungen bereitstellen.

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:

Konfiguration Geladen aus --add-dir
Skills in .claude/skills/ Ja, mit Live-Reload
Befehlsdateien in .claude/commands/ Ja, ohne Live-Reload. Wenn das hinzugefügte Verzeichnis und Ihr Projekt beide einen Befehl mit demselben Namen definieren, führt Claude Code Ihren Projektbefehl aus
Subagents in .claude/agents/ Ja, ohne Live-Reload
Einstellungen in .claude/settings.json und .claude/settings.local.json Nur enabledPlugins und extraKnownMarketplaces-Schlüssel
CLAUDE.md-Dateien, .claude/rules/ und CLAUDE.local.md Nur wenn CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 gesetzt ist. CLAUDE.local.md erfordert zusätzlich die local-Einstellungsquelle, die standardmäßig aktiviert ist

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.

Verwaltete Einstellungen

Für Organisationen, die eine zentralisierte Kontrolle benötigen, stellen Administratoren verwaltete Einstellungen bereit, die Benutzer- und Projekteinstellungen nicht überschreiben können, mit Ausnahme einiger sicherheitssensibler Schlüssel. Verwaltete Einstellungen bereitstellen behandelt die Bereitstellungsmechanismen, die Rangfolge innerhalb der verwalteten Ebene und die Schlüssel, die nur verwaltete Einstellungen setzen können.

Einer dieser Schlüssel, allowManagedPermissionRulesOnly, macht verwaltete Einstellungen zur einzigen Einstellungsquelle für Berechtigungsregeln. Sein Eintrag listet jede Quelle auf, die Claude Code dann ignoriert.

disableBypassPermissionsMode wird normalerweise in verwalteten Einstellungen platziert, um Organisationsrichtlinien durchzusetzen, funktioniert aber aus jedem Bereich. Ein Benutzer kann es in seinen eigenen Einstellungen festlegen, um sich selbst aus dem Bypass-Modus auszusperren.

Einstellungspriorität

Berechtigungsregeln folgen der gleichen Einstellungspriorität wie alle anderen Claude Code-Einstellungen, wobei verwaltete Einstellungen am höchsten sind: Keine andere Ebene, einschließlich Befehlszeilenargumenten, kann eine verwaltete Berechtigungsregel überschreiben.

Wenn ein Werkzeug auf einer beliebigen Ebene verweigert wird, kann keine andere Ebene es zulassen. Zum Beispiel kann eine verwaltete Einstellungs-Deny nicht durch --allowedTools überschrieben werden, und --disallowedTools kann Einschränkungen über das hinaus hinzufügen, was verwaltete Einstellungen definieren.

Das Gleiche gilt für Einstellungsbereiche: Wenn Benutzereinstellungen eine Berechtigung zulassen und Projekteinstellungen sie verweigern, blockiert die Deny-Regel sie. Das Gegenteil ist auch wahr: eine Deny-Regel auf Benutzerebene blockiert eine Allow-Regel auf Projektebene, da Deny-Regeln aus jedem Bereich vor Allow-Regeln ausgewertet werden.

Diese Priorität gilt zwischen Einstellungsdateien und Befehlszeilenargumenten. Ob eine Deny-Regel gegenüber einem mod, das Sie installieren, gilt, siehe Berechtigungen mit Hooks erweitern.

Embedding-Hosts können zusätzliche verwaltete Richtlinien über die SDK-Option managedSettings bereitstellen, einschließlich Berechtigungsallow-Regeln, es sei denn, der Administrator setzt die allowManaged*Only-Sperren; Richtlinie an Claude Desktop-Sitzungen bereitstellen behandelt, wann die Embedder-Richtlinie überhaupt angewendet wird.

Projekterlaubnisregeln und Workspace-Vertrauen

permissions.allow-Regeln und permissions.additionalDirectories-Einträge in der .claude/settings.json eines Projekts gewähren Funktionen, daher wendet Claude Code sie nur an, nachdem Sie den Workspace-Vertrauensdialog für diesen Ordner akzeptiert haben. Der Dialog listet die Regeln und Verzeichnisse auf, die der Ordner gewähren würde, damit Sie diese zuerst überprüfen können. deny- und ask-Regeln sind nicht betroffen, da sie nur einschränken.

Claude Code speichert das Vertrauen, das Sie akzeptieren, je nachdem, wo Sie es starten:

  • In einem Repository speichert Claude Code das Vertrauen auf der Git-Repository-Root, sodass das Vertrauen das gesamte Repository abdeckt, mit Ausnahme von verschachtelten Git-Repositories darin, wie z. B. Submodule. In einem Worktree verwendet es die Root des Haupt-Checkouts, wie es auch für gespeicherte Regeln der Fall ist.
  • Außerhalb eines Repositorys speichert Claude Code das Vertrauen auf dem Verzeichnis, von dem aus Sie es gestartet haben, und das Vertrauen deckt alle Unterverzeichnisse dieses Verzeichnisses ab, mit Ausnahme von verschachtelten Git-Repositories darin, wie z. B. Klone. Jedes abgedeckte Unterverzeichnis zählt dann als ein Ordner, dessen übergeordnetes Verzeichnis Sie vertraut haben.
  • Wenn Sie in Ihrem Home-Verzeichnis starten, speichert Claude Code das Vertrauen nur für die aktuelle Sitzung und schreibt es nicht auf die Festplatte; siehe die Notiz zu zusätzlichen Schutzmaßnahmen.

Claude Code zeigt den Vertrauensdialog nur in interaktiven Sitzungen an. Ein claude -p-Lauf oder eine SDK-Sitzung zeigt ihn nie an, und das Vertrauen in ein übergeordnetes Verzeichnis zählt nicht für diese Regeln, daher sagt Was läuft ab, bevor Sie einem Ordner vertrauen, welche Repository-Inhalte Claude Code in jeder dieser beiden Situationen noch verwendet.

Bevor Claude Code eine Hintergrund-Sitzung startet oder neu startet, prüft Claude Code auch das Workspace-Vertrauen für das Verzeichnis, in dem die Sitzung läuft. Wenn Sie claude --bg von einem Terminal in einem Verzeichnis ausführen, dem Sie nicht vertraut haben, wird der Vertrauensdialog zuerst angezeigt und die Sitzung startet, sobald Sie ihn akzeptieren. Wo kein Dialog angezeigt werden kann, z. B. in einem Skript, beendet sich der Befehl stattdessen mit einem Workspace not trusted-Fehler.

Wenn Ihre lokale Einstellungsdatei Vertrauen benötigt

.claude/settings.local.json ist normalerweise Ihre eigene Datei, daher wendet Claude Code ihre Allow-Regeln und zusätzlichen Verzeichnisse ohne den Vertrauensschritt an. Wenn die Datei in Git verfolgt wird oder .claude ein Symlink ist, behandelt Claude Code sie stattdessen als vom Repository bereitgestellt und hält ihre Regeln zurück, bis Sie dem Ordner vertrauen.

Claude Code führt Git aus, um die beiden zu unterscheiden, und führt Git nur aus, nachdem Sie dem Ordner vertraut haben: Sie haben den Vertrauensdialog dafür oder für ein übergeordnetes Verzeichnis, dessen Vertrauen sich darauf erstreckt, akzeptiert, oder Sie befinden sich in einer -p- oder SDK-Sitzung, die als akzeptiert zählt. Bis dahin entscheidet, wo Sie Claude Code gestartet haben, was mit den Regeln der Datei geschieht:

  • In Ihrem Konfigurationsheim: Claude Code wendet die .claude/settings.local.json dieses Ordners sofort an, ohne Git auszuführen. Ihr Konfigurationsheim ist Ihr Home-Verzeichnis oder ein Verzeichnis, dessen .claude-Unterverzeichnis Sie als CLAUDE_CONFIG_DIR festgelegt haben. Wenn dieses CLAUDE_CONFIG_DIR-Verzeichnis in einem Git-Repository sitzt und Claude Code Ihre lokalen Einstellungen in der Repository-Root speichert, hält es die Regeln wie überall sonst zurück.
  • Überall sonst: Claude Code hält die Regeln der Datei wie Projekteinstellungen zurück. Sobald die Überprüfung ausgeführt wurde, wendet Claude Code die Regeln einer nicht verfolgten Datei oder einer Datei in einem Verzeichnis außerhalb eines Git-Repositorys an, obwohl Sie diesem genauen Ordner nicht vertraut haben.

In den Versionen 2.1.196 bis 2.1.199 speicherte Claude Code die Regeln der Datei in Ihrem Konfigurationsheim und außerhalb von Git-Repositorys und gab die Warnung this workspace has not been trusted dort aus. Vor v2.1.207 wendete Claude Code die Regeln einer nicht verfolgten Datei an, bevor Sie den Dialog akzeptierten.

Was läuft ab, bevor Sie einem Ordner vertrauen

Jede Zeile ist eine Art von Inhalten, die ein Repository bereitstellen kann. Die Spalten sind die beiden Situationen, in denen Sie dem Ordner selbst nicht vertraut haben: Sie haben nur einem übergeordneten Ordner vertraut, oder Sie haben claude -p oder das SDK dort ausgeführt, was nie den Vertrauensdialog anzeigt. Die Spalte für übergeordnete Ordner gilt nicht in einem verschachtelten Repository: In einer interaktiven Sitzung zeigt Claude Code den Vertrauensdialog dafür an, und ein claude -p- oder SDK-Lauf dort folgt der claude -p-Spalte.

Was das Repository bereitstellt Sie haben nur einem übergeordneten Ordner vertraut claude -p oder das SDK, Ordner wurde nie vertraut
Hooks in Einstellungsdateien, der env-Block und Hilfsbefehle wie apiKeyHelper, und die Hooks und allowed-tools eines Projektskills Verwendet Verwendet. Workspace-Vertrauen gatet nie die allowed-tools eines Skills in einer Sitzung
permissions.allow-Regeln und additionalDirectories in .claude/settings.json Nicht verwendet, bis Sie den Vertrauensdialog akzeptieren, der sie erneut auflistet Nicht verwendet. Claude Code gibt eine this workspace has not been trusted-Warnung auf stderr aus
Frontmatter-Hooks in einem Projekt-Subagent, einem Projekt-@skills-dir-Plugin und extraKnownMarketplaces-Einträgen aus dem Repository oder einem --add-dir-Verzeichnis Nicht verwendet, und es wird kein Dialog angeboten Nicht verwendet
Inline-mcpServers im Frontmatter eines Subagents aus dem Repository oder einem --add-dir-Verzeichnis Nicht verwendet, und es wird kein Dialog angeboten Nicht verwendet
Server in .mcp.json, einschließlich derjenigen, die das Repository in seinen eigenen Einstellungen genehmigt Claude Code fragt Sie, bevor er sich mit ihnen verbindet. Die eigenen Genehmigungen des Repositorys zählen nicht Verbunden ohne zu fragen, genehmigt oder nicht. Das SDK lädt sie nur, wenn settingSources Projekteinstellungen enthält. claude mcp list im selben Ordner meldet einen solchen Server immer noch als ausstehend
Ein headersHelper auf einem Server in .mcp.json Nicht ausgeführt, bis Sie den Vertrauensdialog akzeptieren, der erneut anzeigt, wo der Helper deklariert ist. Claude Code verbindet den Server nur mit seinen statischen headers, bis dahin Nicht ausgeführt. Claude Code verbindet den Server mit seinen statischen headers und gibt eine headersHelper not run-Zeile pro Server auf stderr aus

Für die Zeilen, die diesen genauen Ordner vertraut benötigen, vertrauen Sie ihm manuell: Setzen Sie projects["<path>"].hasTrustDialogAccepted auf true in ~/.claude.json, wobei <path> die Repository-Root oder der Ordner selbst außerhalb eines Repositorys ist. Claude Code gibt den genauen Schlüssel in der Debug-Log-Zeile für einen übersprungenen Subagent-Hook oder Inline-MCP-Server, in der stderr-Warnung für übersprungene Allow-Regeln und in der headersHelper not run-Zeile für einen übersprungenen Helper aus.

Bevor Sie claude -p in einem Repository ausführen, das Sie nicht geschrieben haben, entscheiden Sie, was es auf Ihrem Computer ausführen kann:

  • Übergeben Sie --setting-sources user oder setzen Sie die settingSources des SDK ohne Projekteinstellungen, damit Claude Code weder die Einstellungsdateien des Projekts noch seine .mcp.json liest
  • Starten Sie mit --bare, damit Claude Code keine Hooks, Skills, benutzerdefinierten Befehle, Subagents, Plugins oder .mcp.json-Server aus dem Projekt liest. Der env-Block des Projekts und Helfer wie awsAuthRefresh in seinen Einstellungsdateien gelten immer noch, und Claude Code liest apiKeyHelper nur aus --settings
  • Übergeben Sie --settings '{"disableAllHooks": true}', um Hooks auszuschalten für diesen Lauf. Es nur in Ihren Benutzereinstellungen zu setzen, reicht nicht aus, da die Projekteinstellungen des Repositorys Vorrang vor Ihren haben und es auf false zurücksetzen können
  • Fügen Sie einen disabledMcpjsonServers-Eintrag hinzu, um einen .mcp.json-Server nach Name in jedem Sitzungstyp abzulehnen

Beispielkonfigurationen

Dieses Repository enthält Starter-Einstellungskonfigurationen für häufige Bereitstellungsszenarien. Verwenden Sie diese als Ausgangspunkte und passen Sie sie an Ihre Anforderungen an.

Siehe auch

  • Alle Einstellungen: jeden Einstellungsschlüssel, einschließlich der Berechtigungsschlüssel
  • Auto-Mode konfigurieren: teilen Sie dem Auto-Mode-Klassifizierer mit, welche Infrastruktur Ihre Organisation vertraut
  • Sandboxing: Dateisystem- und Netzwerkisolation auf Betriebssystemebene für Bash-Befehle
  • Authentifizierung: richten Sie Benutzerzugriff auf Claude Code ein
  • Sicherheit: Sicherheitsvorkehrungen und Best Practices
  • Hooks: automatisieren Sie Workflows und erweitern Sie die Berechtigungsevaluierung