Claude Code: Auto-Modus wird zum neuen Standard

Was der Auto-Modus am 14. August 2026 ändert

Der Auto-Modus von Claude Code führt Tool-Aufrufe aus, ohne Sie vorher zu fragen, und sendet jede Aktion zur vorherigen Prüfung an ein separates Klassifizierungsmodell. Ab dem 14. August 2026 ist dies der Modus, in dem neue Sitzungen auf den Pro-, Max- und Team-Plänen starten. Sie können den Modus jederzeit wechseln. Ein Standardwert, den Sie bereits selbst festgelegt haben, wird nicht überschrieben.

Die Dokumentation beschreibt die Änderung wie folgt:

Ab dem 14. August 2026 wird der Auto-Modus zum standardmäßigen Berechtigungsmodus für neue Sitzungen auf den Pro-, Max- und Team-Plänen. Sie können den Modus jederzeit wechseln. Ein von Ihnen festgelegter Standardwert bleibt bestehen, sofern Sie der einmaligen Aufforderung zum Wechsel nicht zustimmen. Ein von Ihrer Organisation verwalteter Standardwert bleibt unverändert.

Zwei Aussagen darin sind wichtiger als das Datum. Ein defaultMode, den Sie in Ihrer eigenen Einstellungsdatei festgelegt haben, bleibt durch die Änderung erhalten. Auch ein Standardwert, den Ihre Organisation über verwaltete Einstellungen bereitstellt, bleibt bestehen. Der Ankündigungsbeitrag ergänzt, dass der Auto-Modus während der ersten Phase der Einführung für Enterprise-Pläne und Konten, die die API verwenden, optional bleibt.

Wenn Sie Claude Code auf einem VPS (virtuellen privaten Server) ausführen, sollten Sie die Änderung vor ihrem Inkrafttreten lesen. Eine Berechtigungsabfrage ist ein Prüfpunkt, an dem eine Person an der Tastatur erforderlich ist. Auf einem entfernten System sind Sie häufig nicht anwesend. Daher bleibt eine Sitzung stundenlang in dem Modus, in dem sie startet.

Die Berechtigungsmodi von Claude Code, von der stärksten zur geringsten Überwachung

Es gibt sechs Modi. Der Name am Anfang jeder Zeile ist der Wert, den Sie in den Einstellungen eintragen oder an --permission-mode übergeben. Alle sechs Modi werden von Claude Code selbst und nicht vom Modell durchgesetzt, weil die Entscheidung darüber, was ein Tool-Aufruf tun darf, die Aufgabe des Harnesses um das Modell herum ist.

• default: Claude fragt vor jeder neuen Tool-Nutzung nach. Lesezugriffe innerhalb Ihres Arbeitsverzeichnisses laufen weiterhin ohne Nachfrage. Die CLI (command line interface) bezeichnet diesen Modus als Manual und akzeptiert seit Claude Code v2.1.200 manual als Alias.
• plan: Claude liest Dateien und führt Befehle zur Untersuchung aus, ändert Ihre Quelldateien jedoch nicht. Änderungen bleiben blockiert, bis Sie den Plan bestätigen.
• acceptEdits: Dateiänderungen laufen ohne Nachfrage, ebenso die Dateisystembefehle mkdir, touch, rm, rmdir, mv, cp und sed. Dies gilt nur für Pfade innerhalb Ihres Arbeitsverzeichnisses oder Ihres additionalDirectories. Für jeden anderen Shell-Befehl wird weiterhin nachgefragt.
• auto: Alles wird ausgeführt, wobei der Klassifikator jede Aktion zuerst prüft. Explizite Regeln in ask erzwingen weiterhin eine Nachfrage.
• dontAsk: Claude Code lehnt alles automatisch ab, was eine Nachfrage ausgelöst hätte. Ausgeführt werden nur Ihre allow-Regeln, die integrierten schreibgeschützten Bash-Befehle und Aufrufe, die ein PreToolUse-Hook genehmigt. Die Sitzung wartet niemals auf Eingaben.
• bypassPermissions: Nachfragen und Sicherheitsprüfungen werden übersprungen. Das gilt auch für Schreibzugriffe auf geschützte Pfade wie .git und .claude.

Drücken Sie während einer Sitzung Shift+Tab, um von default über acceptEdits zu plan zu wechseln. Die Statusleiste zeigt den aktiven Modus an, beispielsweise ⏵⏵ auto mode on oder ein graues ⏸ manual mode on. Die anderen Modi gehören standardmäßig nicht zu diesem Wechsel. auto wird aufgenommen, sobald Ihr Konto die Voraussetzungen dafür erfüllt. bypassPermissions wird nur aufgenommen, wenn die Sitzung mit --permission-mode bypassPermissions oder --dangerously-skip-permissions gestartet wurde. dontAsk erscheint dort nie. Setzen Sie diesen Modus daher mit claude --permission-mode dontAsk.

Der Auto-Modus benötigt außerdem ein aktuelles Modell. Das ist normalerweise der Grund, warum er überhaupt nicht angezeigt wird. Im August 2026 nennt die Dokumentation Claude Opus 4.6 oder höher, Sonnet 4.6 oder höher sowie Fable 5 in der Anthropic API als unterstützte Modelle. Außerdem werden ältere Modelle wie Sonnet 4.5 bei keinem Provider unterstützt. Wenn Claude Code den Auto-Modus als nicht verfügbar meldet, ist eine dieser Voraussetzungen nicht erfüllt. Es handelt sich nicht um einen vorübergehenden Ausfall. Warten behebt das Problem daher nicht.

Zwei Einstellungen gelten in jedem Modus, auch in bypassPermissions: Regeln in deny und explizite Regeln in ask. Diese Steuerungsmöglichkeiten bleiben unabhängig davon erhalten, in welchem Modus eine Sitzung gestartet wird.

Was der Klassifikator im Automatikmodus blockiert

Der Klassifikator ist ein zweites Modell. Es liest die ausstehende Aktion und entscheidet, ob sie zu Ihrer Anfrage passt. Die Dokumentation beschreibt seine Aufgabe in einem Satz:

Ein separates Klassifikatormodell prüft Aktionen, bevor sie ausgeführt werden. Es blockiert alles, was über Ihre Anfrage hinausgeht, auf nicht erkannte Infrastruktur zielt oder offenbar durch schädliche Inhalte ausgelöst wurde, die Claude gelesen hat.

Standardmäßig blockiert werden insbesondere folgende Aktionen, die bei der Serververwaltung häufig vorkommen:

• Herunterladen und Ausführen von Code, beispielsweise curl | bash
• Deployments und Migrationen in der Produktion
• Force Push
• Ändern gemeinsam genutzter Infrastruktur
• Öffnen eines Tunnels oder einer Reverse Shell, durch den ein lokaler Dienst aus dem öffentlichen Internet erreichbar wird
• Ausgeben eines aktiven Zugangsdatenwerts oder Tokens im Transkript oder in einer Datei

Standardmäßig erlaubt sind:

• Lokale Dateioperationen in Ihrem Arbeitsverzeichnis
• Installieren von Abhängigkeiten, die in Ihren Lock-Dateien oder Manifesten angegeben sind
• HTTP-Anfragen mit Lesezugriff
• Pushen in jeden Branch des Repositorys, in dem Sie arbeiten

Arbeiten Sie nicht anhand einer Zusammenfassung wie der obigen. Führen Sie claude auto-mode defaults aus, um die vollständigen Regellisten als JSON auszugeben, und lesen Sie den Regelsatz, der mit der von Ihnen installierten Version ausgeliefert wurde.

Bevor Sie sich darauf verlassen, sind 2 dokumentierte Einschränkungen wichtig. Erstens sieht der Klassifikator Ihre Nachrichten, die Tool-Aufrufe und Ihre Inhalte CLAUDE.md. Tool-Ergebnisse werden entfernt. Text in einer Datei oder auf einer Webseite, die Claude gelesen hat, kann den Klassifikator daher nicht direkt ansprechen. Zweitens pausiert der Automatikmodus, wenn der Klassifikator eine Aktion 3-mal hintereinander oder 20-mal innerhalb einer Sitzung blockiert. Claude Code fordert Sie dann wieder zur Bestätigung auf. Diese Schwellenwerte können nicht konfiguriert werden. Im nicht interaktiven Modus mit dem Flag -p gibt es niemanden, den das System auffordern kann. Wiederholte Blockierungen brechen die Sitzung stattdessen ab.

Dieses zweite Verhalten ist es, das auf einem entfernten System problematisch wird. Ein unbeaufsichtigter Lauf, der das Limit erreicht, wird angehalten und wartet auf eine Person, die nicht auf das Terminal schaut. Eine zweite Claude Code-Sitzung auf demselben System ersetzt diese Person nicht, da von einer Sitzung an eine andere gesendeter Text zurückgehalten wird, bis die empfangende Sitzung ihn abruft, und eine Sitzung, die an einer Berechtigungsabfrage pausiert, weiterhin eine menschliche Antwort benötigt. Den Aufgabenbereich des Agenten einzugrenzen, ist die andere Hälfte der Lösung. Eine Skill, die den Agenten zu der kleinsten funktionierenden Änderung anleitet, verhindert, dass eine Sitzung in umfangreiche Aktionen abgleitet, die der Klassifizierer stoppt. Während eine Skill eine einzelne Aufgabe steuert, bearbeitet ein Ausgabestil den System-Prompt selbst. Ein Stil, der kleine, gezielte Änderungen verlangt, gilt daher für jeden Turn der Sitzung und nicht nur für die eine Aufgabe, für die Sie ihn aufgerufen haben.

Wo die Modi in settings.json definiert sind

Alles oben ist ein Objekt in einer Einstellungsdatei.

{
  "permissions": {
    "defaultMode": "auto",
    "allow": [
      "Bash(npm run test *)",
      "Bash(git status)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(docker compose up *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  }
}

Regeln werden in dieser Reihenfolge ausgewertet: deny, dann ask, dann allow. Das erste passende Ergebnis in dieser Reihenfolge bestimmt das Verhalten. Eine spezifischere Regel setzt keine weiter gefasste Regel außer Kraft, wenn diese früher kommt. Eine deny-Regel für Bash(aws *) blockiert aws s3 ls auch dann, wenn Sie genau diesen Befehl zusätzlich erlaubt haben. Eine deny-Regel kann daher keine Ausnahmen enthalten.

ask ist der Regeltyp, der im auto-Modus seinen Zweck erfüllt. Der auto-Modus entfernt die routinemäßige Abfrage. Eine ask-Regel fügt für den angegebenen Befehl wieder eine Abfrage hinzu, die eine Person bestätigen muss. Ihr Bereitstellungsbefehl gehört dort hinein. Das gilt auch für Bash(git push *), wenn vor dem Verlassen des Systems ein Kontrollpunkt erforderlich ist. Bewahren Sie Anmeldeinformationsdateien in deny auf. Das ist die zweite Maßnahme und ergänzt Anmeldeinformationen von vornherein außerhalb der Reichweite eines Agenten zu halten.

Die Einstellungsdateien selbst, zunächst mit der niedrigsten Priorität:

• ~/.claude/settings.json: Ihre Benutzereinstellungen, die in jedem Projekt angewendet werden.
• .claude/settings.json: Projekteinstellungen, die im Repository versioniert werden.
• .claude/settings.local.json: Ihre eigenen Einstellungen für ein Repository, die von git ignoriert werden.
• Verwaltete Einstellungen, die ein Administrator bereitstellt. Unter Linux befindet sich diese Datei in /etc/claude-code/managed-settings.json. Keine Einstellung kann eine verwaltete Berechtigungsregel außer Kraft setzen, auch kein Befehlszeilen-Flag.

Hier gibt es eine Falle mit dokumentierter Ursache. defaultMode: "auto" wird ignoriert, wenn die Einstellung aus .claude/settings.json oder .claude/settings.local.json stammt, und zwar ab Claude Code v2.1.142. Dadurch kann ein Repository den auto-Modus nicht durch eine mitgelieferte Einstellungsdatei aktivieren. Wenn Sie die Zeile dort setzen, startet die Sitzung im default-Modus, ohne dass irgendwo eine Fehlermeldung ausgegeben wird. Verschieben Sie die Zeile nach ~/.claude/settings.json. Führen Sie /permissions aus, um jede aktive Regel zusammen mit der Datei aufzulisten, aus der sie stammt.

Die beiden Schalter zum Deaktivieren eines Modus

Administratoren haben zwei Notabschalter. Beide erwarten die Zeichenfolge "disable" und keinen booleschen Wert.

{
  "permissions": {
    "disableAutoMode": "disable",
    "disableBypassPermissionsMode": "disable"
  }
}

Die Dokumentation beschreibt genau, wo sie einzutragen sind:

Um zu verhindern, dass der Modus bypassPermissions oder auto verwendet wird, setzen Sie permissions.disableBypassPermissionsMode oder permissions.disableAutoMode in einer beliebigen Einstellungsdatei auf "disable". Diese Optionen sind besonders für verwaltete Einstellungen geeignet, da sie dort nicht überschrieben werden können.

disableAutoMode entfernt auto aus dem Shift+Tab-Zyklus und weist --permission-mode auto beim Start zurück. disableBypassPermissionsMode erfüllt dieselbe Aufgabe für den Bypass-Modus und funktioniert in jedem Geltungsbereich. Sie können die Option daher in Ihrer eigenen ~/.claude/settings.json setzen, um einen Modus zu sperren, den Sie auf einem produktiv genutzten Server nachts um 2am nicht versehentlich aktivieren möchten. Auf einem System, das von mehreren Personen verwendet wird, tragen Sie beide Optionen stattdessen in /etc/claude-code/managed-settings.json ein, da eine Benutzereinstellungsdatei dem jeweiligen Benutzer gehört, eine verwaltete Einstellungsdatei jedoch nicht.

Warum der Auto-Modus auf einem VPS eine Isolationsgrenze benötigt

Der Klassifikator prüft jeweils eine einzelne Aktion. Er beschränkt nicht, was eine genehmigte Aktion anschließend ausführt. Die Dokumentation zieht die Grenze klar:

Der Klassifikator ist eine Kontrolle pro Aktion und keine Isolationsgrenze. Eine Isolationsgrenze bietet daher auch bei unbeaufsichtigten Ausführungen zusätzliche Sicherheit. Sie ist jedoch nicht in derselben Weise erforderlich wie für --dangerously-skip-permissions.

Für einen entfernten Server lautet die geeignete Kombination daher Auto-Modus plus eine Umgebung, deren Verlust Sie akzeptieren, nicht bypassPermissions plus Hoffnung. Der Bypass-Modus ist ausschließlich für isolierte Umgebungen dokumentiert: Container, virtuelle Maschinen oder Dev-Container ohne Internetzugriff, in denen Claude Code Ihr Host-System nicht beschädigen kann. Ein VPS, auf dem Ihre Datenbank und Ihr Reverse Proxy laufen, gehört zu keiner dieser Kategorien.

Drei Maßnahmen sind auf einem Server besonders wichtig. Führen Sie Claude Code als normaler Benutzer aus, niemals als root. Geben Sie diesem Benutzer ein Arbeitsverzeichnis und keine weiteren lesenswerten Daten. Bauen Sie den Server neu auf, statt ihn zu reparieren. Das ist der Grund für eine verworfene VM, die Sie nach jedem Auftrag löschen. Die Details zur Absicherung, von der Benutzererstellung bis zu den Firewall-Regeln, werden in der vollständigen Sicherheitsprüfung für Claude Code auf einem VPS behandelt und hier nicht wiederholt.

Claude Code erzwingt die root-Regel selbst. Unter Linux und macOS verweigert das Programm den Start im Bypass-Modus unter sudo oder als root:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

Diese Prüfung wird innerhalb einer erkannten Sandbox übersprungen. Deshalb empfiehlt die Dokumentation für autonome Arbeit in Containern einen Dev-Container, in dem Claude Code als Benutzer ohne root-Rechte ausgeführt wird. Wenn Sie den Agenten von einem Telefon oder Laptop über SSH steuern, gilt dieselbe Überlegung für eine lange laufende Claude-Code-Sitzung in tmux: Während die Sitzung läuft, beobachtet niemand die Eingabeaufforderung. Nichts davon beginnt, bevor die Anmeldung funktioniert. Wenn der Server Sie mit Permission denied (publickey) abweist, zeigt die ausführliche SSH-Ausgabe, welchen der fünf Fehler Sie tatsächlich haben.

Bash-Sandbox auf einem Ubuntu-VPS einrichten

Die integrierte Sandbox beschränkt den Dateisystem- und Netzwerkzugriff jedes Bash-Befehls, den Claude ausführt. Das Betriebssystem setzt diese Beschränkungen auch für untergeordnete Prozesse durch. Unter Linux werden dafür zwei Pakete benötigt.

sudo apt-get install bubblewrap socat

Starten Sie Claude Code und führen Sie /sandbox aus. Das Panel wird mit einem Tab „Mode“ und einem Tab „Overrides“ sowie einem Tab „Dependencies“ geöffnet, in dem alle fehlenden Abhängigkeiten aufgeführt sind. Die Abhängigkeitsprüfung läuft beim Start. Starten Sie Claude Code nach der Installation der Pakete daher neu. Andernfalls meldet das Panel die Pakete weiterhin als fehlend.

Unter Ubuntu 24.04 und höher verhindert die standardmäßige AppArmor-Richtlinie, dass bubblewrap die benötigten User-Namespaces erstellt. Dadurch kann die Sandbox nicht gestartet werden. Prüfen Sie, ob dies auf Ihrem System zutrifft:

sysctl kernel.apparmor_restrict_unprivileged_userns

Ein 0 oder eine Fehlermeldung, dass der Schlüssel nicht vorhanden ist, bedeutet, dass nichts zu tun ist. Ein 1 bedeutet, dass bwrap ein eigenes Profil benötigt:

sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>

profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}
EOF
sudo systemctl reload apparmor

Das Profil gilt für bwrap selbst, nicht für die Befehle, die darin innerhalb der Sandbox ausgeführt werden. Schränken Sie die Grenze anschließend in den Einstellungen ein:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Dieser Block gehört in die .claude/settings.json des Projekts, weil . nur aus den Projekteinstellungen zum Projektstammverzeichnis aufgelöst wird. Fügen Sie dieselben Zeilen in ~/.claude/settings.json ein. Dann wird . stattdessen zu ~/.claude aufgelöst. Dadurch hält die Regel denyRead Ihre Projektdateien weiterhin blockiert, und jeder Befehl kann den Code, den er bearbeiten soll, nicht lesen.

Beachten Sie, was dadurch nicht abgedeckt wird. Die Sandbox beschränkt Bash und dessen untergeordnete Prozesse. Die integrierten Dateiverarbeitungswerkzeuge laufen innerhalb des Claude-Code-Prozesses. MCP-Server (Model Context Protocol) und Hooks sind separate Prozesse, die ohne Einschränkung auf dem Host ausgeführt werden. Um alle diese Komponenten hinter einer gemeinsamen Grenze auszuführen, starten Sie den gesamten Claude-Code-Prozess innerhalb eines Containers, einer virtuellen Maschine oder des Pakets @anthropic-ai/sandbox-runtime. Zum Zeitpunkt der Erstellung dieses Textes handelt es sich dabei um eine Beta-Forschungs-Vorschau.

Welcher Modus ist für die jeweilige Umgebung geeignet?

Ein einzelnes Repository auf Ihrem eigenen Laptop

Verwenden Sie auto mit ask-Regeln für die Aktionen, die Sie überwachen möchten. Sie sitzen an der Tastatur, die Rückfallebene des Klassifizierers kann Sie tatsächlich erreichen, und der mögliche Schaden ist auf einen von Ihnen kontrollierten Rechner begrenzt. Für diesen Fall wurde der Standard vom 14 August festgelegt.

Ein gemeinsam genutzter VPS

Verwenden Sie auto pro Benutzer. Legen Sie den Modus in der jeweiligen ~/.claude/settings.json des Benutzers fest. Der Account, unter dem Claude Code ausgeführt wird, darf auf dem System nicht root sein und die Arbeit der anderen Benutzer nicht lesen können. Stellen Sie disableBypassPermissionsMode als "disable" in /etc/claude-code/managed-settings.json bereit. Ergänzen Sie die Konfiguration um deny-Regeln, die gemeinsam genutzte Pfade schützen. Auf einem gemeinsam genutzten System ist bypassPermissions eindeutig ungeeignet, weil die von diesem Modus vorausgesetzte Isolationsgrenze nicht existiert: Die anderen Mandanten befinden sich innerhalb dieser Grenze.

CI und unbeaufsichtigte Sitzungen

Verwenden Sie dontAsk mit einer expliziten allow-Liste der Befehle, die der Job benötigt. Auto-deny ist das korrekte Fehlerverhalten, wenn niemand eine Eingabeaufforderung sehen wird. Der Auto-Modus läuft ebenfalls nicht interaktiv. Wiederholte Blockierungen durch den Klassifizierer brechen jedoch eine -p-Sitzung ab. Ein Job, bei dem solche Blockierungen auftreten, schlägt daher während der Ausführung fehl und hinterlässt unvollständig ausgeführte Arbeiten. Verwenden Sie bypassPermissions nur in einem Container oder einer virtuellen Maschine, die Sie aus einem Image neu erstellen. Verwenden Sie ihn nicht auf einem Host, auf dem außerdem Systeme oder Dienste laufen, die Sie benötigen.

FAQ

Wann wird der automatische Modus in Claude Code zum Standard?

Ab dem 14. August 2026 für neue Sitzungen in den Pro-, Max- und Team-Tarifen. In der Dokumentation wird ergänzt, dass Sie jederzeit zwischen den Modi wechseln können, dass ein von Ihnen festgelegter Standard erhalten bleibt, solange Sie die einmalige Aufforderung zum Wechsel nicht akzeptieren, und dass ein von Ihrer Organisation verwalteter Standard unverändert bleibt. Laut Ankündigung bleibt der automatische Modus während des ersten Teils der Einführung für Enterprise-Tarife und für Konten, die die API verwenden, optional. Prüfen Sie den tatsächlichen Modus einer Sitzung in der Statusleiste. Im automatischen Modus wird dort ⏵⏵ auto mode on angezeigt.

Sollte ich auf einem VPS den automatischen Modus oder bypassPermissions verwenden?

Den automatischen Modus zusammen mit einer Isolationsgrenze. Der Klassifizierer prüft jede Aktion vor ihrer Ausführung. In der Dokumentation wird jedoch ausdrücklich darauf hingewiesen, dass diese Prüfung pro Aktion erfolgt und keine Isolationsgrenze darstellt. Auch ein unbeaufsichtigter Lauf benötigt daher einen Container, eine virtuelle Maschine oder ein System, das Sie bei Bedarf neu aufsetzen können. bypassPermissions überspringt die Prüfungen vollständig und ist laut Dokumentation nur für isolierte Umgebungen vorgesehen. Claude Code verweigert den Start in diesem Modus als root unter Linux und gibt --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons aus.

Wie verhindere ich, dass jemand auf meinem Server den automatischen Modus oder den Bypass-Modus verwendet?

Setzen Sie permissions.disableAutoMode und permissions.disableBypassPermissionsMode in /etc/claude-code/managed-settings.json auf die Zeichenfolge "disable". Verwaltete Einstellungen haben Vorrang vor allen anderen Gültigkeitsbereichen. Daher können weder eine Einstellungsdatei eines Benutzers noch ein Befehlszeilen-Flag diese Einstellungen überschreiben. disableAutoMode entfernt auto aus dem Shift+Tab-Zyklus und lehnt --permission-mode auto beim Start ab. disableBypassPermissionsMode funktioniert ebenfalls in jedem Gültigkeitsbereich. Ein einzelner Benutzer kann die Einstellung daher in seiner eigenen ~/.claude/settings.json setzen.

Warum wird meine Einstellung defaultMode: "auto" ignoriert?

Weil sie sich in der falschen Datei befindet. Ab Claude Code v2.1.142 wird defaultMode: "auto" ignoriert, wenn die Einstellung aus .claude/settings.json oder .claude/settings.local.json stammt. Dadurch kann ein Repository den automatischen Modus nicht über eine mitgelieferte Einstellungsdatei selbst aktivieren. Die Sitzung startet im Modus default und gibt keinen Fehler aus. Verschieben Sie die Einstellung nach ~/.claude/settings.json. Führen Sie anschließend /permissions aus, um zu prüfen, aus welcher Datei die einzelnen aktiven Regeln stammen. Wenn der automatische Modus weiterhin nicht verfügbar ist, prüfen Sie die Modellanforderung: Ältere Modelle wie Sonnet 4.5 werden von keinem Provider unterstützt.