Auto-Modus konfigurieren

• 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

​

Einen menschlichen Checkpoint hinzufügen

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

​

Wo der Klassifizierer die Konfiguration liest

​

Vertrauenswürdige Infrastruktur definieren

• Kontextplätze: beschreiben Ihre Organisation, Ihren Stack und Ihre Sicherheitslage, damit der Klassifizierer die anderen Regeln in Ihrem Kontext liest. Jeder hat einen Standard von None configured oder zur konservativen Annahme, die daneben benannt ist:
  • Organisation
  • Primäre Verwendung von Claude Code: Standard ist Softwareentwicklung
  • Cloud-Anbieter
  • Repository-Sichtbarkeit: Ein Repository wird als privat angenommen, es sei denn, sein Remote-Host und Name deuten anderes an, oder eine Sichtbarkeitsprüfung früher im Gespräch, die der Klassifizierer liest, zeigt, dass es öffentlich ist. Der Klassifizierer liest Ihre Nachrichten und die Befehle, die Claude ausführt, nicht deren Ausgabe, daher muss der Beweis etwas sein, das er 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: Standard ist 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 / Klassifizierungsaufhebung
• 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 Standard auf das Arbeits-Repository und seine konfigurierten Remotes. Jeder andere Vertrauensplatz hat Standard auf None configured, daher ist nichts anderes vertrauenswürdig, bis Sie es hinzufügen. Die Sichtbarkeit eines Repositorys umfasst nur vertrauliches Material: Ein privates Repository ist ein akzeptables Ziel für vertrauliches Material, aber ein Repository privat zu machen löscht niemals Secrets oder persönliche oder anvertraute Daten darin, und der Klassifizierer behandelt Inhalte, die von außerhalb des Arbeits-Repositorys portiert, umgeleitet oder zuerst gelesen werden, als nicht die eigene Arbeit dieses Repositorys. Diese Scoping 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 Standard auf eine breite Heuristik, wie das Behandeln jedes Hosts oder Namespace, dessen Name prod oder production trägt, als sensibles Remote-Ziel, daher sind die Schutzregeln aktiv, bevor Sie etwas konfigurieren. Das Benennen konkreter Ziele in einem Sensibilitätsplatz macht diese Regeln auf die benannten Ziele anwenden, anstatt auf die Heuristik.

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

• Organisation: Ihr Unternehmensname und wofür Claude Code hauptsächlich verwendet wird, wie Softwareentwicklung, Infrastruktur-Automatisierung oder Datentechnik
• Source Control: jede GitHub-, GitLab- oder Bitbucket-Organisation, zu der Ihre Entwickler pushen
• Cloud-Anbieter und vertrauenswürdige Buckets: Bucket-Namen oder Präfixe, aus denen Claude lesen und in die Claude schreiben kann
• 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 Paket-Indizes, Incident-Tools
• Interne Paket-Registry: die private npm-, PyPI- oder andere Registry, durch die Installationen laufen sollten, daher werden Installationen, die sie für eine öffentliche Registry umgehen, blockiert
• 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 Ort geteilt werden können, damit der Klassifizierer diese Orte schützt, anstatt vom Inhalt zu raten. Claude Code v2.1.195 bis v2.1.197 benennen diesen Eintrag PII / regulated-data locations und decken nur Orte 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, daher benötigen Remote-Shells und Port-Forwards in sie Ihre ausdrückliche Genehmigung
• 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

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

​

Umgebungseinträge mit /auto-mode-setup generieren

​

Was /auto-mode-setup liest

• 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

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

​

/auto-mode-setup ausschalten

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

​

Override the block and allow rules

• autoMode.hard_deny: bedingungslose Sicherheitsgrenzen
• autoMode.soft_deny: destruktive Aktionen, die Benutzerabsicht aufheben kann
• autoMode.allow: Ausnahmen zu Soft-Block-Regeln

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

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

​

Bearbeitungsregeln aus /permissions

• 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

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

​

Überprüfen Sie die Standardwerte und Ihre effektive Konfiguration

claude auto-mode defaults

claude auto-mode config

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

claude auto-mode critique

claude auto-mode reset

​

Ablehnungen überprüfen

​

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

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

​

Wiederholte Ablehnungen beheben

​

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