Claude Code Auto Mode begrenzt Netzwerkzugriff pro Befehl

Im Claude Code Auto Mode muss eine einzelne Abhängigkeitsinstallation nicht mehr den Netzwerkzugriff für den gesamten restlichen Claude Code-Job öffnen. Seit dem 14. September 2026 unterstützt Claude Code 2.1.271 befehlsspezifischen Netzwerkzugriff im abgesicherten Auto Mode. Der für die Installation freigegebene Registry-Host wird damit nach Ende des Befehls wieder geschlossen.

Was sich im Claude Code Auto Mode konkret geändert hat

Claude Code arbeitet hier mit zwei getrennten Sicherheitsebenen. Erst wenn beide auseinandergehalten werden, wird die Neuerung verständlich.

Der Auto Mode entscheidet, ob ein Tool-Aufruf ausgeführt werden darf. Ein separater Klassifikator gleicht die Aktion mit dem erteilten Auftrag ab. Der frühere Leitfaden zum Claude Code Auto Mode erklärt dieses allgemeine Berechtigungsmodell.

Die Sandbox legt fest, worauf ein laufender Shell-Befehl zugreifen darf. Sie begrenzt Schreibzugriffe auf Dateien und leitet Netzwerkverkehr durch einen Proxy, der den Zielhost prüft.

Version 2.1.271 verzahnt diese Ebenen enger. Ein Bash-, PowerShell- oder Monitor-Aufruf kann im abgesicherten Auto Mode nun eine allowed_domains-Liste mitführen. Claude Code prüft den Befehl gemeinsam mit den benötigten Hosts. Diese Hosts werden nur für den jeweiligen Befehl geöffnet; alle anderen weist die Sandbox ab. Der Changelog-Eintrag benennt diesen Geltungsbereich ausdrücklich.

Das Feld in Snake Case ist nicht mit sandbox.network.allowedDomains in settings.json gleichzusetzen.

Vor diesem Release konnte die Freigabe eines neuen Sandbox-Hosts einen weiter reichenden Zugriff erzeugen. Eine manuelle Freigabe gilt für den Rest der aktuellen Sitzung; eine gespeicherte Freigabe kann auch in späteren Sitzungen fortbestehen. Der Auto Mode kann seine Entscheidung zu Host und Port ebenfalls zwischenspeichern. Das neue Feld verändert die Reichweite zur Laufzeit, selbst wenn ein Klassifikatorurteil erneut verwendet wird: Die Netzwerköffnung gehört allein zum aktuellen Befehl.

Betroffen ist nur die im Release genannte Kombination: Auto Mode, Sandbox und Bash, PowerShell oder Monitor. Manuelle Sitzungen, Befehle außerhalb der Sandbox, integrierte Datei-Tools und Jobs ohne Netzwerkzugriff erhalten diese Abgrenzung nicht.

Entscheidend ist der Berechtigungsumfang, nicht ein günstigerer Tarif

Am Preis eines Claude Code-Zugangs ändert sich nichts. Anthropic hat weder eine eigene Gebühr oder SKU noch ein Leistungsresultat für befehlsspezifische Domains angekündigt.

Die entscheidende Rechnung beschreibt den Umfang der Autorisierung, die abgesichert werden muss:

standing grant = approved host × every later command that can reuse it

command-scoped grant = approved host × the reviewed command

Angenommen, eine Abhängigkeitsinstallation benötigt registry.npmjs.org. Bisher war die operative Wahl oft unbefriedigend: Entweder wartete ein unbeaufsichtigter Job auf eine Netzwerkentscheidung, oder die Registry wurde vorab freigegeben und war dadurch für jeden späteren abgesicherten Befehl erreichbar. Jetzt kann der Auto Mode den Host zusammen mit der Installation genehmigen und ihn wieder schließen, bevor Build, Tests, Paketierung und Review weiterlaufen.

Damit verändern sich zwei Kostenblöcke, obwohl die Abonnementrechnung gleich bleibt. Plattformteams müssen weniger dauerhafte Ausnahmen entwerfen und später bereinigen. Sicherheitsprüfer können ein konkretes Paar aus Befehl und Host bewerten, statt den Host als für den gesamten restlichen Job verfügbar zu behandeln.

Der Prüfpfad verursacht weiterhin Rechenkosten. Bei Enterprise-Konten und den in Anthropics Dokumentation zu Berechtigungsmodi genannten nutzungsabhängig abgerechneten Provider-Konten fließen Klassifikatorprüfungen in den Token-Verbrauch ein und verursachen einen zusätzlichen Roundtrip. Das Release enthält keinen Zeitbenchmark; für diesen Beitrag wurde ebenfalls kein Lauf gemessen. Eine seriöse Aussage zu eingesparten Sekunden ist deshalb nicht möglich.

Wer die Funktion morgen einsetzen kann

Solo-Gründer mit einem langen Build-Job

Ein Gründer kann Claude Code die durch die Lockdatei festgelegten Pakete eines SaaS-Repositorys wiederherstellen lassen und anschließend mit Tests und Code-Review fortfahren, ohne die öffentliche Registry für diese späteren Schritte offen zu halten. Der Job läuft weiter, ohne dass aus einem notwendigen Download ein dauerhafter ausgehender Netzwerkzugriff für die gesamte Sitzung wird.

Technische Leitung einer Agentur mit mehreren Kunden-Repositorys

Eine Agentur kann den Paket-Host eines Kunden gezielt an die Installation binden, die ihn benötigt, statt eine weitere Ausnahme auf Projektebene zu speichern. Das verringert den Bereinigungsaufwand bei Berechtigungen und erschwert es einem Befehl in der nächsten Jobphase, Kundencode an einen Host zu senden, der ausschließlich für Abhängigkeiten geöffnet wurde.

Plattform- oder Sicherheitsverantwortliche für unbeaufsichtigte Agenten

Ein Plattformteam kann organisationsweite Sperrregeln und verwaltete Domain-Vorgaben beibehalten, während Routinebefehle innerhalb dieser Richtlinie enger begrenzten Zugriff anfordern. Das Prüfprotokoll lässt sich klarer erklären: Dieser Befehl benötigte diesen Host für diese Aktion. Daraus folgt nicht, dass der Host für alles sicher war, was der Agent anschließend ausgeführt hat.

Build Engineering mit getrennten Installations- und Testphasen

Im Build Engineering lässt sich die Paketwiederherstellung als vernetzte Phase und die Testsuite als Offline-Phase ausführen. Versucht ein kompromittierter Test oder ein unerwartetes Skript nach Abschluss der Installation die Registry aufzurufen, wird die vorherige Befehlsfreigabe nicht übernommen – es sei denn, eine andere dauerhafte Regel erlaubt den Host bereits.

Eine klar begrenzte npm-Installation einrichten

Am deutlichsten zeigt sich die Neuerung in einem Repository mit eingecheckter package-lock.json, dessen Abhängigkeiten über eine einzige bekannte Registry aufgelöst werden. npm dokumentiert npm ci für saubere automatisierte Installationen: Der Befehl setzt eine Lockdatei voraus, bricht bei Abweichungen zwischen Lockdatei und Manifest ab, entfernt ein vorhandenes node_modules und lässt Manifest und Lockdatei unverändert. Die Option --ignore-scripts verhindert während der Installation die Ausführung von Lifecycle-Skripten der Pakete. npm dokumentiert dieses Verhalten.

1. 1

   Claude Code-Version prüfen

   Die Versionsabfrage aus dem Changelog ausführen:

   claude --version

   Erforderlich ist 2.1.271 oder ein neuerer Build, der die Funktion enthält.

2. 2

   Auto Mode in einer Fail-Closed-Sandbox starten

   Für eine einzelne Sitzung wird der Auto Mode mit einer Sandbox kombiniert, die erfolgreich starten muss und einen blockierten Befehl nicht außerhalb der Sicherheitsgrenze wiederholen darf:

   claude --permission-mode auto --settings '{"sandbox":{"enabled":true,"failIfUnavailable":true,"allowUnsandboxedCommands":false}}'

   Dabei kommen die dokumentierten Steuerungen --permission-mode, --settings, failIfUnavailable und allowUnsandboxedCommands zum Einsatz. Unter macOS ist die Sandbox integriert. Linux und WSL2 benötigen bubblewrap und socat; natives Windows wird von der integrierten Sandbox nicht unterstützt. Einrichtung und Plattformgrenzen stehen im Sandbox-Leitfaden.

3. 3

   Der Installation einen eng gefassten Auftrag geben

   Folgenden Auftrag senden und den Registry-Host ersetzen, falls die Lockdatei eine private Registry verwendet:

   Installiere exakt die Abhängigkeiten aus package-lock.json mit npm ci --ignore-scripts. Dieser Befehl darf ausschließlich registry.npmjs.org erreichen. Speichere diesen Host weder in den Projekt- noch in den Benutzereinstellungen. Führe die Testsuite nach Abschluss der Installation als separaten Befehl ohne Netzwerkzugriff aus. Brich ab, falls die Installation einen anderen Host benötigt.

   Das Feld allowed_domains wird nicht manuell eingegeben. Claude Code erstellt den Shell-Tool-Aufruf; der Auto Mode prüft den angeforderten Host zusammen mit diesem Aufruf.

4. 4

   Prüfen, ob der nächste Schritt geschlossen beginnt

   /sandbox öffnen, den Tab „Config“ mit der aufgelösten Konfiguration prüfen und sicherstellen, dass registry.npmjs.org nicht bereits in einer dauerhaften allowedDomains- oder gespeicherten WebFetch-Regel steht. Danach kann der separate Testbefehl laufen. Ein Netzwerkversuch dieses späteren Befehls sollte eine eigene geprüfte Domain-Liste benötigen oder von der bestehenden Richtlinie abgewiesen werden.

Ein häufig übersehenes Detail ist die Lockdatei. Sie kann auf eine private Registry, einen Git-Host oder eine direkte Tarball-URL verweisen. Nur registry.npmjs.org zu nennen, verschiebt diese Abhängigkeiten nicht dorthin. Deshalb sollten die tatsächlich aufgelösten Hosts geprüft und exakt aufgeführt werden; fordert die Lockdatei einen unerwarteten Host an, muss der Befehl stoppen.

Was der befehlsspezifische Netzwerkzugriff nicht löst

Befehlsspezifischer Netzwerkzugriff begrenzt, wann ein Host erreichbar ist. Er weist weder die Vertrauenswürdigkeit des Hosts nach, noch prüft er jede verschlüsselte Anfrage oder macht heruntergeladenen Code sicher.

Der integrierte Proxy von Anthropic filtert nach Hostnamen und untersucht TLS-Inhalte standardmäßig nicht. Innerhalb des freigegebenen Befehls kann ein Prozess jeden erlaubten Pfad auf diesem Host erreichen. Vom Befehl gestartete Kindprozesse teilen sich dieselbe Sandbox-Grenze. Deshalb eignet sich npm ci --ignore-scripts als anschauliches Beispiel: Der Befehl unterbindet Lifecycle-Skripte der Pakete im Installationsschritt, prüft die heruntergeladenen Pakete aber nicht.

Verwaltete Richtlinien stehen weiterhin über der Funktion. strictAllowlist kann alles außerhalb der konfigurierten Liste sperren; allowManagedDomainsOnly kann zulässige Hosts auf verwaltete Einstellungen beschränken. Ausdrückliche Sperrregeln greifen unverändert. Befehlsspezifische Domains umgehen diese Kontrollen nicht.

Auch die erneute Ausführung außerhalb der Sandbox ist ein relevantes Randthema. Claude Code besitzt normalerweise einen Ausweg für Befehle, die in der Sandbox nicht ausgeführt werden können. allowUnsandboxedCommands auf false zu setzen ist wichtig: So wird bei einer fehlgeschlagenen Installation aus der Frage „Welchen Host darf dieser Befehl erreichen?“ nicht unbemerkt die Frage „Darf dieser Befehl außerhalb der Sandbox laufen?“

Was am Montag ansteht

Handlungsbedarf besteht noch in dieser Woche, wenn Claude Code im Auto Mode für Abhängigkeitsaktualisierungen, nächtliche Wartung oder unbeaufsichtigte Build-Jobs läuft und Paket-Registrys derzeit in einer weit gefassten Sandbox-Freigabeliste stehen. Die neue Funktion ist ein guter Anlass zu prüfen, ob sich diese dauerhaften Einträge entfernen lassen.

Abwarten ist sinnvoll, wenn eine Organisation mit einer verwalteten Netzwerkrichtlinie arbeitet, die die Registry bewusst für jeden Befehl freigibt, oder wenn ein äußerer Container beziehungsweise CI-Runner bereits strengere Regeln für den ausgehenden Netzwerkverkehr einzelner Prozesse durchsetzt. Das neue Feld kann die gestaffelte Absicherung dennoch verstärken, ersetzt aber keine bereits betriebene Sicherheitsgrenze.

Nicht betroffen sind Umgebungen, die den Auto Mode nicht mit einer Sandbox kombinieren oder deren Jobs Bash, PowerShell oder Monitor nie für Netzwerkzugriffe aufrufen.

Der konkrete Montagsschritt bleibt klein: Claude Code 2.1.271 oder neuer bestätigen, eine Installation mit Lockdatei auswählen, sie im Auto Mode in einer Fail-Closed-Sandbox starten, nur den erwarteten Registry-Host benennen und anschließend nachweisen, dass der folgende Testbefehl diesen Netzwerkpfad nicht übernehmen kann. Eine dauerhafte Registry-Ausnahme sollte erst entfallen, nachdem diese Prüfung in der eigenen Umgebung bestanden wurde.

Wer auch die nächste Plattformänderung in den betroffenen Workflow übersetzt lesen möchte, kann den Newsletter abonnieren.