Berechtigungen konfigurieren - Claude Code Docs

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:

Werkzeugtyp	Beispiel	Genehmigung erforderlich	Verhalten „Ja, nicht mehr fragen”
Nur Lesen	Dateilesevorgänge, Grep	Nein	N/A
Bash-Befehle	Shell-Ausführung	Ja	Dauerhaft pro Projektverzeichnis und Befehl
Dateiänderung	Dateien bearbeiten/schreiben	Ja	Bis zum Ende der Sitzung

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 -> ask -> allow. Die erste übereinstimmende Regel gewinnt, daher haben Deny-Regeln immer Vorrang.

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:

Modus	Beschreibung
`default`	Standardverhalten: fordert Genehmigung bei der ersten Verwendung jedes Werkzeugs auf
`acceptEdits`	Akzeptiert automatisch Dateiberechtigungen für die Sitzung
`plan`	Plan Mode: Claude kann Dateien analysieren, aber nicht ändern oder Befehle ausführen
`auto`	Genehmigt Werkzeugaufrufe automatisch mit Hintergrund-Sicherheitsprüfungen, die überprüfen, ob Aktionen mit Ihrer Anfrage übereinstimmen. Derzeit eine Forschungsvorschau
`dontAsk`	Verweigert Werkzeuge automatisch, es sei denn, sie sind vorab über `/permissions` oder `permissions.allow`-Regeln genehmigt
`bypassPermissions`	Überspringt Berechtigungsaufforderungen außer für Schreibvorgänge in geschützte Verzeichnisse (siehe Warnung unten)

Der Modus bypassPermissions überspringt Berechtigungsaufforderungen. Schreibvorgänge in die Verzeichnisse .git, .claude, .vscode und .idea fordern weiterhin eine Bestätigung auf, um eine versehentliche Beschädigung des Repository-Status und der lokalen Konfiguration zu verhindern. Schreibvorgänge in .claude/commands, .claude/agents und .claude/skills sind ausgenommen und fordern nicht auf, da Claude routinemäßig dort schreibt, wenn Skills, Subagents und Befehle erstellt werden. Verwenden Sie diesen Modus nur in isolierten Umgebungen wie Containern oder VMs, in denen Claude Code keinen Schaden anrichten kann. Administratoren können diesen Modus verhindern, indem sie disableBypassPermissionsMode in verwalteten Einstellungen auf "disable" setzen.

Um zu verhindern, dass der Modus bypassPermissions oder auto verwendet wird, setzen Sie permissions.disableBypassPermissionsMode oder 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:

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.

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

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. Die veraltete :*-Suffixsyntax ist gleichwertig mit *, wird aber nicht mehr empfohlen.

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

Claude Code ist sich Shell-Operatoren (wie &&) bewusst, daher gibt eine Präfixabgleichregel wie Bash(safe-cmd *) ihm nicht die Berechtigung, den Befehl safe-cmd && other-cmd auszuführen.

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.

Bash-Berechtigungsmuster, die versuchen, Befehlsargumente einzuschränken, sind fragil. Zum Beispiel beabsichtigt Bash(curl http://github.com/ *), curl auf GitHub-URLs zu beschränken, wird aber Variationen nicht abgleichen wie:

Optionen vor URL: curl -X GET http://github.com/...
Anderes Protokoll: curl https://github.com/...
Umleitungen: curl -L http://bit.ly/xyz (leitet zu github um)
Variablen: URL=http://github.com && curl $URL
Zusätzliche Leerzeichen: curl http://github.com

Für zuverlässigere URL-Filterung sollten Sie erwägen:

Bash-Netzwerkwerkzeuge einschränken: Verwenden Sie Deny-Regeln, um curl, wget und ähnliche Befehle zu blockieren, verwenden Sie dann das WebFetch-Werkzeug mit WebFetch(domain:github.com)-Berechtigung für zulässige Domänen
PreToolUse-Hooks verwenden: Implementieren Sie einen Hook, der URLs in Bash-Befehlen validiert und nicht zulässige Domänen blockiert
Claude Code über Ihre zulässigen curl-Muster über CLAUDE.md informieren

Beachten Sie, dass die alleinige Verwendung von WebFetch keinen Netzwerkzugriff verhindert. Wenn Bash zulässig ist, kann Claude immer noch curl, wget oder andere Werkzeuge verwenden, um auf jede URL zuzugreifen.

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.

Read- und Edit-Deny-Regeln gelten für Claude’s integrierte Dateiwerkzeuge, nicht für Bash-Unterprozesse. Eine Read(./.env)-Deny-Regel blockiert das Read-Werkzeug, verhindert aber nicht cat .env in Bash. Für OS-Ebenen-Durchsetzung, die alle Prozesse daran hindert, auf einen Pfad zuzugreifen, aktivieren Sie die Sandbox.

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

Muster	Bedeutung	Beispiel	Gleicht ab
`//path`	Absoluter Pfad vom Dateisystem-Root	`Read(//Users/alice/secrets/**)`	`/Users/alice/secrets/**`
`~/path`	Pfad vom Home-Verzeichnis	`Read(~/Documents/*.pdf)`	`/Users/alice/Documents/*.pdf`
`/path`	Pfad relativ zum Projekt-Root	`Edit(/src/*/.ts)`	`<project root>/src/*/.ts`
`path` oder `./path`	Pfad relativ zum aktuellen Verzeichnis	`Read(*.env)`	`<cwd>/*.env`

Ein Muster wie /Users/alice/file ist KEIN absoluter Pfad. Es ist relativ zum Projekt-Root. Verwenden Sie //Users/alice/file für absolute Pfade.

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/

In gitignore-Mustern gleicht * Dateien in einem einzelnen Verzeichnis ab, während ** rekursiv über Verzeichnisse hinweg abgleicht. Um allen Dateizugriff zu ermöglichen, verwenden Sie einfach den Werkzeugnamen ohne Klammern: Read, Edit oder Write.

WebFetch

WebFetch(domain:example.com) gleicht Fetch-Anfragen an example.com ab

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)"]
  }
}

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. Das Überspringen der Aufforderung umgeht keine Berechtigungsregeln. Deny- und Ask-Regeln werden immer noch ausgewertet, nachdem ein Hook "allow" zurückgibt, daher blockiert eine übereinstimmende Deny-Regel immer noch den Aufruf. 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.

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 verwenden Read- und Edit-Deny-Regeln, nicht separate Sandbox-Konfiguration
Netzwerk-Einschränkungen kombinieren WebFetch-Berechtigungsregeln mit der allowedDomains-Liste der Sandbox

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

Einige Einstellungen sind nur in verwalteten Einstellungen wirksam:

Einstellung	Beschreibung
`allowManagedPermissionRulesOnly`	Wenn `true`, verhindert, dass Benutzer- und Projekteinstellungen `allow`-, `ask`- oder `deny`-Berechtigungsregeln definieren. Nur Regeln in verwalteten Einstellungen gelten
`allowManagedHooksOnly`	Wenn `true`, verhindert das Laden von Benutzer-, Projekt- und Plugin-Hooks. Nur verwaltete Hooks und SDK-Hooks sind zulässig
`allowManagedMcpServersOnly`	Wenn `true`, werden nur `allowedMcpServers` aus verwalteten Einstellungen berücksichtigt. `deniedMcpServers` wird immer noch aus allen Quellen zusammengeführt. Siehe Verwaltete MCP-Konfiguration
`blockedMarketplaces`	Blocklist von Marketplace-Quellen. Blockierte Quellen werden vor dem Download überprüft, sodass sie das Dateisystem nie berühren. Siehe verwaltete Marketplace-Einschränkungen
`sandbox.network.allowManagedDomainsOnly`	Wenn `true`, werden nur `allowedDomains` und `WebFetch(domain:...)`-Allow-Regeln aus verwalteten Einstellungen berücksichtigt. Nicht zulässige Domänen werden automatisch blockiert, ohne den Benutzer zu fragen. Verweigerte Domänen werden immer noch aus allen Quellen zusammengeführt
`sandbox.filesystem.allowManagedReadPathsOnly`	Wenn `true`, werden nur `allowRead`-Pfade aus verwalteten Einstellungen berücksichtigt. `allowRead`-Einträge aus Benutzer-, Projekt- und lokalen Einstellungen werden ignoriert
`strictKnownMarketplaces`	Steuert, welche Plugin-Marketplaces Benutzer hinzufügen können. Siehe verwaltete Marketplace-Einschränkungen

Der Zugriff auf Remote Control und Web-Sitzungen wird nicht durch einen Schlüssel für verwaltete Einstellungen gesteuert. Bei Team- und Enterprise-Plänen aktiviert oder deaktiviert ein Administrator diese Funktionen in Claude Code-Administratoreinstellungen.

Konfigurieren Sie den Auto-Mode-Klassifizierer

Auto Mode verwendet ein Klassifizierermodell, um zu entscheiden, ob jede Aktion sicher ausgeführt werden kann, ohne zu fragen. Standardmäßig vertraut es nur dem Arbeitsverzeichnis und, falls vorhanden, den Remotes des aktuellen Repos. Aktionen wie das Pushen zu Ihrer Unternehmens-Quellcode-Org oder das Schreiben in einen Team-Cloud-Bucket werden als potenzielle Datenexfiltration blockiert. Der autoMode-Einstellungsblock ermöglicht es Ihnen, dem Klassifizierer mitzuteilen, welche Infrastruktur Ihre Organisation vertraut. Der Klassifizierer liest autoMode aus Benutzereinstellungen, .claude/settings.local.json und verwalteten Einstellungen. Er liest nicht aus gemeinsamen Projekteinstellungen in .claude/settings.json, da ein eingechecktes Repo sonst seine eigenen Allow-Regeln injizieren könnte.

Bereich	Datei	Verwendung für
Ein Entwickler	`~/.claude/settings.json`	Persönliche vertrauenswürdige Infrastruktur
Ein Projekt, ein Entwickler	`.claude/settings.local.json`	Pro-Projekt vertrauenswürdige Buckets oder Services, gitignored
Organisationsweit	Verwaltete Einstellungen	Vertrauenswürdige Infrastruktur, die für alle Entwickler erzwungen wird

Einträge aus jedem Bereich werden kombiniert. Ein Entwickler kann environment, allow und soft_deny mit persönlichen Einträgen erweitern, kann aber Einträge, die verwaltete Einstellungen bereitstellen, nicht entfernen. Da Allow-Regeln als Ausnahmen zu Block-Regeln innerhalb des Klassifizierers fungieren, kann ein von einem Entwickler hinzugefügter allow-Eintrag einen Organisations-soft_deny-Eintrag überschreiben: Die Kombination ist additiv, nicht eine harte Richtliniengrenze. Wenn Sie eine Regel benötigen, die Entwickler nicht umgehen können, verwenden Sie stattdessen permissions.deny in verwalteten Einstellungen, was Aktionen blockiert, bevor der Klassifizierer konsultiert wird.

Definieren Sie vertrauenswürdige Infrastruktur

Für die meisten Organisationen ist autoMode.environment das einzige Feld, das Sie festlegen müssen. Es teilt dem Klassifizierer mit, welche Repos, Buckets und Domänen vertrauenswürdig sind, ohne die integrierten Block- und Allow-Regeln zu berühren. Der Klassifizierer verwendet environment, um zu entscheiden, was „extern” bedeutet: Jedes Ziel, das nicht aufgelistet ist, ist ein potenzielles Exfiltrationsziel.

{
  "autoMode": {
    "environment": [
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com",
      "Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
    ]
  }
}

Einträge sind Prosa, keine Regex oder Werkzeugmuster. Der Klassifizierer liest sie als natürlichsprachige Regeln. Schreiben Sie sie so, wie Sie Ihre Infrastruktur einem neuen Ingenieur beschreiben würden. Ein gründlicher Umgebungsabschnitt deckt ab:

Organisation: Ihr Unternehmensname und wofür Claude Code hauptsächlich verwendet wird, wie Softwareentwicklung, Infrastrukturautomatisierung oder Datentechnik
Quellkontrolle: jede GitHub-, GitLab- oder Bitbucket-Org, zu der Ihre Entwickler pushen
Cloud-Provider und vertrauenswürdige Buckets: Bucketnamen oder Präfixe, aus denen Claude lesen und in die Claude schreiben kann
Vertrauenswürdige interne Domänen: Hostnamen für APIs, Dashboards und Services in Ihrem Netzwerk, wie *.internal.example.com
Wichtige interne Services: CI, Artifact-Registries, interne Paketindizes, Incident-Tools
Zusätzlicher Kontext: Einschränkungen der regulierten Industrie, Multi-Tenant-Infrastruktur oder Compliance-Anforderungen, die beeinflussen, was der Klassifizierer als riskant behandeln sollte

Eine nützliche Startvorlage: Füllen Sie die eingeklammerten Felder aus und entfernen Sie alle Zeilen, die nicht zutreffen:

{
  "autoMode": {
    "environment": [
      "Organization: {COMPANY_NAME}. Primary use: {PRIMARY_USE_CASE, e.g. software development, infrastructure automation}",
      "Source control: {SOURCE_CONTROL, e.g. GitHub org github.example.com/acme-corp}",
      "Cloud provider(s): {CLOUD_PROVIDERS, e.g. AWS, GCP, Azure}",
      "Trusted cloud buckets: {TRUSTED_BUCKETS, e.g. s3://acme-builds, gs://acme-datasets}",
      "Trusted internal domains: {TRUSTED_DOMAINS, e.g. *.internal.example.com, api.example.com}",
      "Key internal services: {SERVICES, e.g. Jenkins at ci.example.com, Artifactory at artifacts.example.com}",
      "Additional context: {EXTRA, e.g. regulated industry, multi-tenant infrastructure, compliance requirements}"
    ]
  }
}

Je spezifischer der Kontext, den Sie geben, desto besser kann der Klassifizierer Routine-Internaloperationen von Exfiltrationversuchen unterscheiden. Sie müssen nicht alles auf einmal ausfüllen. Ein angemessener Rollout: Beginnen Sie mit den Standardeinstellungen und fügen Sie Ihre Quellkontroll-Org und wichtige interne Services hinzu, was die häufigsten falschen Positive wie das Pushen zu Ihren eigenen Repos behebt. Fügen Sie als nächstes vertrauenswürdige Domänen und Cloud-Buckets hinzu. Füllen Sie den Rest aus, wenn Blockierungen auftreten.

Überschreiben Sie die Block- und Allow-Regeln

Zwei zusätzliche Felder ermöglichen es Ihnen, die integrierten Regellisten des Klassifizierers zu ersetzen: autoMode.soft_deny steuert, was blockiert wird, und autoMode.allow steuert, welche Ausnahmen gelten. Jedes ist ein Array von Prosabeschreibungen, das als natürlichsprachige Regeln gelesen wird. Innerhalb des Klassifizierers ist die Priorität: soft_deny-Regeln blockieren zuerst, dann allow-Regeln überschreiben als Ausnahmen, dann explizite Benutzerabsicht überschreibt beide. Wenn die Nachricht des Benutzers direkt und spezifisch die genaue Aktion beschreibt, die Claude ausführen wird, lässt der Klassifizierer sie zu, selbst wenn eine soft_deny-Regel passt. Allgemeine Anfragen zählen nicht: Claude zu bitten, das Repo zu „bereinigen”, autorisiert kein Force-Push, aber Claude zu bitten, „diesen Branch zu force-pushen”, tut es. Um zu lockern: Entfernen Sie Regeln aus soft_deny, wenn die Standardeinstellungen etwas blockieren, das Ihre Pipeline bereits mit PR-Review, CI oder Staging-Umgebungen schützt, oder fügen Sie zu allow hinzu, wenn der Klassifizierer wiederholt ein Routinemuster kennzeichnet, das die Standard-Ausnahmen nicht abdecken. Um zu verschärfen: Fügen Sie zu soft_deny für Risiken hinzu, die für Ihre Umgebung spezifisch sind und die Standardeinstellungen vermissen, oder entfernen Sie aus allow, um eine Standard-Ausnahme zu den Block-Regeln zu halten. Führen Sie in allen Fällen claude auto-mode defaults aus, um die vollständigen Standard-Listen zu erhalten, kopieren Sie sie dann und bearbeiten Sie sie: Beginnen Sie niemals mit einer leeren Liste.

{
  "autoMode": {
    "environment": [
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly",
      "Writing to s3://acme-scratch/ is allowed: ephemeral bucket with a 7-day lifecycle policy"
    ],
    "soft_deny": [
      "Never run database migrations outside the migrations CLI, even against dev databases",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow",
      "...copy full default soft_deny list here first, then add your rules..."
    ]
  }
}

Das Festlegen von allow oder soft_deny ersetzt die gesamte Standard-Liste für diesen Abschnitt. Wenn Sie soft_deny mit einem einzelnen Eintrag festlegen, wird jede integrierte Block-Regel verworfen: Force Push, Datenexfiltration, curl | bash, Production-Deploys und alle anderen Standard-Block-Regeln werden zulässig. Um sicher anzupassen, führen Sie claude auto-mode defaults aus, um die integrierten Regeln zu drucken, kopieren Sie sie in Ihre Einstellungsdatei, überprüfen Sie dann jede Regel gegen Ihre eigene Pipeline und Risikotoleranz. Entfernen Sie nur Regeln für Risiken, die Ihre Infrastruktur bereits mindert.

Die drei Abschnitte werden unabhängig ausgewertet, daher lässt das Festlegen von environment allein die Standard-allow- und soft_deny-Listen intakt.

Überprüfen Sie die Standardeinstellungen und Ihre effektive Konfiguration

Da das Festlegen von allow oder soft_deny die Standardeinstellungen ersetzt, beginnen Sie jede Anpassung, indem Sie die vollständigen Standard-Listen kopieren. Drei CLI-Unterbefehle helfen Ihnen, zu überprüfen und zu validieren:

claude auto-mode defaults  # the built-in environment, allow, and soft_deny rules
claude auto-mode config    # what the classifier actually uses: your settings where set, defaults otherwise
claude auto-mode critique  # get AI feedback on your custom allow and soft_deny rules

Speichern Sie die Ausgabe von claude auto-mode defaults in einer Datei, bearbeiten Sie die Listen, um Ihre Richtlinie zu entsprechen, und fügen Sie das Ergebnis in Ihre Einstellungsdatei ein. Nach dem Speichern führen Sie claude auto-mode config aus, um zu bestätigen, dass die effektiven Regeln das sind, was Sie erwarten. Wenn Sie benutzerdefinierte Regeln geschrieben haben, überprüft claude auto-mode critique sie und kennzeichnet Einträge, die mehrdeutig, redundant oder wahrscheinlich zu falschen Positiven führen.

Einstellungspriorität

Berechtigungsregeln folgen der gleichen Einstellungspriorität wie alle anderen Claude Code-Einstellungen:

Verwaltete Einstellungen: können von keiner anderen Ebene überschrieben werden, einschließlich Befehlszeilenargumenten
Befehlszeilenargumente: temporäre Sitzungsüberschreibungen
Lokale Projekteinstellungen (.claude/settings.local.json)
Gemeinsame Projekteinstellungen (.claude/settings.json)
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. Wenn eine Berechtigung in Benutzereinstellungen zulässig ist, aber in Projekteinstellungen verweigert wird, hat die Projekteinstellung Vorrang und die Berechtigung wird blockiert.

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

Konfiguration

​Berechtigungssystem

​Berechtigungen verwalten

​Berechtigungsmodi

​Berechtigungsregelsyntax

​Alle Verwendungen eines Werkzeugs abgleichen

​Verwenden Sie Spezifizierer für granulare Kontrolle

​Wildcard-Muster

​Werkzeugspezifische Berechtigungsregeln

​Bash

​Read und Edit

​WebFetch

​MCP

​Agent (Subagents)

​Berechtigungen mit Hooks erweitern

​Arbeitsverzeichnisse

​Wie Berechtigungen mit Sandboxing interagieren

​Verwaltete Einstellungen

​Nur verwaltete Einstellungen

​Konfigurieren Sie den Auto-Mode-Klassifizierer

​Definieren Sie vertrauenswürdige Infrastruktur

​Überschreiben Sie die Block- und Allow-Regeln

​Überprüfen Sie die Standardeinstellungen und Ihre effektive Konfiguration

​Einstellungspriorität

​Beispielkonfigurationen

​Siehe auch

Berechtigungssystem

Berechtigungen verwalten

Berechtigungsmodi

Berechtigungsregelsyntax

Alle Verwendungen eines Werkzeugs abgleichen

Verwenden Sie Spezifizierer für granulare Kontrolle

Wildcard-Muster

Werkzeugspezifische Berechtigungsregeln

Bash

Read und Edit

WebFetch

MCP

Agent (Subagents)

Berechtigungen mit Hooks erweitern

Arbeitsverzeichnisse

Wie Berechtigungen mit Sandboxing interagieren

Verwaltete Einstellungen

Nur verwaltete Einstellungen

Konfigurieren Sie den Auto-Mode-Klassifizierer

Definieren Sie vertrauenswürdige Infrastruktur

Überschreiben Sie die Block- und Allow-Regeln

Überprüfen Sie die Standardeinstellungen und Ihre effektive Konfiguration

Einstellungspriorität

Beispielkonfigurationen

Siehe auch