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.

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.

Informationen dazu, wie Sitzungen in Auto-Modus landen und was der Klassifizierer standardmäßig blockiert, finden Sie unter Auto-Modus auf der Seite „Berechtigungsmodi". Diese Seite ist die Konfigurationsreferenz.

Diese Seite behandelt, wie Sie:

• Einen menschlichen Checkpoint für Pushes und Pull Requests mit permissions.ask hinzufügen
• Wählen Sie, wo Sie Regeln festlegen über CLAUDE.md, Benutzereinstellungen und verwaltete Einstellungen
• Definieren Sie vertrauenswürdige Infrastruktur mit autoMode.environment
• Generieren Sie Umgebungseinträge mit /auto-mode-setup
• Überschreiben Sie die Block- und Allow-Regeln, wenn die Standardwerte nicht zu Ihrer Pipeline passen
• Bearbeiten Sie Regeln von /permissions ohne eine Einstellungsdatei zu öffnen
• Leiten Sie alle Shell-Befehle durch den Klassifizierer mit autoMode.classifyAllShell
• Überprüfen Sie Ihre effektive Konfiguration mit den claude auto-mode-Unterbefehlen
• Ü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. Vor v2.1.207 las der Klassifizierer auch .claude/settings.local.json; verschiebe alle autoMode-Blöcke in dieser Datei zu ~/.claude/settings.json. Das Ausschließen von .claude/settings.local.json schließt auch den Fall, in dem ein Repository die Datei committed oder ein lokales Tool oder Build-Schritt sie schreibt.

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.

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.

Ab Claude Code v2.1.198 gibt claude auto-mode defaults drei Arten von Umgebungseinträgen aus. Versionen vor v2.1.195 geben nur die ersten fünf Vertrauensplätze 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. Die Transkript-Beweis-Prüfung erfordert Claude Code v2.1.200 oder später

  • 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. Diese Scoping-Anforderung erfordert Claude Code v2.1.203 oder später.
• 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. Claude Code v2.1.195 bis v2.1.197 nennt diesen Eintrag PII / regulated-data locations und deckt nur Speicherorte ab, die persönliche oder regulierte Daten enthalten, ohne die Zielgruppen-Dimension
• 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

Die Einträge Internal package registry, Sensitive data locations & audiences, Sensitive remote targets und Protected IaC scopes erfordern Claude Code v2.1.195 oder später. Frühere Versionen lesen sie immer noch als einfachen Kontext, haben aber nicht die integrierten Regeln, die auf sie abzielen.

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

Je spezifischer der Kontext ist, 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 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 autoMode.environment-Einträge und manchmal auch Regeleinträge aus Ihrem Projekt und Ihren letzten Sitzungen darin entwirft. Wenn Sie den Entwurf akzeptieren, schreibt Claude Code ihn in ~/.claude/settings.json.

Was `/auto-mode-setup` liest

Wenn ~/.claude/settings.json bereits autoMode-Einträge enthält, fragt Claude Code zunächst, ob Sie Ihre Umgebungsliste erweitern oder ersetzen möchten, und behält die von Ihnen geschriebenen Regeln in jedem Fall bei. Claude Code fragt dann, wie Sie dieses Projekt nutzen, und bietet zwei optionale Scans an, bevor es etwas scannt. Beim Scan liest Claude Code immer diese Quellen:

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

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

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

Entwurf überprüfen und speichern

Claude Code scannt im Hintergrund und zeigt Ihnen dann den Entwurf. Sie akzeptieren oder verwerfen ihn als Ganzes, daher bearbeiten Sie ~/.claude/settings.json danach, um einzelne Einträge anzupassen. Wenn Sie akzeptieren, schreibt Claude Code den Entwurf und gleicht ihn mit den Einstellungen ab, die Sie bereits haben:

• Claude Code schreibt die environment-Liste ohne "$defaults", da der Entwurf die integrierten Einträge aufzählt, die unverändert geblieben sind
• Claude Code fügt "$defaults" in jede der allow-, soft_deny- und hard_deny-Listen ein, zu denen der Entwurf Einträge hinzufügt, es sei denn, Sie haben bereits eine allow-Liste ohne sie geschrieben, damit die integrierten Regeln, die Sie nicht ersetzt haben, weiterhin gelten
• Nach dem Speichern bietet Claude Code an, permissions.allow-Regeln in ~/.claude/settings.json zu entfernen, die der Auto-Modus ignoriert, wie Bash(*), oder die destruktive Befehle automatisch genehmigen

Führen Sie dann claude auto-mode config aus, um das effektive Ergebnis zu sehen.

`/auto-mode-setup` ausschalten

Sobald der Auto-Modus mehrere Aktionen blockiert hat und Sie immer noch keine autoMode.environment-Einträge haben, zeigt Claude Code am Ende einer Runde ein Dialogfeld mit dem Titel „Auto-Modus über Ihre Umgebung unterrichten?" an und bietet an, /auto-mode-setup für Sie auszuführen. Um das Angebot zu stoppen, aber den Befehl zu behalten, wählen Sie Nicht mehr anzeigen in diesem Dialogfeld.

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 keine gebündelte Skill, daher gilt dieser skillOverrides-Eintrag immer noch dafür, aber disableBundledSkills schaltet ihn nicht 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: bedingungslose Sicherheitsgrenzen
• 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 Klassifizierer wiederholt ein routinemäßiges 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 Sicherheitsgrenzen, die niemals überschritten werden dürfen.

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",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow"
    ],
    "hard_deny": [
      "$defaults",
      "Never send repository contents to third-party code-review APIs"
    ]
  }
}

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

Die Registerkarte listet die Einträge allow, soft_deny, hard_deny und environment aus jedem der Bereiche, die der Klassifizierer liest, auf und zeigt an, ob die integrierten Regeln für jeden Abschnitt wirksam sind. 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. Auf der Registerkarte können Sie:

• Regeln in den Abschnitten allow, soft_deny und hard_deny hinzufügen, bearbeiten oder löschen. Wenn Sie die erste Regel zu einem Abschnitt hinzufügen, fügt Claude Code auch "$defaults" ein, damit die integrierten Regeln wirksam bleiben.
• Die integrierten Regeln für allow, soft_deny oder hard_deny aus- oder wieder einschalten. Claude Code speichert die Auswahl, indem es "$defaults" in Ihrer Liste für diesen Abschnitt hinzufügt oder entfernt. Ein Abschnitt benötigt daher mindestens eine eigene Regel, bevor Sie die integrierten Regeln ausschalten können.
• Die Einträge environment als ein Dokument in Ihrem Editor bearbeiten. Wenn Sie noch keine environment-Einträge konfiguriert haben, fragt Claude Code zunächst, ob die integrierte Umgebung ersetzt werden soll, und öffnet dann den Editor mit dem vollständigen integrierten Text. Wenn Sie speichern, ersetzt Claude Code Ihr autoMode.environment-Array durch das Dokument. Fügen Sie die Zeile "$defaults" ein, um die integrierten Einträge beizubehalten.

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.

{
  "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. Erfordert Claude Code v2.1.208 oder später.

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 Regeln allow, soft_deny und hard_deny:

claude auto-mode critique

Führen Sie claude auto-mode config nach dem Speichern Ihrer Einstellungen aus, um zu bestätigen, dass die effektiven Regeln Ihren Erwartungen entsprechen, wobei "$defaults" an Ort und Stelle erweitert wird. 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. Er erfordert Claude Code v2.1.212 oder später und entfernt den Abschnitt autoMode aus Ihrer Benutzereinstellungsdatei:

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 Aktionen zu überprüfen und erneut zu versuchen, die der Auto-Modus-Klassifizierer abgelehnt hat, öffnen Sie /permissions und wählen Sie die Registerkarte Kürzlich abgelehnt, in der Claude Code jede Ablehnung aufzeichnet. Drücken Sie r auf einer abgelehnten Aktion, um sie zum Wiederholen zu markieren: Wenn Sie den Dialog beenden, sendet Claude Code eine Nachricht, die dem Modell mitteilt, dass es diesen Tool-Aufruf wiederholen darf, und setzt das Gespräch fort.

Wenn der Klassifizierer keine Entscheidung zur Aktion trifft, weil eine Sicherheitsprüfung, die vom Auto-Modus getrennt ist, die Anfrage des Klassifizierers selbst oder dessen Antwort nicht analysiert hat, lehnt Claude Code die Aktion ab, ohne sie unter Kürzlich abgelehnt aufzuzeichnen. Der verlinkte Fehlereintrag behandelt, was Claude mitgeteilt wird, und wie die Aktion ausgeführt wird, falls Sie sie benötigen.

Eine Ablehnung mit einer Erlaubnisregel, einem Umgebungseintrag oder einem Wiederholungsversuch beheben

Um zu sehen, was der Klassifizierer blockiert hat, suchen Sie den Tool-Aufruf im Gespräch. Wenn der Aufruf verkürzt oder in eine Zusammenfassungszeile wie Ran 3 shell commands eingeklappt angezeigt wird, drücken Sie Ctrl+O, um den Transcript-Viewer zu öffnen, der ihn erweitert.

Zwei weitere Stellen auf dem Bildschirm, die Ablehnungen melden, lassen den Befehl oder die URL aus: Die Benachrichtigung neben dem Eingabefeld, z. B. bash denied by auto mode · [Data Exfiltration] · /permissions, gibt das Tool und den Grund an, und die Registerkarte Kürzlich abgelehnt listet einen Shell-Befehl nach der Beschreibung auf, die Claude dafür geschrieben hat. Um die genaue Eingabe dieser Ablehnungen programmgesteuert zu erfassen, fügen Sie einen PermissionDenied-Hook hinzu, der sie als tool_input empfängt.

Der Text unter dem Aufruf teilt Ihnen mit, ob es etwas zu beheben gibt. Text, der ein Problem mit dem Klassifizierer selbst meldet, z. B. ein Modell, das is temporarily unavailable ist, oder ein Klassifizierer-Fehler, bedeutet, dass Claude Code den Aufruf ohne endgültige Entscheidung des Klassifizierers blockiert hat; siehe Auto-Modus kann die Sicherheit einer Aktion nicht bestimmen für weitere Informationen. Andernfalls bedeutet eine Zeile, die Denied by auto mode classifier mit einem Grund wie [Production Deploy] oder Blocked by classifier liest, dass der Klassifizierer den Aufruf für unsicher befunden hat. Wählen Sie daher die Behebung aus dem aus, was der Aufruf 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 erneut versuchen.

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

In den meisten Sitzungen benennt der Grund die Regel, die der Klassifizierer abgeglichen hat, in eckigen Klammern, z. B. [Data Exfiltration] oder [Production Deploy], und einige Sitzungen führen ein Klassifizierer-Modell aus, das eine kurze Erklärung hinzufügt. Claude Code wählt das Klassifizierer-Modell aus, daher ist es nicht etwas, das Sie konfigurieren können, welche Form Sie sehen.

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.

Um programmgesteuert auf Ablehnungen zu reagieren, verwenden Sie den PermissionDenied-Hook.

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