Claude Code: Auto-Modus wird am 14. August 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 zunächst zur Prüfung an ein separates Klassifizierungsmodell. Ab dem 14. August 2026 ist dies der Modus, mit dem neue Sitzungen in den Tarifen Pro, Max und Team starten. Sie können den Modus jederzeit wechseln. Einen von Ihnen bereits festgelegten Standard überschreibt die Änderung nicht.

Die Dokumentation beschreibt die Änderung wie folgt:

Ab dem 14. August 2026 wird der Auto-Modus zum standardmäßigen Berechtigungsmodus für neue Sitzungen in den Tarifen Pro, Max und Team. Sie können den Modus jederzeit wechseln. Ein von Ihnen selbst festgelegter Standard bleibt bestehen, sofern Sie die einmalige Aufforderung zum Wechsel nicht akzeptieren. Ein von Ihrer Organisation verwalteter Standard bleibt unverändert.

Zwei Aussagen sind dabei wichtiger als das Datum. Ein defaultMode, den Sie in Ihrer eigenen Einstellungsdatei festlegen, bleibt nach der Änderung bestehen. Ein Standard, den Ihre Organisation über verwaltete Einstellungen ausrollt, bleibt ebenfalls erhalten. Der Ankündigungsbeitrag ergänzt, dass der Auto-Modus für Enterprise-Tarife und für Konten, die während des ersten Teils der Einführung die API verwenden, optional bleibt.

Wenn Sie Claude Code auf einem VPS (virtuellen privaten Server) ausführen, sollten Sie die Änderung vor ihrer Einführung lesen. Eine Berechtigungsabfrage ist ein Prüfpunkt, an dem eine Person an der Tastatur erforderlich ist. Auf einem Remote-System sind Sie häufig nicht anwesend. Daher bleibt der Modus, mit dem eine Sitzung startet, dort möglicherweise stundenlang aktiv.

Die Berechtigungsmodi von Claude Code, von der meisten zur geringsten Kontrolle

Es gibt sechs Modi. Der Name am Anfang jeder Zeile ist der Wert, den Sie in den Einstellungen eintragen oder an --permission-mode übergeben.

• default: Claude fragt vor jeder neuen Tool-Nutzung. Lesezugriffe innerhalb Ihres Arbeitsverzeichnisses laufen weiterhin ohne Rückfrage. Die CLI (Befehlszeilenschnittstelle) bezeichnet diesen Modus als Manual und akzeptiert manual ab Claude Code v2.1.200 als Alias.
• plan: Claude liest Dateien und führt Befehle zur Erkundung aus, ändert aber Ihren Quellcode nicht. Änderungen bleiben blockiert, bis Sie den Plan freigeben.
• acceptEdits: Dateiänderungen laufen ohne Rückfrage. Das gilt auch für die Dateisystembefehle mkdir, touch, rm, rmdir, mv, cp und sed. Dies gilt nur für Pfade innerhalb Ihres Arbeitsverzeichnisses oder Ihres additionalDirectories. Jeder andere Shell-Befehl erfordert weiterhin eine Rückfrage.
• auto: Alles wird ausgeführt, wobei der Classifier zuerst jede Aktion prüft. Explizite Regeln in ask erzwingen weiterhin eine Rückfrage.
• dontAsk: Claude Code lehnt alles automatisch ab, was andernfalls eine Rückfrage ausgelöst hätte. Es werden nur Ihre Regeln in allow, die integrierten schreibgeschützten Bash-Befehle und Aufrufe ausgeführt, die ein PreToolUse-Hook genehmigt. Die Sitzung wartet nie auf Eingaben.
• bypassPermissions: Rückfragen 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 zu acceptEdits und anschließend zu plan zu wechseln. Die Statusleiste zeigt den ausgewählten Modus an, beispielsweise ⏵⏵ auto mode on oder ein graues ⏸ manual mode on. Die anderen Modi sind standardmäßig nicht in diesem Zyklus enthalten. 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 wird dort nie angezeigt. Legen Sie diesen Modus daher mit claude --permission-mode dontAsk fest.

Der Auto-Modus erfordert 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 und Fable 5 in der Anthropic API. Außerdem weist sie darauf hin, dass ältere Modelle wie Sonnet 4.5 bei keinem Anbieter unterstützt werden. 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 wird das Problem daher nicht beheben.

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

Was der Auto-Modus-Klassifikator 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 Klassifikationsmodell 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, auf die Serverbetreiber am häufigsten stoßen:

• Herunterladen und Ausführen von Code, etwa 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
• Nur lesende HTTP-Anfragen
• Pushen in jeden Branch des Repositorys, in dem Sie arbeiten

Verlassen Sie sich nicht auf eine Zusammenfassung wie die obige. 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 CLAUDE.md-Inhalte. Tool-Ergebnisse werden entfernt. Text in einer Datei oder auf einer Webseite, die Claude gelesen hat, kann den Klassifikator daher nicht direkt anweisen. Zweitens pausiert der Auto-Modus, 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 zur Bestätigung auffordern kann. Wiederholte Blockierungen brechen die Sitzung stattdessen ab.

Dieses zweite Verhalten ist auf einem Remote-System besonders problematisch. Ein unbeaufsichtigter Lauf wird beendet, sobald er das Limit erreicht, und wartet dann auf eine Person, die das Terminal nicht überwacht. Sie müssen daher auch den Aufgabenbereich des Agenten einschränken. Eine Skill, die den Agenten auf die kleinste funktionierende Änderung ausrichtet, verhindert, dass eine Sitzung in umfangreiche Aktionen abdriftet, die der Klassifikator blockiert.

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. Die erste passende Regel in dieser Reihenfolge bestimmt das Ergebnis. Eine engere Regel hat keinen Vorrang vor einer früher stehenden, allgemeineren Regel. Eine deny-Regel für Bash(aws *) blockiert aws s3 ls, selbst 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 Rückfrage. Eine ask-Regel aktiviert sie für den angegebenen Befehl wieder. Ihr Deploy-Befehl gehört dorthin. Das gilt auch für Bash(git push *), wenn Sie einen Kontrollpunkt einrichten möchten, bevor Code das System verlässt. Bewahren Sie Credential-Dateien in deny auf. Das ist die andere Hälfte dieser Konfiguration und ergänzt das grundsätzliche Fernhalten von Credentials aus dem Zugriffsbereich eines Agents.

Die Einstellungsdateien selbst, in aufsteigender Reihenfolge ihrer Priorität:

• ~/.claude/settings.json: Ihre Benutzereinstellungen, die in jedem Projekt angewendet werden.
• .claude/settings.json: Projekteinstellungen, die in das Repository committed werden.
• .claude/settings.local.json: Ihre eigenen Einstellungen für ein Repository, die von git ignoriert werden.
• Verwaltete Einstellungen, die von einem Administrator bereitgestellt werden. Unter Linux ist diese Datei /etc/claude-code/managed-settings.json. Eine verwaltete Berechtigungsregel kann nicht überschrieben werden, auch nicht mit einem Befehlszeilen-Flag.

Hier gibt es eine Falle mit dokumentierter Ursache. defaultMode: "auto" wird ignoriert, wenn es 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 Einstellung 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 zur Verfügung. Beide erwarten die Zeichenfolge "disable" statt eines booleschen Werts.

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

Die Dokumentation beschreibt genau, wo sie einzutragen sind:

Damit der Modus bypassPermissions oder auto nicht verwendet wird, setzen Sie permissions.disableBypassPermissionsMode oder permissions.disableAutoMode in einer beliebigen Einstellungsdatei auf "disable". Diese Optionen sind besonders für verwaltete Einstellungen geeignet, in denen sie 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. Die Option gilt in jedem Geltungsbereich. Sie können sie daher in Ihrer eigenen ~/.claude/settings.json setzen, um sich für einen Modus zu sperren, den Sie auf einem Produktivserver um 2 Uhr morgens 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. Eine benutzerspezifische Einstellungsdatei gehört dem jeweiligen Benutzer, eine verwaltete Einstellungsdatei dagegen nicht.

Warum der Automatikmodus auf einem VPS eine Isolationsgrenze benötigt

Der Klassifikator prüft jeweils eine einzelne Aktion. Er enthält 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 bei unbeaufsichtigten Ausführungen daher weiterhin zusätzliche Sicherheit und ist nicht auf dieselbe Weise erforderlich wie für --dangerously-skip-permissions.

Für einen entfernten Server bedeutet das: Automatikmodus 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 Hostsystem 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 sonst nichts, was lesenswert wäre. Bauen Sie den Server neu auf, statt ihn zu reparieren. Dafür spricht eine kurzlebige VM, die Sie nach jedem Auftrag löschen. Die zugehörigen Härtungsmaßnahmen, von der Benutzeranlage 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 setzt die root-Regel selbst durch. 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 ist für autonome Arbeit in Containern ein Dev-Container dokumentiert, in dem Claude Code als Benutzer ohne root-Rechte ausgeführt wird. Wenn Sie den Agenten von einem Smartphone oder Laptop über SSH steuern, gilt dieselbe Überlegung für eine dauerhaft laufende Claude-Code-Sitzung in tmux: Während die Sitzung läuft, überwacht niemand die Eingabeaufforderung.

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 erzwingt diese Beschränkungen auch für untergeordnete Prozesse. 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“ geöffnet. Zusätzlich gibt es einen Tab „Dependencies“, der alle fehlenden Abhängigkeiten auflistet. Die Abhängigkeitsprüfung wird beim Start ausgeführt. Starten Sie Claude Code nach der Installation der Pakete daher neu, andernfalls werden sie im Panel weiterhin als fehlend angezeigt.

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 existiert, 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 innerhalb der Sandbox ausgeführt werden. Schränken Sie die Grenze anschließend in den Einstellungen weiter ein:

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

Dieser Block gehört in das .claude/settings.json des Projekts, weil . nur aus den Projekteinstellungen heraus zum Projektverzeichnis 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 zu bearbeitenden Code 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 auf dem Host ohne Einschränkungen 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. Dieses Paket ist zum Zeitpunkt der Erstellung ein Beta-Forschungsvorschau.

Welcher Modus ist für welches Setup geeignet?

Ein einzelnes Repository auf dem eigenen Laptop

Verwenden Sie auto mit ask-Regeln für die Aktionen, die über den Filter hinaus ausgeführt werden dürfen. Sie sitzen an der Tastatur, der Fallback der Klassifizierung kann Sie tatsächlich erreichen, und der Schaden bleibt auf einen von Ihnen kontrollierten Rechner begrenzt. Für diesen Fall wurde der Standard vom 14. August geschrieben.

Ein gemeinsam genutzter VPS

Verwenden Sie auto pro Benutzer. Setzen Sie den Modus jeweils in der eigenen ~/.claude/settings.json-Datei des Benutzers. Auf dem System darf das Konto, unter dem Claude Code läuft, nicht root sein und nicht auf die Arbeit der anderen Benutzer zugreifen können. Aktivieren Sie disableBypassPermissionsMode als "disable" in /etc/claude-code/managed-settings.json. Ergänzen Sie außerdem die Deny-Regeln, die gemeinsam genutzte Pfade schützen. Bei einem gemeinsam genutzten System ist bypassPermissions eindeutig falsch, weil die von diesem Modus angenommene 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 richtige Fehlerverhalten, wenn niemand eine Eingabeaufforderung sehen wird. Der Auto-Modus läuft ebenfalls nicht interaktiv. Wiederholte Blockierungen durch die Klassifizierung brechen jedoch eine -p-Sitzung ab. Ein Job, der auf solche Blockierungen trifft, schlägt daher nach teilweise ausgeführten Arbeiten fehl. Verwenden Sie bypassPermissions nur für einen Container oder eine virtuelle Maschine, die Sie aus einem Image neu erstellen. Verwenden Sie diesen Modus nicht auf einem Host, auf dem außerdem andere wichtige Dienste laufen.

FAQ

Wann wird der Auto-Modus in Claude Code zum Standard?

Ab dem 14. August 2026 gilt er für neue Sitzungen in den Tarifen Pro, Max und Team. Die Dokumentation ergänzt, dass Sie jederzeit zwischen den Modi wechseln können, dass ein von Ihnen festgelegter Standard erhalten bleibt, sofern Sie die einmalige Aufforderung zum Wechsel nicht akzeptieren, und dass ein von Ihrer Organisation verwalteter Standard unverändert bleibt. Laut Ankündigung bleibt der Auto-Modus für Enterprise-Tarife und für Konten, die während der ersten Rollout-Phase die API verwenden, optional. Prüfen Sie in der Statusleiste, in welchem Modus sich eine Sitzung tatsächlich befindet. Im Auto-Modus wird dort ⏵⏵ auto mode on angezeigt.

Sollte ich auf einem VPS den Auto-Modus oder bypassPermissions verwenden?

Verwenden Sie den Auto-Modus zusammen mit einer Isolationsgrenze. Der Klassifizierer prüft jede Aktion, bevor sie ausgeführt wird. Die Dokumentation weist jedoch ausdrücklich darauf hin, dass es sich um eine Kontrolle pro Aktion und nicht um eine Isolationsgrenze handelt. Für einen unbeaufsichtigten Lauf benötigen Sie daher weiterhin einen Container, eine virtuelle Maschine oder ein System, das Sie notfalls neu aufsetzen können. bypassPermissions überspringt die Prüfungen vollständig und ist laut Dokumentation nur für isolierte Umgebungen vorgesehen. Claude Code startet diesen Modus unter Linux nicht als root 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 Auto-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 Geltungsbereichen. Daher können weder eine Benutzereinstellungsdatei noch ein Befehlszeilen-Flag sie überschreiben. disableAutoMode entfernt auto aus dem Zyklus Shift+Tab und weist --permission-mode auto beim Start zurück. disableBypassPermissionsMode funktioniert ebenfalls in jedem Geltungsbereich. 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 Auto-Modus nicht über eine mitgelieferte Einstellungsdatei für sich selbst aktivieren. Die Sitzung startet im Modus default und gibt keine Fehlermeldung 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 Auto-Modus weiterhin nicht verfügbar ist, prüfen Sie die Modellanforderung: Ältere Modelle wie Sonnet 4.5 werden von keinem Anbieter unterstützt.