Auto-Modus konfigurieren

Teilen Sie dem Auto-Modus-Klassifizierer mit, welche Repos, Buckets und Domains Ihre Organisation vertraut. Legen Sie den Umgebungskontext fest, überschreiben Sie die Standard-Block- und Allow-Regeln, und überprüfen Sie Ihre effektive Konfiguration mit den Auto-Modus-CLI-Unterbefehlen.

Auto-Modus ermöglicht es Claude Code, ohne routinemäßige Berechtigungsaufforderungen zu laufen, indem Werkzeugaufrufe durch einen Klassifizierer geleitet werden, der alles blockiert, das irreversibel, destruktiv oder außerhalb Ihrer Umgebung ausgerichtet ist. Deny- und explizite Ask-Regeln werden vor dem Klassifizierer ausgewertet und blockieren oder fordern weiterhin auf. Verwenden Sie den autoMode-Einstellungsblock, um diesem Klassifizierer mitzuteilen, welche Repos, Buckets und Domains Ihre Organisation vertraut, damit er routinemäßige interne Operationen nicht mehr blockiert.

[!NOTE]

Diese Seite ist die Konfigurationsreferenz. Das Aktivieren und Deaktivieren des Auto-Modus wird auf der Seite „Berechtigungsmodi“ behandelt:

• Wechseln Sie während einer Sitzung zum Auto-Modus oder kehren Sie aus ihm zurück: siehe Berechtigungsmodi wechseln
• Starten Sie eine Sitzung im Auto-Modus: siehe In einem anderen Berechtigungsmodus starten

Auto-Modus ist für alle Benutzer auf jedem Anbieter verfügbar, einschließlich der Anthropic API, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry und angemeldeter Claude apps gateway-Sitzungen. Wenn Claude Code Auto-Modus als nicht verfügbar für Ihr Konto meldet, überprüfen Sie die vollständigen Anforderungen, die auch die unterstützten Modelle und die Kontrolle auf Organisationsebene in Team- und Enterprise-Plänen abdecken.

Standardmäßig vertraut der Klassifizierer nur dem Arbeitsverzeichnis und den konfigurierten Remotes des aktuellen Repos. Aktionen wie das Pushen zu Ihrer Unternehmens-Quellcode-Org oder das Schreiben in einen Team-Cloud-Bucket werden blockiert, bis Sie sie zu autoMode.environment hinzufügen.

Diese Seite behandelt, wie Sie:

• Einen menschlichen Checkpoint für Pushes und Pull Requests mit permissions.ask hinzufügen
• Definieren Sie vertrauenswürdige Infrastruktur mit autoMode.environment
• Generieren Sie Umgebungseinträge mit /auto-mode-setup
• Überprüfen Sie Ablehnungen, damit Sie wissen, was Sie als Nächstes hinzufügen müssen

Häufige Grenzen

Der Auto-Modus ermöglicht standardmäßig Pushes zu jedem Zweig des Repositorys, in dem Sie arbeiten, einschließlich des Standard-Zweigs, und die Erstellung von Pull Requests. Ein Nicht-Standard-Zweig, dessen Name ihn als Deploy- oder Veröffentlichungsziel kennzeichnet, wie production, release oder gh-pages, wird von diesem Standard nicht abgedeckt: Der Klassifizierer beurteilt einen Push dorthin nach seinen eigenen Bedingungen, einschließlich als Production-Deploy. Der Inhalt des Push wird ebenfalls noch überprüft, sodass ein Force Push, ein Geheimnis, das in den Commit eintritt, oder eine Änderung, die Geheimnisse außerhalb des Repositorys senden würde, wenn CI oder eine Deploy-Pipeline es ausführt, blockiert bleibt.

Wenn Sie vor jedem Push und Pull Request einen menschlichen Checkpoint wünschen, fügen Sie Berechtigungsregeln hinzu: Die Rezepte unten halten den Auto-Modus für alles andere aktiviert.

Einen menschlichen Checkpoint hinzufügen

Der direkteste Mechanismus ist permissions.ask. Inhaltsgebundene Ask-Regeln wie die folgenden werden vor dem Klassifizierer ausgewertet und erzwingen immer eine Berechtigungsaufforderung, auch im Auto-Modus, da eine explizite Ask-Regel Ihre ausdrückliche Absicht ist, für diese Aktion aufgefordert zu werden. Fügen Sie die Regeln in Ihren Einstellungen hinzu:

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

Diese Regeln entsprechen Befehlen, die mit git push oder gh pr create beginnen. Ein Push, den Claude auf andere Weise schreibt, wie git -C <dir> push oder git -c <key>=<value> push, entspricht der Regel nicht, daher wird er nicht kontrolliert. Für einen Checkpoint, der den vollständigen Befehlstext überprüft, fügen Sie einen PreToolUse Hook hinzu.

Wählen Sie den Mechanismus, der der Festigkeit der erforderlichen Grenze entspricht:

Wo der Klassifizierer die Konfiguration liest

Der Klassifizierer liest denselben CLAUDE.md-Inhalt, den Claude selbst lädt, sodass eine Anweisung wie „niemals force push“ in der CLAUDE.md deines Projekts sowohl Claude als auch den Klassifizierer gleichzeitig steuert. Beginne dort mit Projektkonventionen und Verhaltensregeln.

Für Regeln, die projektübergreifend gelten, wie vertrauenswürdige Infrastruktur oder organisationsweite Ablehnungsregeln, verwende den autoMode-Einstellungsblock. Der Klassifizierer liest autoMode aus den folgenden Bereichen:

Der Klassifizierer liest autoMode nicht aus Projekteinstellungen in .claude/settings.json oder .claude/settings.local.json. Beide Dateien befinden sich im Repository-Verzeichnis, sodass ein eingechecktes Repository oder ein Build-Schritt sonst seine eigenen Allow-Regeln injizieren könnte. Verschiebe alle autoMode-Blöcke in .claude/settings.local.json zu ~/.claude/settings.json.

Einträge aus jedem Bereich werden kombiniert. Ein Entwickler kann environment, allow, soft_deny und hard_deny mit persönlichen Einträgen erweitern, kann aber Einträge, die verwaltete Einstellungen bereitstellen, nicht entfernen. Da Allow-Regeln als Ausnahmen zu Soft-Block-Regeln innerhalb des Klassifizierers fungieren, kann ein von einem Entwickler hinzugefügter allow-Eintrag einen organisatorischen soft_deny-Eintrag überschreiben: Die Kombination ist additiv, keine harte Richtliniengrenze.

[!NOTE]

Der Klassifizierer ist ein zweites Gate, das nach dem Berechtigungssystem ausgeführt wird. Für Aktionen, die unabhängig von Benutzerabsicht oder Klassifizierer-Konfiguration niemals ausgeführt werden dürfen, verwende permissions.deny in verwalteten Einstellungen, das die Aktion blockiert, bevor der Klassifizierer konsultiert wird, und kann nicht überschrieben werden.

Vertrauenswürdige Infrastruktur definieren

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 Domains vertrauenswürdig sind: Der Klassifizierer nutzt dies, um zu entscheiden, was „extern“ bedeutet, sodass jedes Ziel, das nicht aufgelistet ist, ein potenzielles Exfiltrationsziel darstellt.

claude auto-mode defaults gibt drei Arten von Umgebungseinträgen aus.

• Kontextplätze: beschreiben Ihre Organisation, Ihren Stack und Ihre Sicherheitslage, damit der Klassifizierer die anderen Regeln in Ihrem Kontext liest. Jeder hat standardmäßig den Wert None configured oder die neben ihm genannte konservative Annahme:

  • Organisation

  • Primäre Verwendung von Claude Code: standardmäßig Softwareentwicklung

  • Cloud-Anbieter

  • Repository-Sichtbarkeit: Ein Repository wird als privat angenommen, es sei denn, sein Remote-Host und Name deuten darauf hin, dass es anders ist, oder der Klassifizierer liest eine Sichtbarkeitsprüfung früher im Gespräch, die zeigt, dass es öffentlich ist.

    In den Klassifizierer-Anfragen, die Claude Code selbst sendet, liest der Klassifizierer Ihre Nachrichten und die Befehle, die Claude ausführt, nicht deren Ausgabe. Der Beweis muss etwas sein, das der Klassifizierer lesen kann, wie Ihre eigene Nachricht, die das Repository als öffentlich benennt; die Ausgabe eines gh repo view allein erreicht ihn nicht.

  • Interne Freigabe / Snippet-Hosting: öffentliche Paste- und Gist-Services werden als außerhalb der Vertrauensgrenze behandelt, bis Sie einen benennen

  • Organisations-spezifische CLIs

  • Secrets-Management

  • CI/CD-Bereitstellungsziele

  • Netzwerk-Postur

  • Host-Containment: standardmäßig ein gewöhnlicher Entwickler-Rechner oder CI-Runner mit offenem Internet. Wenn Claude Code in einem Container, einer VM oder einem Pod mit einer Egress-Allow-Liste oder Nachbarn läuft, die es nicht berühren darf, benennen Sie die zulässigen Hosts, ob der Cloud-Metadaten-Endpunkt erreichbar sein sollte, und welches Cloud-Projekt, Cluster oder Registry die Aufgabe nutzt und unter welcher Identität. Bis dieser Eintrag diese Identität benennt, blockiert der Klassifizierer Anfragen für die eigenen Anmeldedaten des Hosts. Erfordert Claude Code v2.1.257 oder später

  • Geschützte Bereitstellungs-Namespaces / Umgebungen: fällt auf die Heuristik für sensible Remote-Ziele zurück, bis Sie diese benennen

  • Datenspeicherung / Deklassifizierung

• Vertrauensplätze: benennen, was der Klassifizierer als innerhalb Ihrer Grenze behandelt. Die Plätze sind Trusted repo, Source control, Trusted internal domains, Trusted cloud buckets, Key internal services und Internal package registry. Die Repo- und Source-Control-Einträge haben standardmäßig das funktionierende Repository und seine konfigurierten Remotes. Jeder andere Vertrauensplatz hat standardmäßig den Wert None configured, sodass nichts anderes vertrauenswürdig ist, bis Sie es hinzufügen. Die Sichtbarkeit eines Repositorys bezieht sich nur auf vertrauliches Material: Ein privates Repository ist ein akzeptables Ziel für vertrauliches Material, aber das Privatmachen eines Repositorys ermöglicht niemals das Verschieben von Secrets oder persönlichen oder anvertrauten Daten in dieses Repository, und der Klassifizierer behandelt Inhalte, die von außerhalb des funktionierenden Repositorys portiert, umgeleitet oder erstmals gelesen werden, als nicht das eigene Werk dieses Repositorys.
• Sensibilitätsplätze: benennen, was die Schutzregeln als hochriskant behandeln. Die Plätze sind Sensitive data locations & audiences, Sensitive remote targets und Protected IaC scopes. Jeder hat standardmäßig eine breite Heuristik, wie das Behandeln eines beliebigen Hosts oder Namespace, dessen Name prod oder production trägt, als sensibles Remote-Ziel, sodass die Schutzregeln aktiv sind, bevor Sie etwas konfigurieren. Das Benennen konkreter Ziele in einem Sensibilitätsplatz lässt diese Regeln stattdessen auf die benannten Ziele angewendet werden.

Um Ihre eigenen Einträge neben den Standardwerten hinzuzufügen, fügen Sie die wörtliche Zeichenkette "$defaults" in das Array ein. Die Standardeinträge werden an dieser Position eingefügt, sodass Ihre benutzerdefinierten Einträge vor oder nach ihnen stehen können.

Das folgende Beispiel behält die Standardeinträge bei und fügt die Repos, Buckets, Domains und Services einer Organisation hinzu.

{
  "autoMode": {
    "environment": [
      "$defaults",
      "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"
    ]
  }
}

Nachdem Sie Ihre Einstellungen gespeichert haben, führen Sie claude auto-mode config aus, um zu bestätigen, dass die geltenden Regeln Ihre Einträge enthalten.

Einträge sind Prosa, keine Regex oder Tool-Muster. 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
• Source Control: jede GitHub-, GitLab- oder Bitbucket-Organisation, in die Ihre Entwickler pushen
• Cloud-Anbieter und vertrauenswürdige Buckets: Bucketnamen oder Präfixe, aus denen und in die Claude lesen und schreiben können sollte
• Vertrauenswürdige interne Domains: Hostnamen für APIs, Dashboards und Services in Ihrem Netzwerk, wie *.internal.example.com
• Wichtige interne Services: CI, Artifact-Registries, interne Paketindizes, Incident-Tools
• Interne Paket-Registry: die private npm-, PyPI- oder andere Registry, durch die Installationen laufen sollten, sodass Installationen, die sie für eine öffentliche Registry umgehen, blockiert werden
• Sensible Datenspeicherorte & Zielgruppen: die Buckets, Datenbanken oder Pfade, die persönliche Daten, vertrauliche Geschäftsdaten, Anmeldedaten, regulierte Daten oder ähnlich sensibles Material enthalten, und die Zielgruppen, mit denen Daten an jedem Speicherort geteilt werden dürfen, sodass der Klassifizierer diese Speicherorte schützt, anstatt vom Inhalt zu raten.
• Sensible Remote-Ziele: die Namespaces, Hosts oder Container, die als Produktion zählen, sodass Remote-Shells und Port-Forwards in diese Ihre explizite Genehmigung benötigen
• Geschützte IaC-Bereiche: die Infrastruktur-Ressourcen, deren Apply oder Destroy immer erfordern sollte, dass Sie die Änderung benennen
• Zusätzlicher Kontext: Constraints für regulierte Industrien, 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": [
      "$defaults",
      "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}"
    ]
  }
}

Sie müssen nicht alles auf einmal ausfüllen. Ein angemessener Rollout: Beginnen Sie mit den Standardwerten und fügen Sie Ihre Source-Control-Organisation und wichtige interne Services hinzu, was die häufigsten falschen Positive wie das Pushen in Ihre eigenen Repos behebt. Fügen Sie als nächstes vertrauenswürdige Domains und Cloud-Buckets hinzu. Füllen Sie den Rest aus, wenn Blockierungen auftreten.

Umgebungseinträge mit /auto-mode-setup generieren

Führen Sie /auto-mode-setup aus, damit Claude Code anhand Ihres Projekts und Ihrer letzten Sitzungen darin Einträge für autoMode.environment und manchmal auch Regeleinträge entwirft. Wenn Sie den Entwurf annehmen, schreibt Claude Code ihn in ~/.claude/settings.json.

[!NOTE]

/auto-mode-setup ist in den Pro-, Max-, Ultra-, Team- und Enterprise-Plänen sowie mit einem Claude Console API-Schlüssel verfügbar. Mit einem Pro-, Max-, Ultra- oder Team-Plan benötigen Sie v2.1.228 oder höher bzw. v2.1.233 oder höher unter nativem Windows. Mit einem Enterprise-Plan oder einem Claude Console API-Schlüssel benötigen Sie v2.1.283 oder höher. Wenn der Befehl in Ihrer Sitzung fehlt, lesen Sie /auto-mode-setup gibt „Unknown command“ zurück.

Was /auto-mode-setup liest

Wenn ~/.claude/settings.json bereits autoMode-Einträge enthält, fragt Claude Code zunächst, ob Ihre Umgebungsliste ergänzt oder ersetzt werden soll, und behält die von Ihnen geschriebenen Regeln in jedem Fall bei. Anschließend fragt Claude Code, wie Sie dieses Projekt nutzen, und bietet zwei optionale Scans an, bevor überhaupt etwas gescannt wird. Beim Scan liest Claude Code immer diese Quellen:

• Die Dateien CLAUDE.md und README.md, Konfigurationsdateien und Git-Remotes dieses Projekts
• Ihre Einstellungen autoMode und permissions.allow
• Die Hosts, Buckets und Befehlsnamen aus den Befehlen, die Claude in Ihren letzten Sitzungen in diesem Projekt ausgeführt hat, niemals Ihre Nachrichten

Die beiden optionalen Scans fügen jeweils eine Quelle hinzu:

• Das erste Wort jedes Befehls in Ihrem Shell-Verlauf
• Die Remote-Hosts und Namen der Repositorys unter Ihrem Home-Verzeichnis

Den Entwurf prüfen und speichern

Claude Code scannt im Hintergrund und zeigt Ihnen dann den Entwurf. Sie nehmen ihn als Ganzes an oder verwerfen ihn. Bearbeiten Sie daher anschließend ~/.claude/settings.json, um einzelne Einträge anzupassen. Wenn Sie annehmen, schreibt Claude Code den Entwurf und gleicht ihn mit Ihren vorhandenen Einstellungen ab:

• Wenn Sie sich dafür entschieden haben, die Liste environment in ~/.claude/settings.json zu ergänzen, bleibt ein darin vorhandener "$defaults"-Eintrag erhalten. Wenn Sie sich dafür entschieden haben, diese Liste zu ersetzen, geht dieser Eintrag verloren. Fügen Sie "$defaults" daher wieder hinzu, wenn Sie die Standardeinträge verwenden möchten
• Claude Code fügt "$defaults" in jede der Listen allow, soft_deny und hard_deny ein, zu denen der Entwurf Einträge hinzufügt, es sei denn, Sie haben bereits eine allow-Liste ohne diesen Eintrag geschrieben. So bleiben die integrierten Regeln, die Sie nicht ersetzt haben, wirksam
• Nach dem Speichern bietet Claude Code an, permissions.allow-Regeln in ~/.claude/settings.json zu entfernen, die der Auto-Modus ignoriert, wie etwa Bash(*), oder die destruktive Befehle automatisch genehmigen

Führen Sie dann claude auto-mode config aus, um das wirksame Ergebnis anzuzeigen.

/auto-mode-setup ausschalten

Sobald der Auto-Modus mehrere Aktionen blockiert hat und Sie noch keine autoMode.environment-Einträge haben, zeigt Claude Code am Ende eines Turns einen Dialog mit dem Titel „Teach auto mode about your environment?“ an und bietet an, /auto-mode-setup für Sie auszuführen. Um das Angebot zu unterbinden, den Befehl aber zu behalten, wählen Sie in diesem Dialog Don't show again.

Um sowohl den Befehl als auch das Angebot auszuschalten, fügen Sie diesen skillOverrides-Eintrag zu ~/.claude/settings.json hinzu:

{
  "skillOverrides": {
    "auto-mode-setup": "off"
  }
}

/auto-mode-setup ist ein integrierter Befehl und kein mitgelieferter Skill. Dieser skillOverrides-Eintrag gilt daher trotzdem dafür, disableBundledSkills schaltet ihn jedoch nicht aus.

/auto-mode-setup gibt „Unknown command“ zurück

Wenn die Eingabe von /auto-mode-setup im Claude Code-Prompt Unknown command: /auto-mode-setup ausgibt, prüfen Sie diese Ursachen:

• Erste Sitzung nach einer Installation oder einem Upgrade: Starten Sie eine neue Sitzung. Wenn der Befehl dort weiterhin fehlt, lesen Sie über die Konfigurationen, in denen auch spätere Sitzungen ohne ihn starten.
• Veraltete Version: Führen Sie claude --version in Ihrer Shell aus. Wenn die Version unter dem Minimum für Ihren Plan liegt, aktualisieren Sie Claude Code.
• Telemetrie aus, Drittanbieter oder Claude Apps-Gateway: Vor v2.1.304 ist der Befehl in Sitzungen, in denen das Abrufen von Feature-Flags deaktiviert ist, nicht verfügbar. Wenn Ihre Sitzung dazu gehört, aktualisieren Sie Claude Code auf v2.1.304 oder höher.

In einer Cloud-Sitzung gibt der Befehl stattdessen /auto-mode-setup isn't available in this environment. aus. Führen Sie ihn in einer interaktiven Sitzung in Ihrem Terminal aus.

Override the block and allow rules

Drei zusätzliche Felder ermöglichen es Ihnen, die integrierten Regellisten des Klassifizierers zu ersetzen:

• autoMode.hard_deny: Aktionen, die blockiert werden, selbst wenn der Benutzer sie anfordert
• autoMode.soft_deny: destruktive Aktionen, die Benutzerabsicht aufheben kann
• autoMode.allow: Ausnahmen zu Soft-Block-Regeln

Jedes ist ein Array von Prosabeschreibungen, das als natürlichsprachige Regeln gelesen wird. Für werkzeugmuster-basierte harte Blöcke, die vor dem Klassifizierer ausgeführt werden, verwenden Sie permissions.deny.

Innerhalb des Klassifizierers funktioniert die Vorrangigkeit in vier Ebenen:

• hard_deny-Regeln blockieren bedingungslos. Benutzerabsicht und allow-Ausnahmen gelten nicht.
• soft_deny-Regeln blockieren als nächstes. Benutzerabsicht und allow-Ausnahmen können diese überschreiben.
• allow-Regeln überschreiben dann übereinstimmende soft_deny-Regeln als Ausnahmen.
• Explizite Benutzerabsicht überschreibt die verbleibenden weichen Blöcke: Wenn die Nachricht des Benutzers direkt und spezifisch die genaue Aktion beschreibt, die Claude ausführen wird, erlaubt der Klassifizierer es, auch wenn eine soft_deny-Regel zutrifft.

Allgemeine Anfragen zählen nicht als explizite Absicht. Claude zu bitten, das Repo „aufzuräumen“, autorisiert keinen Force-Push, aber Claude zu bitten, „diesen Branch zu force-pushen“, tut es.

Um zu lockern, fügen Sie zu allow hinzu, wenn der Klassifikator wiederholt ein wiederkehrendes Muster kennzeichnet, das die Standard-Ausnahmen nicht abdecken. Um zu straffen, fügen Sie zu soft_deny für destruktive Risiken hinzu, die spezifisch für Ihre Umgebung sind und die Standardwerte übersehen, oder zu hard_deny für Aktionen, die blockiert werden sollen, selbst wenn der Benutzer sie anfordert.

Um die integrierten Regeln beizubehalten und gleichzeitig Ihre eigenen hinzuzufügen, fügen Sie die Literalzeichenkette "$defaults" in das Array ein. Die Standardregeln werden an dieser Position eingefügt, sodass Ihre benutzerdefinierten Regeln vor oder nach ihnen stehen können, und Sie erhalten weiterhin Updates, wenn sich die integrierte Liste über Versionen hinweg ändert.

Das folgende Beispiel behält die Standardwerte in allen vier Listen bei und fügt organisationsspezifische Regeln zu jedem hinzu.

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "$defaults",
      "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": [
      "$defaults",
      "Never run database migrations outside the migrations CLI, even against dev databases",
      "Running terraform apply in infra/terraform/prod/ needs an explicit request: production infrastructure changes go through the review workflow"
    ],
    "hard_deny": [
      "$defaults",
      "Never send repository contents to third-party code-review APIs"
    ]
  }
}

[!CAUTION]

Das Festlegen eines der Felder environment, allow, soft_deny oder hard_deny ohne "$defaults" ersetzt die gesamte Standardliste für diesen Abschnitt. Wenn Sie ein Array ohne "$defaults" festlegen, verwerfen Sie die integrierten Regeln für diesen Abschnitt:

• soft_deny: jede integrierte Soft-Block-Regel, einschließlich Force-Push, curl | bash, Produktionsbereitstellungen und Auto-Mode-Bypass
• hard_deny: die integrierte Datenexfiltrations-Regel

Jeder Abschnitt wird unabhängig ausgewertet, sodass das Festlegen von environment allein die Standard-allow-, soft_deny- und hard_deny-Listen intakt lässt.

Lassen Sie "$defaults" nur weg, wenn Sie die vollständige Kontrolle über die Liste übernehmen möchten. Um dies sicher zu tun, führen Sie claude auto-mode defaults aus, um die integrierten Regeln auszudrucken, kopieren Sie sie in Ihre Einstellungsdatei, und überprüfen Sie dann jede Regel gegen Ihre eigene Pipeline und Risikotoleranz.

Bearbeitungsregeln aus /permissions

Um Klassifiziererregeln und environment-Einträge anzuzeigen und zu bearbeiten, ohne eine Einstellungsdatei zu öffnen, führen Sie /permissions aus und wählen Sie die Registerkarte Auto mode aus. Die Registerkarte erfordert Claude Code v2.1.246 oder später und wird nur angezeigt, wenn Auto mode für Ihre Sitzung verfügbar ist.

Claude Code zeigt Einträge aus verwalteten Einstellungen oder dem Flag --settings als schreibgeschützt an und speichert jede Änderung, die Sie auf der Registerkarte vornehmen, in ~/.claude/settings.json.

Alle Shell-Befehle durch den Klassifizierer leiten

Standardmäßig ermöglichen enge Bash- und PowerShell-Regeln wie Bash(npm test), dass sie im Auto-Modus wirksam bleiben, und Claude Code löst sie auf, bevor der Klassifizierer ausgeführt wird, es sei denn, der Befehl trägt pro-Befehl zulässige Domänen. Claude Code setzt nur die breiten Regeln aus, die beliebige Code-Ausführung ermöglichen, wie Bash(*) oder Wildcards-Interpreter, zusammen mit jeder Regel, die Monitor benennt, da Monitor-Befehle durch die Shell laufen. Dies bedeutet, dass eine enge Regel immer noch ein destruktives Argument durchlassen kann, ohne dass der Klassifizierer es sieht, beispielsweise einen Skriptpfad oder ein Flag, das das Präfix der Regel nicht vorgesehen hat.

Setzen Sie autoMode.classifyAllShell auf true, um jede Bash- und PowerShell-Erlaubnisregel auszusetzen, während der Auto-Modus aktiv ist, damit der Klassifizierer jeden Shell-Befehl unabhängig von Ihrer Erlaubnisliste evaluiert, außer kritische-Pfad-Entfernungen.

{
  "autoMode": {
    "classifyAllShell": true
  }
}

Dies tauscht Latenz gegen Abdeckung: Ein Befehl, den eine Erlaubnisregel sofort genehmigt hätte, wartet jetzt auf eine Klassifizierer-Entscheidung, und jeder Shell-Befehl zählt als ein Klassifizierer-Aufruf.

Die Einstellung gilt nur, während der Auto-Modus aktiv ist, und Ihre Erlaubnisregeln verhalten sich in anderen Berechtigungsmodi normal.

Überprüfen Sie die Standardwerte und Ihre effektive Konfiguration

Die Unterbefehle claude auto-mode helfen Ihnen, Ihre Konfiguration zu überprüfen, zu validieren und zurückzusetzen.

Geben Sie die integrierten Regeln environment, allow, soft_deny und hard_deny als JSON aus:

claude auto-mode defaults

Um die vollständige Formulierung einer Regel ohne Piping durch jq zu lesen, übergeben Sie --label mit dem Anfang des Regelbezeichners, z. B. claude auto-mode defaults --label 'Git Destructive'. Der Abgleich ist ein Präfix ohne Berücksichtigung der Groß-/Kleinschreibung für jeden Regelbezeichner, und Abschnitte ohne Übereinstimmung werden als leere Listen ausgegeben.

Geben Sie aus, was der Klassifizierer tatsächlich als JSON verwendet, mit Ihren Einstellungen, wo festgelegt, und Standardwerten andernfalls:

claude auto-mode config

Sowohl defaults als auch config geben die vier Regellisten als ein einzelnes JSON-Objekt aus, wobei jede Regel als Prosatext dargestellt wird. Dies ist ein verkürztes Beispiel:

{
  "allow": [
    ...
    "Test Artifacts: Hardcoded test API keys, placeholder credentials in examples, or hardcoding test cases. Placeholder means authored as a placeholder — a file or value copied from a real secret or sensitive path is never a test artifact (see Sensitive-Source Provenance).",
    ...
  ],
  "soft_deny": [
    "Git Destructive [named+specifics — **must name:** the destructive operation and its target]: Force pushing (`git push --force`), deleting remote branches, tags, or releases, or rewriting remote history. Also `git commit --amend` when the commit being rewritten is not the agent's own unpushed work: either no prior `git commit` is visible (HEAD pre-dates the session), or a `git push` of the current branch is visible after the most recent commit (it has been pushed). Clears when the user asked to amend/reword/fixup, or when it is a message-only reword (`--amend -m …`, nothing newly staged) of a commit the agent visibly created this session.",
    ...
  ],
  "hard_deny": [...],
  "environment": [
    ...
    "**Trusted repo**: The git repository the agent started in (its working directory) and its configured remote(s). When the repo's public/private visibility is given — by the Repository visibility entry or the user's own message — use it to scope what is OK to commit or push there: confidential material is fine in a private repo; in a public one, only that repo's own work is — and content ported, repointed, or first read from outside this session's repo is not its own work, whoever directed the port. Visibility scopes confidential material only: secrets and sensitive data (personal & entrusted) are never cleared into any repo by its visibility (see Definitions).",
    ...
  ]
}

Erhalten Sie KI-Feedback zu Ihren benutzerdefinierten Einträgen für allow, soft_deny, hard_deny und environment:

claude auto-mode critique

Wenn Sie benutzerdefinierte Regeln geschrieben haben, überprüft claude auto-mode critique diese und kennzeichnet Einträge, die mehrdeutig, redundant oder wahrscheinlich zu falsch positiven Ergebnissen führen.

Um Ihre Anpassungen zu verwerfen und zu den integrierten Standardwerten zurückzukehren, führen Sie den Reset-Unterbefehl aus, der den Abschnitt autoMode aus Ihrer Benutzereinstellungsdatei entfernt:

claude auto-mode reset

Der Befehl fasst zusammen, was entfernt wird, und fragt Reset auto mode configuration to defaults? ab, bevor er schreibt. Übergeben Sie --yes, um die Bestätigung zu überspringen. Reset ändert nur ~/.claude/settings.json: Regeln für autoMode aus verwalteten Einstellungen oder dem Flag --settings gelten weiterhin.

Ablehnungen überprüfen

Um Claude eine blockierte Aktion erneut versuchen zu lassen, verwenden Sie die Registerkarte Recently blocked in /permissions:

1. Registerkarte öffnen

Führen Sie in Ihrer Sitzung /permissions aus, um den Berechtigungsdialog zu öffnen, und wählen Sie dann die Registerkarte Recently blocked aus.

2. Aktion prüfen

Markieren Sie die Zeile der Aktion und lesen Sie ihren Befehl oder ihre Eingabe unterhalb der Liste. Orientieren Sie sich am Befehl oder an der Eingabe, nicht an der Beschreibung der Zeile, die Claude oder das Tool verfasst hat.

3. Aktion genehmigen

Drücken Sie r, um die Aktion zu genehmigen und Claude sie erneut versuchen zu lassen.

4. Dialog schließen

Drücken Sie Esc, um den Dialog zu schließen und Ihre Genehmigung anzuwenden. Wenn Claude gerade gearbeitet hat, als Sie /permissions geöffnet haben, senden Sie eine Nachricht, sobald Claude fertig ist, damit Claude die Aktion erneut versuchen kann. Andernfalls müssen Sie nichts senden: Claude fährt jetzt fort und versucht sie möglicherweise erneut. Falls nicht, nennen Sie die Aktion in Ihrer nächsten Nachricht, wie unter Genehmigungen, die Sie in der Konversation angeben beschrieben.

Das Genehmigen einer Aktion fügt keine Berechtigungsregel hinzu. Im Auto-Modus durchläuft eine erneut versuchte Aktion die Prüfung noch einmal und kann daher erneut blockiert werden. Um einen Befehl von nun an durchzulassen, fügen Sie eine allow-Regel hinzu.

Wenn Claude es nicht sofort erneut versuchen soll, können Sie eine Aktion für später genehmigen, eine Genehmigung zurücknehmen oder den Dialog schließen und Ihre Genehmigungen verwerfen:

• Für später genehmigen: Drücken Sie Enter auf der Zeile und dann Esc. Die Zeile verschwindet von der Registerkarte, und Claude versucht die Aktion möglicherweise nach Ihrer nächsten Nachricht erneut, sobald Claude fertig ist. Wenn Sie zusätzlich auf einer anderen Zeile r gedrückt haben, bleibt die Zeile, auf der Sie Enter gedrückt haben, auf der Registerkarte, und Claude wird über diese Aktion nicht informiert. Genehmigen Sie diese Zeile bei Ihrem nächsten Besuch, oder drücken Sie auf beiden r
• Eine Genehmigung zurücknehmen: Drücken Sie, bevor Sie Esc drücken, Enter auf der Zeile, unabhängig davon, ob Sie sie mit Enter oder r genehmigt haben
• Den Dialog schließen und Ihre Genehmigungen verwerfen: Drücken Sie zweimal Ctrl+C

Sie können eine Aktion nicht über die Registerkarte genehmigen, wenn ihre Zeile nicht ihren gesamten Befehl oder ihre gesamte Eingabe anzeigen kann oder wenn die Aktion keine Zeile hat:

• Die Zeile lautet This row can't be approved here: Wenn Sie die Aktion beabsichtigt haben, teilen Sie dies Claude in Ihrer nächsten Nachricht mit, und Claude versucht sie möglicherweise erneut
• Keine Zeile, und Not run oder ein Klassifikatorfehler in der Konversation: Der Klassifikator des Auto-Modus hat kein Urteil gefällt. Wie Sie die Aktion ausführen, erfahren Sie unter Auto mode cannot determine the safety of an action

Eine Ablehnung mit einer Allow-Regel, einem Umgebungseintrag oder einem Wiederholungsversuch beheben

Benachrichtigungen lauten etwa bash blocked by auto mode · /permissions · Auto mode: [Data Exfiltration]. Um den Befehl oder die URL hinter einer solchen Benachrichtigung zu lesen, verwenden Sie die Registerkarte Recently blocked, einen Hook oder die Konversation:

• Registerkarte Recently blocked: Markieren Sie die Zeile der Aktion. Im Screenreader-Modus erscheinen alle Befehle und Eingaben vor der Liste.
• Hook: Um die genaue Eingabe von Ablehnungen programmgesteuert zu erfassen, fügen Sie einen PermissionDenied Hook hinzu, der sie als tool_input empfängt. Wenn Ihr Hook reason liest, erwarten Sie kein Präfix Auto mode: und Text wie Blocked by classifier anstelle von No reason provided.
• Konversation: Suchen Sie den Tool-Aufruf. Wenn der Aufruf verkürzt oder in eine Zusammenfassungszeile wie Ran 3 shell commands eingeklappt angezeigt wird, drücken Sie Ctrl+O, um den Transkript-Viewer zu öffnen, der ihn erweitert.

Der Text unter dem Aufruf teilt Ihnen mit, ob es etwas zu beheben gibt. Eine abgeblendete Zeile Not run · auto mode's check had no usable answer oder Text, der ein Problem mit dem Klassifikator selbst meldet, z. B. Auto mode could not evaluate this action, bedeutet, dass Claude Code den Aufruf ohne ein Urteil des Klassifikators blockiert hat. Drücken Sie bei einer Not run-Zeile Ctrl+O, um die vollständige Meldung zu lesen, und lesen Sie dann unter Auto mode cannot determine the safety of an action oder The server returned no safety verdict nach, was zu tun ist.

Andernfalls bedeutet eine Zeile Blocked by auto mode, dass der Klassifikator den Aufruf für unsicher befunden hat. Um den Aufruf durchzulassen, wählen Sie den Schritt, der dazu passt, was Claude erreichen oder tun wollte:

• Ein Ziel, das Claude während der gesamten Aufgabe benötigt, z. B. eine Paket-Registry, eine interne Domäne oder einen Repository-Host: Fügen Sie es zu autoMode.environment hinzu.
• Ein Befehl, den Sie von nun an ohne Überprüfung ausführen möchten: Fügen Sie eine allow-Regel hinzu.
• Eine einmalige Aktion, die Sie beabsichtigt haben: Geben Sie diese Absicht in Ihrer nächsten Nachricht an und lassen Sie Claude es erneut versuchen.

Sie können den Umgebungseintrag oder die allow-Regel aus der Registerkarte Auto mode des Dialogs /permissions hinzufügen.

Der Text in eckigen Klammern, z. B. [Data Exfiltration], ist der Name der Regel, die der Klassifizierer gefunden hat. Um die vollständige Formulierung dieser Regel zu lesen, siehe Inspect the defaults and your effective config.

Wiederholte Ablehnungen beheben

Wiederholte Ablehnungen für dasselbe Ziel bedeuten normalerweise, dass dem Klassifizierer der Kontext fehlt. Fügen Sie dieses Ziel zu autoMode.environment hinzu, oder führen Sie /auto-mode-setup aus, damit Claude Code die Einträge entwirft, und führen Sie dann claude auto-mode config aus, um zu bestätigen, dass die Änderung wirksam wurde.

Siehe auch

• Berechtigungsmodi: was Auto-Modus ist, was er standardmäßig blockiert, und welche Sitzungen darin starten
• Verwaltete Einstellungen: stellen Sie autoMode-Konfiguration in Ihrer Organisation bereit
• Berechtigungen: Zulassen-, Fragen- und Ablehnungsregeln, die vor dem Klassifizierer gelten
• Alle Einstellungen: jeden Einstellungsschlüssel, einschließlich autoMode