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. Berechtigungseinstellungen können in die Versionskontrolle eingecheckt und an alle Entwickler in Ihrer Organisation verteilt werden, sowie von einzelnen Entwicklern angepasst werden.

Berechtigungssystem

Claude Code verwendet ein gestuftes Berechtigungssystem, um Leistung und Sicherheit auszugleichen:

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.

• 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, daher kann eine deny-Regel keine Allowlist-Ausnahmen enthalten. 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. Eine eingegrenzte Regel wie Bash(rm *) lässt das Werkzeug verfügbar und blockiert übereinstimmende Aufrufe, wenn Claude sie versucht.

Berechtigungsmodi

Claude Code unterstützt mehrere Berechtigungsmodi, die steuern, wie Werkzeuge genehmigt werden. Siehe Berechtigungsmodi für den Zeitpunkt der Verwendung jedes Modus. Legen Sie den defaultMode in Ihren Einstellungsdateien fest:

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

Berechtigungsregelsyntax

Berechtigungsregeln folgen dem Format Tool oder Tool(specifier).

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 Werkzeug mit Tool(param:value) abgleichen. Die Regel passt, wenn Claude das Werkzeug mit diesem Parameter aufruft, der auf diesen genauen Wert gesetzt ist. Diese Syntax ist für Ablehnungs- und Anfrage-Regeln; 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

Felder, die ein Werkzeug bereits mit seinen eigenen kanonisierenden Regeln abgleicht, können auf diese Weise nicht abgeglichen werden: 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

Bash-Regeln unterstützen Glob-Muster mit *. Platzhalter können an jeder Position im Befehl erscheinen. Diese Konfiguration ermöglicht npm- und git-Commit-Befehle, blockiert aber git push:

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

Das Leerzeichen vor * ist wichtig: Bash(ls *) gleicht ls -la ab, aber nicht lsof, während Bash(ls*) beide abgleicht. 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. 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.

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 nur den kanonischen Namen 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 unterstützen Wildcard-Abgleich mit *. Platzhalter können an jeder Position im Befehl erscheinen, einschließlich am Anfang, in der Mitte oder am Ende:

• Bash(npm run build) gleicht den genauen Bash-Befehl npm run build ab
• Bash(npm run test *) gleicht Bash-Befehle ab, die mit npm run test beginnen
• Bash(npm *) gleicht jeden Befehl ab, der mit npm beginnt
• Bash(* install) gleicht jeden Befehl ab, der mit install endet
• Bash(git * main) gleicht Befehle wie git checkout main und git log --oneline main ab

Ein einzelnes * gleicht jede Zeichenfolge ab, einschließlich Leerzeichen, daher kann ein Platzhalter mehrere Argumente umfassen. Bash(git *) gleicht git log --oneline --all ab, und Bash(git * main) gleicht sowohl git push origin main als auch git merge main ab.

Wenn * am Ende mit einem Leerzeichen davor erscheint (wie Bash(ls *)), wird eine Wortgrenze erzwungen, die erfordert, dass dem Präfix ein Leerzeichen oder das Ende der Zeichenkette folgt. Zum Beispiel gleicht Bash(ls *) ls -la ab, aber nicht lsof. Im Gegensatz dazu gleicht Bash(ls*) ohne Leerzeichen sowohl ls -la als auch lsof ab, da es keine Wortgrenzbeschränkung gibt.

Zusammengesetzte Befehle

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.

Prozess-Wrapper

Vor dem Abgleich von Bash-Regeln entfernt Claude Code einen festen Satz von Prozess-Wrappern, daher gleicht eine Regel wie Bash(npm test *) auch timeout 30 npm test ab. Die erkannten Wrapper sind timeout, time, nice, nohup und stdbuf.

Auch bloßes xargs wird 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 fordern immer auf und können nicht durch eine Präfixregel wie Bash(watch *) automatisch genehmigt werden. 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.

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. Diese umfassen 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.

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. Befehle mit schreibfähigen oder ausführungsfähigen Flags, wie find, sort, sed und git, fordern immer noch auf, wenn ein unquotiertes Glob vorhanden ist, da das Glob zu einem Flag wie -delete expandieren könnte.

Ein cd in einen Pfad innerhalb Ihres Arbeitsverzeichnisses oder eines zusätzlichen Verzeichnisses ist auch schreibgeschützt. Ein zusammengesetzter Befehl wie cd packages/api && ls läuft ohne Aufforderung, wenn jeder Teil auf eigene Faust qualifiziert. Das Kombinieren von cd mit git in einem zusammengesetzten Befehl fordert immer auf, unabhängig vom Zielverzeichnis.

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

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.

Read- und Edit-Regeln folgen beide der gitignore-Spezifikation mit vier unterschiedlichen Mustertypen:

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 <project>/docs/ (NICHT /docs/ und NICHT <project>/.claude/docs/)
• Read(~/.zshrc): liest die .zshrc Ihres Home-Verzeichnisses
• Edit(//tmp/scratch.txt): bearbeitet den absoluten Pfad /tmp/scratch.txt
• Read(src/**): liest aus <current-directory>/src/

Eine Regel gleicht nur Dateien unter ihrem Anker ab, daher bestimmt der Anker, wie weit eine Deny-Regel reicht. Bare Dateinamen folgen gitignore-Semantik und gleichen in jeder Tiefe ab, daher sind Read(.env) und Read(**/.env) gleichwertig:

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.

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 und ist gleichwertig mit einer bloßen WebFetch-Regel

An jeder Position außer einem führenden *. oder einem bloßen * gleicht der Platzhalter 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 müsste und einen Punkt überschreiten würde. Dies verhindert, dass ein nachgestellter Platzhalter Domänen abgleicht, die ein Angreifer registrieren könnte.

MCP

• mcp__puppeteer gleicht jedes Werkzeug ab, das vom puppeteer-Server bereitgestellt wird (Name in Claude Code konfiguriert)
• mcp__puppeteer__* Wildcard-Syntax, die auch alle Werkzeuge vom puppeteer-Server abgleicht
• mcp__puppeteer__puppeteer_navigate gleicht das puppeteer_navigate-Werkzeug ab, das vom puppeteer-Server bereitgestellt wird

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 bloße 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 bieten eine Möglichkeit, benutzerdefinierte Shell-Befehle zu registrieren, um die Berechtigungsevaluierung zur Laufzeit durchzuführen. Wenn Claude Code einen Werkzeugaufruf tätigt, werden PreToolUse-Hooks vor dem Berechtigungssystem ausgeführt. Die Hook-Ausgabe kann den Werkzeugaufruf verweigern, eine Aufforderung erzwingen oder die Aufforderung überspringen, um den Aufruf fortzufahren.

Hook-Entscheidungen umgehen keine Berechtigungsregeln. Deny- und Ask-Regeln werden unabhängig davon ausgewertet, was ein PreToolUse-Hook zurückgibt, daher blockiert eine übereinstimmende Deny-Regel 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.

Ein blockierender Hook hat auch Vorrang vor Allow-Regeln. Ein Hook, der mit Code 2 beendet wird, stoppt den Werkzeugaufruf, bevor Berechtigungsregeln ausgewertet 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 es gestartet wurde. 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.

Um das primäre Arbeitsverzeichnis der Sitzung zu ändern, anstatt ein weiteres hinzuzufügen, verwenden Sie /cd. Der Befehl /cd erfordert Claude Code v2.1.169 oder später. Im Gegensatz zu /add-dir verlagert er die Sitzung: Die CLAUDE.md des neuen Verzeichnisses wird geladen und --resume findet die Sitzung von dort aus.

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. Verzeichnisse, die in permissions.additionalDirectories in einer Einstellungsdatei aufgelistet sind, gewähren nur Dateizugriff und laden keine der folgenden Konfigurationen.

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

Befehle und Ausgabestile werden aus dem aktuellen Arbeitsverzeichnis und seinen übergeordneten Verzeichnissen, Ihrem Benutzerverzeichnis unter ~/.claude/ und verwalteten Einstellungen erkannt. Hooks und andere 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. 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 alle Werkzeuge (Bash, Read, Edit, WebFetch, MCP und andere).
• Sandboxing bietet OS-Ebenen-Durchsetzung, die den Zugriff des Bash-Werkzeugs auf das Dateisystem und das Netzwerk einschränkt. Es gilt nur für Bash-Befehle und ihre untergeordneten Prozesse.

Verwenden Sie beide für Defense-in-Depth:

• Berechtigungs-Deny-Regeln blockieren Claude daran, überhaupt zu versuchen, auf eingeschränkte Ressourcen zuzugreifen
• Sandbox-Einschränkungen verhindern, dass Bash-Befehle Ressourcen außerhalb definierter Grenzen erreichen, selbst wenn eine Prompt-Injection Claude's Entscheidungsfindung umgeht
• Dateisystem-Einschränkungen in der Sandbox kombinieren die sandbox.filesystem-Einstellungen mit Read- und Edit-Deny-Regeln; beide werden in die endgültige Sandbox-Grenze zusammengeführt
• Netzwerk-Einschränkungen kombinieren WebFetch-Berechtigungsregeln mit den allowedDomains- und deniedDomains-Listen der Sandbox

Wenn Sandboxing mit autoAllowBashIfSandboxed: true aktiviert ist, was die Standardeinstellung ist, 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. Inhaltsgebundene Ask-Regeln wie Bash(git push *) erzwingen weiterhin eine Aufforderung, explizite Deny-Regeln gelten weiterhin, und rm- oder rmdir-Befehle, die auf /, Ihr Home-Verzeichnis oder andere kritische Systempfade abzielen, lösen weiterhin eine Aufforderung aus. 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 über die Claude Code-Konfiguration benötigen, können Administratoren verwaltete Einstellungen bereitstellen, die nicht von Benutzer- oder Projekteinstellungen überschrieben werden können. Diese Richtlinieneinstellungen folgen dem gleichen Format wie reguläre Einstellungsdateien und können über MDM/OS-Ebenen-Richtlinien, verwaltete Einstellungsdateien oder servergesteuerte Einstellungen bereitgestellt werden. Siehe Einstellungsdateien für Bereitstellungsmechanismen und Dateispeicherorte.

Nur verwaltete Einstellungen

Die folgenden Einstellungen sind nur in verwalteten Einstellungen wirksam. Das Platzieren in Benutzer- oder Projekteinstellungsdateien hat keine Auswirkung.

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:

1. Verwaltete Einstellungen: können von keiner anderen Ebene überschrieben werden, einschließlich Befehlszeilenargumenten
2. Befehlszeilenargumente: temporäre Sitzungsüberschreibungen
3. Lokale Projekteinstellungen (.claude/settings.local.json)
4. Gemeinsame Projekteinstellungen (.claude/settings.json)
5. Benutzereinstellungen (~/.claude/settings.json)

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.

Embedding-Hosts können zusätzliche verwaltete Richtlinien über die SDK-Option managedSettings bereitstellen, wenn parentSettingsBehavior auf "merge" gesetzt ist; Embedder-Werte können die Richtlinie verschärfen, aber nicht lockern.

Wenn beispielsweise 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.

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

• Einstellungen: vollständige Konfigurationsreferenz einschließlich der Berechtigungseinstellungstabelle
• Konfigurieren Sie den Auto-Mode: Teilen Sie dem Auto-Mode-Klassifizierer mit, welche Infrastruktur Ihre Organisation vertraut
• Sandboxing: OS-Ebenen-Dateisystem- und Netzwerkisolation 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