Claude Code /auto-mode-setup: dem Auto-Mode-Classifier deine Umgebung beibringen und prüfen, welches Modell deine Aktionen wirklich bewertet

Zwei aktuelle Claude-Code-Releases fassen dieselbe Sache von zwei Seiten an. Version 2.1.302 (16. Oktober) hat CLAUDE_CODE_AUTO_MODE_MODEL eingeführt, das festlegt, auf welchem Modell der clientseitige Auto-Mode-Classifier läuft. Laut Version 2.1.304 (19. Oktober) ist /auto-mode-setup, der geführte Befehl, der deine autoMode.environment-Einträge entwirft, jetzt auch auf Bedrock, Vertex, Foundry, dem Claude-Apps-Gateway und in Sessions ohne Telemetrie verfügbar. Das eine ändert, wer urteilt. Das andere ändert, was der Richter über deine Welt weiß.

Ich habe beides auf 2.1.304 ausprobiert, in Wegwerf-Repositories, mit User-Settings ganz ohne autoMode-Block: claude auto-mode config gab dasselbe JSON aus wie claude auto-mode defaults. Zwei Ergebnisse tragen alles Weitere. Der Entwurf des Setups hat die meisten mitgelieferten Einträge, die er angefasst hat, gekürzt, und wer ihn übernimmt, friert diese kürzeren Fassungen ein. Und das Modell, das ich für den Classifier gewählt hatte, wurde überstimmt, bevor ein einziger Befehl lief. Warum ein Classifier eine schwache Grenze ist, steht in einem früheren Essay. Hier geht es darum, ihn gut zu konfigurieren, wenn er nun einmal da ist.

Was schreibt Claude Codes /auto-mode-setup eigentlich?

Es schreibt autoMode.environment-Einträge, manchmal auch Allow- oder Deny-Regeln, nach ~/.claude/settings.json, und du übernimmst oder verwirfst den Entwurf als Ganzes. Laut Doku liest es immer CLAUDE.md, README.md, Konfigurationsdateien und Git-Remotes des Projekts, deine bestehenden autoMode- und permissions.allow-Settings sowie Hosts, Buckets und Befehlsnamen aus den Befehlen, die Claude in deinen letzten Sessions in diesem Projekt ausgeführt hat. Deine Nachrichten liest es nie. Zwei optionale Scans ergänzen das erste Wort jeder Zeile deiner Shell-History und die Remotes der Repositories unter deinem Home-Verzeichnis.

Das wichtigste Detail steckt im Speicherschritt. Die übernommene environment-Liste wird ohne "$defaults" geschrieben, erklärt die Doku, weil der Entwurf die eingebauten Einträge, die er behalten hat, bereits ausschreibt. "$defaults" ist das Token, das die mitgelieferte Liste in deine einfügt und dafür sorgt, dass du Änderungen daran über Releases hinweg erbst. Die Übernahme macht aus dem Environment-Abschnitt also statt „Defaults plus meine Ergänzungen“ eine „bearbeitete Kopie der heutigen Defaults“. Die Regellisten, die der Entwurf ergänzt, bekommen dagegen "$defaults", außer du hattest schon eine allow-Liste ohne "$defaults" geschrieben.

Behalt noch eine Zeile aus der Doku für später im Kopf. Der Classifier liest autoMode nur aus den User-Settings, den Managed Settings und dem --settings-Flag, nie aus .claude/settings.json im Repo, weil sonst ein eingechecktes Repo oder ein Build-Schritt eigene Allow-Regeln einschleusen könnte.

Bei der Verfügbarkeit herrscht Durcheinander. Die Konfigurationsseite, die ich am selben Tag gelesen habe, sagt noch, der Befehl brauche einen Pro-, Max- oder Team-Plan und das Abrufen von Feature-Flags, was Sessions ohne Telemetrie ausschließt. Das Changelog zu 2.1.304 sagt das Gegenteil. Eins von beiden hinkt hinterher.

Wie führst du /auto-mode-setup aus, ohne deine Settings zu ändern?

Interaktiv: ausführen und den Entwurf verwerfen. Headless zerfällt es in zwei Schritte, und der erste schlägt nur vor. Ohne Argumente in claude -p getippt, antwortet der Befehl mit seiner Usage:

/auto-mode-setup [--request-id <uuid>] --wizard posture=<personal|open-source|enterprise|mixed> scope=<all|project> depth=<both|shell|repos|here> --propose
/auto-mode-setup [--request-id <uuid>] [--apply-target <user|project>] --expect-sha256 <64-hex> --apply-file <absolute-path>

Der Apply-Schritt liest den Vorschlag aus einer Datei im System-Temp-Verzeichnis oder im Claude-Konfigurationsverzeichnis und verweigert das Schreiben, wenn die Bytes dieser Datei nicht den sha256 ergeben, den du übergibst. Das bindet das Schreiben an genau eine Datei. Es beweist nicht, dass jemand sie gelesen hat; das Vorzeigen an einen Menschen überlässt der Usage-Text dem Aufrufer. Für einen Entwurf und sonst nichts:

sha256sum ~/.claude/settings.json
claude -p --permission-mode default \
  "/auto-mode-setup --wizard posture=personal scope=project depth=here --propose" \
  < /dev/null > proposal.json
sha256sum ~/.claude/settings.json

depth=here überspringt beide optionalen Scans, gelesen werden also weder Shell-History noch die Repositories unter deinem Home-Verzeichnis. Bei mir stimmten die beiden Hashes überein. Laut Usage-Text prüft --apply-target außerdem nur den Scope des Vorschlags und wählt keine Datei: Die Einträge landen immer in deinen User-Settings. Auch ein scope=project-Entwurf geht in die Datei, die alle deine Projekte lesen. Ob der Classifier diese Einträge dann auf das eine Projekt beschränkt, aus dem sie stammen, konnte ich von außen nicht prüfen.

Was hat der /auto-mode-setup-Entwurf an den Auto-Mode-Defaults geändert?

In meinem Lauf hat er sieben der 21 mitgelieferten Environment-Einträge umgeschrieben, die meisten davon gekürzt, und einen eigenen Slot ergänzt. Das Test-Repo hatte ein erfundenes GitHub-Remote, eine package.json und ein kurzes README, das ein Staging-Deploy-Skript und einen S3-Bucket nennt. Dort war noch keine Session gelaufen, aus der Nutzung hatte der Entwurf also nichts.

Um dasselbe auf deiner Maschine zu sehen, vergleich den Entwurf in beide Richtungen mit der mitgelieferten Liste:

claude auto-mode defaults > defaults.json
python3 - <<'EOF'
import json, re
label = lambda s: (re.match(r"\*\*(.+?)\*\*", s) or [None, None])[1]
d = {label(x): x for x in json.load(open("defaults.json"))["environment"]}
draft = json.load(open("proposal.json"))["proposal"]["environment"]
p = {label(x): x for x in draft if label(x)}
for k in d:
    if p.get(k) != d[k]:
        print(f"changed  {k}: {len(d[k])} -> {len(p.get(k) or '')} chars")
for k in p:
    if k not in d:
        print(f"added    {k}: {p[k]}")
for x in draft:
    if not label(x):
        print(f"unlabeled: {x}")
EOF

Vierzehn Einträge kamen unverändert zurück. Vier der sieben Änderungen haben Kontext aus dem Repo eingetragen, und genau das ist der Job: CI/CD deploy targets, Source control, Trusted cloud buckets und Repository visibility, die vom mitgelieferten „als privat annehmen“ auf „möglicherweise öffentlich“ gewechselt ist, weil das Setup es nicht prüfen konnte. Diese Änderung macht den Eintrag strenger. Außerdem hat der Entwurf einen Slot Default / protected branches ergänzt, als nicht abfragbar markiert, plus zwei Abschnittsüberschriften.

Die anderen drei Änderungen waren Kürzungen. Der mitgelieferte Eintrag Host containment hat 802 Zeichen, der des Entwurfs 128. Weggefallen ist der Teil mit der Anleitung:

Whatever is configured, instance-metadata credential paths and node/cluster
credentials of the hosting layer are never task credentials unless this entry
says the agent operates that identity (see Containment Escape). The classifier
sees commands, not their output, so a declared-sealed box that is actually
open cannot be caught here — enforce that in network configuration.

Die Notizen des Entwurfs führen ausgerechnet Host containment unter den Einträgen, die auf den mitgelieferten Defaults belassen wurden. Belassen wurde er nicht. Wer die Notizen statt der Einträge prüft, übersieht die Kürzung.

Trusted repo nennt jetzt das Repository und ist dabei von 667 auf 130 Zeichen geschrumpft. Verloren ging der Satz, dass die Sichtbarkeit eines Repos Secrets und personenbezogene Daten nie für dieses Repo freigibt. Sensitive remote targets hat seine Heuristik behalten, aber das Beispiel verloren, das sie festnagelt: prod-db matchen, nicht producer. Die Containment-Escape-Regel steht weiter in soft_deny, keine Sperre ist also verschwunden. Verschwunden ist Kontext, auf den die Regeln zurückverweisen.

Das war ein Lauf mit einem modellgeschriebenen Entwurf auf einem fast leeren Repo, und ein reicheres Projekt bekommt einen anderen. Das Setup ist nicht kaputt. Der Entwurf ist eine Bearbeitung der Defaults, und eine Bearbeitung liest man als Diff.

Sollte ein README Claude Codes Auto Mode einen vertrauenswürdigen Bucket hinzufügen dürfen?

Nein, nicht bevor du den Bucket selbst bestätigt hast. Aus einem Satz im README wurde dieser Eintrag im Entwurf:

**Trusted cloud buckets**: s3://example-org-builds (config-derived — not a
confirmed upload destination; uploads of local data still require confirmation)

Der Entwurf hat ihn abgeschwächt, und seine Notizen haben den Eintrag als nur aus dem README stammend markiert. Nichts wurde übernommen und kein Upload getestet, das hier zeigt also einen Weg, keinen Exploit. Ein Repository kann den Classifier schon heute beeinflussen: Laut Doku liest er bei jeder Prüfung die CLAUDE.md des Projekts. Was ein Repository nicht kann, ist einen Vertrauens-Slot schreiben, und deshalb wird autoMode aus den Projekt-Settings herausgehalten. Der Setup-Befehl öffnet diese Tür eine Ebene höher. Er liest die Prosa des Repositorys, macht aus einem Satz einen Vertrauenseintrag und bietet an, ihn in der Datei zu speichern, die alle deine Projekte lesen, wo er die Session überlebt. Zwischen „das Repo hat es mir gesagt“ und „ich habe entschieden“ steht nur das Review, und ein Alles-oder-nichts-Entwurf mit zwei Dutzend Einträgen lädt zu der reflexhaften Freigabe ein, die jeden menschlichen Kontrollpunkt abnutzt.

Die Regel, die ich anwenden würde: Einträge in den Vertrauens-Slots (Source Control, Domains, Buckets, interne Dienste) schreibst oder bestätigst du von Hand. Lass das Setup sie entwerfen und lösch dann alle, für die du dich nicht aus eigener Kenntnis der Infrastruktur verbürgen kannst. Was eine Datei im Repo behauptet, reicht dafür nicht. Ein geklontes Repo, das du nicht gelesen hast, ist genau der Ort, an dem eine eingeschleuste Zeile säße. claude auto-mode critique prüft eigene Einträge auf Mehrdeutigkeit und Fehlalarmrisiko, liest aber deine installierten Settings, nicht proposal.json, hilft also erst nach der Übernahme.

Welches Modell bewertet Aktionen in Claude Codes Auto Mode?

Standardmäßig läuft der Classifier auf Claude Sonnet 5. In vielen Sessions bewertet allerdings der Server die Aktionen innerhalb der Modell-Requests der Session selbst, und der Client-Classifier übernimmt nur, was der Server nicht abdeckt. CLAUDE_CODE_AUTO_MODE_MODEL ändert nur den Client-Classifier; die Changelog-Zeile zu 2.1.302 sagt, dass serverseitiger Auto Mode unberührt bleibt.

Über deiner Einstellung gibt es eine zweite Instanz, und mein Test ist auf sie gestoßen. Ich habe die Variable auf claude-sonnet-4-6 gesetzt und eine headless Auto-Mode-Session mit --debug-file gestartet. Das Log meldete beim Start, vor jedem Tool-Aufruf:

[WARN] Auto mode classifier: ignoring CLAUDE_CODE_AUTO_MODE_MODEL=claude-sonnet-4-6 because a server-configured classifier model (claude-sonnet-5[1m]) takes priority; using that model instead

Die Doku führt diesen Fall in der Tabelle der Standardmodelle sogar an erster Stelle (ein von Anthropic für deine Session konfiguriertes Classifier-Modell), aber ob er dich betrifft, siehst du erst, wenn du nachschaust. Wer Claude Opus 5, Claude Sonnet 5.5 oder Claude Opus 5.5 wählt, landet ebenfalls beim Standard-Classifier-Modell; „nimm das stärkste Modell“ steht also gar nicht zur Wahl. Eine Modell-ID, die dein Provider nicht bedienen kann, ist schlimmer: Die Requests schlagen fehl, und jede bewertete Aktion wird abgelehnt.

Zum Prüfen startest du eine Session mit der Variable und einer Debug-Datei, lässt Claude einen Shell-Befehl ausführen, der nicht nur liest, und durchsuchst dann das Log:

CLAUDE_CODE_AUTO_MODE_MODEL=claude-sonnet-4-6 claude --permission-mode auto --debug-file classifier-debug.log
grep -E "classifier_request_started|ignoring CLAUDE_CODE_AUTO_MODE_MODEL" classifier-debug.log

Setz die vollständige Modell-ID deines Providers ein. Du willst classifier_request_started mit deinem Modell hinter model= sehen. Meine Läufe zeigen, wo dieses Rezept dünn wird. Ein mkdir und eine date-Umleitung im Repo haben den Client-Classifier komplett übersprungen; das Log sagte Skipping auto mode classifier for Bash: would be allowed in acceptEdits mode, also der dokumentierte Schnellpfad für Edits im Arbeitsbaum. Ein curl auf example.com erzeugte überhaupt keine classifier_request_started-Zeile. Das ist das erwartete Ergebnis für eine claude -p-Session mit direkter API-Verbindung, die standardmäßig den Server um das Review bittet, und den nächsten Schritt aus der Doku, die Zeile Auto mode server in /status, gibt es in -p nicht.

Um die Frage headless zu erzwingen, schalt das Server-Review für einen Lauf mit CLAUDE_CODE_AUTO_MODE_SERVER=0 ab. Auf Accounts, die Classifier-Requests abrechnen, wird dieser Lauf berechnet. Meiner lieferte die Zeile, mit weiterhin aktiver Überstimmung:

classifier_request_started reqId=… tool=Bash model=claude-sonnet-5[1m] stage=xml_s1

Auf diesem Account hat die Variable also in keinem der beiden Modi etwas bewirkt. Den meisten Lesern rate ich, sie in Ruhe zu lassen. Die Ausnahme ist ein Setup, in dem der Client-Classifier das ganze Review übernimmt, typischerweise ein LLM-Gateway, das die Request- und Response-Felder entfernt, die das Server-Review braucht. Repariere zuerst das Gateway: Laut Doku soll es Header, Body-Felder und Streaming-Events unverändert durchreichen. Kann es das nicht, sorgt CLAUDE_CODE_AUTO_MODE_SERVER=0 dafür, dass die Session nicht mehr fragt, und dann ist das Modell des Classifiers eine echte Entscheidung über Kosten und Latenz.

Was gehört in Claude Codes Deny-Regeln statt ins Auto-Mode-Environment?

Alles, was nie passieren darf, gehört in permissions.deny; das Environment beschreibt nur, wem du vertraust. Deny-Regeln greifen, bevor der Classifier gefragt wird, und in Managed Settings kann sie niemand überstimmen. Environment-Einträge sind Prosa, die der Classifier abwägt. Die Doku sagt außerdem, dass sich die Scopes additiv kombinieren und keine Policy-Grenze bilden; ein eigener allow-Eintrag eines Entwicklers kann also ein soft_deny der Organisation überstimmen. Und eine im Gespräch gezogene Grenze wie „push nicht, bevor ich es reviewt habe“ kann verschwinden, wenn die Compaction die Nachricht entfernt, in der sie stand.

Die Aufteilung, die ich nutzen würde: Environment-Einträge für das, was dir gehört (Orgs, Buckets, interne Hosts, was als Produktion zählt), permissions.ask für Kontrollpunkte, die du weiter sehen willst, und Deny-Regeln für die kurze Liste der Dinge, deren Kosten nicht umkehrbar sind. Deny-Regeln haben eigene Grenzen; sie matchen den Befehlstext, den Claude schreibt, und eine Reihe neuerer Fixes hat gezeigt, wo dieses Matching gebrochen ist. Eine Regel, die halten muss, egal, wie ein Modell sie auslegt, gehört in eine Prüfung, die der Harness ausführt, wie ein anderes Essay ausführlich begründet.

Wenn du einen Setup-Entwurf übernimmst, kannst du das Einfrieren rückgängig machen. Setz "$defaults" wieder an den Anfang der Environment-Liste, behalt die Einträge, die etwas ergänzen, das der mitgelieferte Text nicht weiß, und lösch die, die einen Default nur wiederholen oder kürzen. Welche welche sind, sagt dir das Diff-Skript oben. Das Beispiel der Doku stellt selbst eine eigene Source-control-Zeile neben "$defaults", die Form ist also unterstützt; der Preis ist, dass ein Default-Slot und deine Zeile dazu beide im Prompt bleiben und der Classifier beide liest. Einzelne Einträge bearbeitest du im Auto-Mode-Tab von /permissions, und claude auto-mode reset entfernt den ganzen autoMode-Block, falls du neu anfangen willst. Prosa in autoMode.environment ist für den Classifier die bessere Prosa, und sie bleibt trotzdem Prosa.