Claude Code v2.1.277 ändert ein sicherheitsrelevantes Detail der Shell-Ausführung: Ein Ausschlussmuster muss auf jeden Teil eines zusammengesetzten Bash-Befehls passen, bevor der gesamte Befehl von der Sandbox ausgenommen wird. Wenn Ihr Unternehmen Sandbox-Ausnahmen nutzt, prüfen Sie den tatsächlich ausgeführten Client, die wirksame Ausnahmeliste und gemischte Befehlsketten. Das Client-Update liefert diese Korrektur; es beweist nicht, dass anschließend jede Werkzeugausführung isoliert ist.
Was sich mit der Veröffentlichung ändert
Anthropic veröffentlichte Claude Code v2.1.277 am 18. September 2026 um 18:06 UTC. Laut Versionshinweisen wurde ein Fehler behoben, bei dem ein Glob-Muster in sandbox.excludedCommands einen ganzen zusammengesetzten Bash-Befehl von der Sandbox ausnehmen konnte, obwohl nur ein Teil passte. Nun muss jeder Teil passen. Um dieses vom Anbieter beschriebene Verhalten geht es hier – nicht um die Behauptung, dass ein veröffentlichter Angriff Ihre Umgebung kompromittiert habe.
Die Unterscheidung ist wesentlich: Eine Befehlskette ist eine größere Ausführungseinheit als ein einzelner Befehl. Eine eng wirkende Ausnahme kann zu einer breiteren Isolationsausnahme werden, wenn ein passender Bestandteil die Behandlung der gesamten Kette verändert. Die neue Regel begrenzt diese Einstufung: Ein einzelner passender Bestandteil reicht nicht mehr aus, um die komplette Kette auszunehmen.
Die Ankündigung nennt weder den vollständigen Bereich betroffener Versionen noch eine Ausnutzungsrate oder einen CVE-Schweregrad. Wir haben den Veröffentlichungseintrag und die aktuelle Dokumentation geprüft, den Fehler jedoch nicht unabhängig reproduziert und die korrigierte Binärdatei nicht selbst getestet. Die folgenden Abnahmeprüfungen sind technische Empfehlungen, keine berichteten Versuchsergebnisse.
Eine Isolationsausnahme ist keine Ausführungsfreigabe
Anthropics Sandbox-Dokumentation trennt Betriebssystem-Isolation und Berechtigungssystem. Die Sandbox begrenzt Datei- und Netzwerkzugriffe der Shell-Befehle, die sie erfasst. Außerhalb ausgeführte Befehle durchlaufen weiterhin den jeweils einschlägigen Berechtigungsablauf. „Von der Sandbox ausgenommen“ bedeutet daher nicht automatisch „zu jeder Aktion berechtigt“. Das tatsächliche Risiko hängt zusätzlich von der Berechtigungsrichtlinie, der Laufzeitumgebung und den verfügbaren Zugangsdaten ab.
Für Ihr Plattformteam ergeben sich drei getrennte Fragen: Welcher Befehl wird als Ausnahme eingestuft? Ist seine Ausführung erlaubt? Worauf kann der entstehende Prozess tatsächlich zugreifen? Ein erfolgreicher Prompt oder ein grüner Build beantwortet keine dieser Fragen allein. Trennen Sie den Nachweis der Sandbox-Entscheidung vom Nachweis des fachlichen Aufgabenerfolgs.
Auch eine Anweisungsdatei ersetzt diese Korrektur nicht. Dieselbe Version ergänzt einen AGENTS.md-Fallback für Projekte ohne CLAUDE.md; dafür nennen die Versionshinweise Ausnahmen bei Bedrock, Vertex und Foundry. Das ist eine separate Funktion, nicht die hier behandelte Durchsetzungsgrenze. Aus den Verfügbarkeitsgrenzen von AGENTS.md lässt sich die Provider-Abdeckung der Sandbox-Korrektur nicht ableiten.
Verfügbarkeit und Umfang der Einführung
Die offizielle Veröffentlichung enthält Downloads für macOS-, Linux- und Windows-Architekturen. Die Verfügbarkeit einer Client-Binärdatei bedeutet jedoch nicht, dass derselbe Isolationsmechanismus auf jeder Plattform verfügbar ist. Die aktuelle Sandbox-Dokumentation nennt Unterstützung für macOS, Linux und WSL2; natives Windows und WSL1 werden nicht unterstützt. Unter Linux und WSL2 gehören bubblewrap und socat zu den dokumentierten Voraussetzungen.
Erfassen Sie für jeden Ablauf die tatsächlich ausgeführte Datei: Entwicklerterminal, IDE-Integration, unbeaufsichtigter Job und SDK-Host. Auf einem Arbeitsplatz können mehrere Installationen mit unterschiedlichen Update-Zyklen vorhanden sein. Dokumentieren Sie Version und Startpfad je Ablauf, statt anzunehmen, dass ein Terminal-Update sämtliche Agentenaufrufe aktualisiert hat. Ergänzen Sie Installationskanal und Betriebssystem im Nachweispaket.
Die Versionshinweise kündigen für diese Korrektur weder einen separaten Preis noch eine neue Lizenz oder ein deutsches Regionsangebot an. Es handelt sich um eine Änderung des Client-Verhaltens, nicht um den Kauf eines neuen Modells. Bestehende Abonnements, Provider-Verträge und organisatorische Zugangsregeln bleiben eine separate Beschaffungsprüfung. Eine Kostensenkung oder Änderung der Datenresidenz ist durch diese Veröffentlichung nicht belegt.
Warum der Geltungsbereich der Konfiguration entscheidend ist
Die Dokumentation zu Einstellungen und Rangfolge unterscheidet benutzerbezogene, geteilte Projekt-, lokale Projekt- und verwaltete Einstellungen. Eine geprüfte Repository-Datei beweist nicht, welche Konfiguration auf einem Mitarbeitergerät oder Runner letztlich gilt. Prüfen Sie die aufgelösten Einstellungen und ihre Herkunft einschließlich der tatsächlich ausgerollten verwalteten Richtlinie.
Ergänzen Sie nicht einfach breite Ausnahmen, bis die Pipeline wieder grün wird. Bestimmen Sie zunächst den Befehl, der wirklich nicht innerhalb der Sandbox arbeiten kann. Jede beibehaltene Ausnahme benötigt einen Verantwortlichen, einen fachlichen Grund, eine begrenzte Laufzeitumgebung und ein Kriterium für ihre Entfernung. Ein separat kontrollierter Runner kann geeigneter sein, als einem ansonsten isolierten Agenten eine breite Werkzeugkette außerhalb der Sandbox bereitzustellen. Dafür entstehen zusätzliche Wartung, Identitätsverwaltung und Freigabezeiten.
Prüfen Sie außerdem zwei dokumentierte Einstellungen ausdrücklich; sie sind nicht mit dieser Fehlerkorrektur gleichzusetzen. sandbox.allowUnsandboxedCommands steuert, ob fehlgeschlagene Sandbox-Befehle auf eine Ausführung außerhalb zurückfallen dürfen. sandbox.failIfUnavailable kann nicht verfügbare Sandbox-Isolation zum harten Abbruch machen, statt nach einer Warnung ohne Sandbox fortzufahren. Ein deaktivierter Rückfall beweist nicht, dass alle expliziten Ausnahmen entfernt wurden. Prüfen Sie die wirksame Ausnahmeliste unabhängig davon.
Für den Lieferantennachweis bietet das bestehende Kontrollmodell für KI-Lieferanten einen Ausgangspunkt. Die konkrete Abhängigkeit umfasst hier nicht nur einen Modellnamen, sondern auch Client-Version, Berechtigungsrichtlinie, Betriebssystem und Sandbox-Voraussetzungen. Verknüpfen Sie diese Kombination mit Ihrem Release-Bundle, damit sich spätere Vorfälle der tatsächlich ausgeführten Konfiguration zuordnen lassen.
Fünf Abnahmeprüfungen vor der breiteren Einführung
Nutzen Sie eine wegwerfbare Testumgebung mit synthetischen Dateien, harmlosen Markierungsbefehlen und einem kontrollierten lokalen Endpunkt. Kopieren Sie keine Produktionsgeheimnisse und führen Sie keine unberechtigten Netzwerkzugriffe aus. Halten Sie Richtlinie und Testdaten beim Vergleich einer freigegebenen Referenz mit dem Kandidaten konstant. Die folgenden Prüfungen definieren zu erhebende Nachweise; sie behaupten nicht, dass jeder Befehl in sämtlichen Berechtigungsmodi identisch erlaubt oder blockiert wird.
1. Laufenden Client und wirksame Richtlinie erfassen
Halten Sie Version, ausführbaren Pfad, Betriebssystem, Provider-Anbindung und aufgelöste Sandbox-Einstellungen für einen Terminal-Ablauf sowie jeden relevanten automatisierten Startpfad fest. Bestätigen Sie, dass die eingesetzte Version die Korrektur aus v2.1.277 oder eine später vom Anbieter bestätigte Entsprechung enthält. Ein Paketverzeichnis ohne Prüfung des Startpfads kann eine weiterhin aktive alte IDE-Version übersehen.
2. Einen ausgenommenen Befehl allein ausführen
Wählen Sie einen harmlosen Testbefehl, der unter eine bestehende freigegebene Ausnahme fällt. Dokumentieren Sie seine tatsächliche Isolation und Berechtigungsbehandlung. Diese Positivkontrolle bestätigt, dass der Test den Ausnahmepfad erreicht. Wenn der Befehl gar nicht auf das Ausschlussmuster passte, kann das Ergebnis einer späteren gemischten Kette die Änderung nicht nachweisen.
3. Passende und nicht passende Bestandteile verknüpfen
Kombinieren Sie den kontrollierten ausgenommenen Vorgang mit einem harmlosen Vorgang, auf den die Ausnahme nicht passt. Wiederholen Sie den Versuch in umgekehrter Reihenfolge und mit den Verknüpfungsformen Ihrer realen Abläufe. Das Abnahmekriterium: Ein einzelner passender Teil darf nicht die ganze Befehlskette von der Sandbox ausnehmen. Erfassen Sie Freigabeabfragen, Ablehnungen, Ausführungsspuren und Markierungsergebnisse. Aufgabenerfolg allein genügt nicht. Der Versionshinweis beschreibt nicht jeden Parser-Grenzfall; ein einzelner Versuch ist deshalb kein vollständiger Abdeckungsnachweis.
4. Rückfall und nicht verfügbare Sandbox getrennt prüfen
Prüfen Sie auf einem isolierten Test-Runner, wie die freigegebene Richtlinie reagiert, wenn ein Vorgang innerhalb der Sandbox nicht ausführbar ist und wenn notwendige Sandbox-Voraussetzungen fehlen. Verlangt Ihre Organisationsrichtlinie Isolation, muss der Ablauf stoppen, statt seine Ausführungsrechte stillschweigend auszuweiten. Dokumentieren Sie beide Fälle separat: Ein Wiederholungsversuch außerhalb der Sandbox und eine fehlgeschlagene Sandbox-Initialisierung sind unterschiedliche Pfade mit unterschiedlichen Einstellungen.
5. Isolation durch unabhängige Beobachtungen nachweisen
Prüfen Sie die vorgesehene Grenze für weiterhin zu isolierende Befehle mit einer synthetischen Datei außerhalb des erlaubten Schreibbereichs und einem kontrollierten Endpunkt außerhalb der Test-Freigabeliste. Ordnen Sie Zugriffsversuche den Prozess- oder Netzwerkbeobachtungen und dem Zustand harmloser Markierungen zu. Die Aussage des Modells, es habe die Richtlinie eingehalten, ist kein Nachweis. Bewahren Sie außerdem das Ergebnis einer weiterhin erfolgreichen erlaubten Referenzaufgabe auf. So erkennt die Prüfung sowohl Isolationsregressionen als auch unnötige Betriebsstörungen.
Grenzen und Freigabeentscheidung
Die Bash-Sandbox ist kein Container für sämtliche Claude-Code-Funktionen. Laut Anthropic nutzen die eingebauten Werkzeuge Read, Edit und Write direkt das Berechtigungssystem; Computerbedienung unterliegt einer anderen Grenze. Sandbox-Bash-Befehle erben standardmäßig Umgebungsvariablen, sofern konfigurierte Schutzmaßnahmen diese nicht entfernen oder maskieren. Eine korrigierte Ausschlussprüfung beseitigt diese anderen Zugriffspfade nicht.
Ohne konfigurierte Ausnahmen kann der konkrete Musterabgleichsfehler für Ihr Team weniger relevant sein. Die wirksame Konfiguration müssen Sie dennoch prüfen. Nutzen Sie Ausnahmen für Build-Werkzeuge, Authentifizierungshelfer oder Deployment-Abläufe, priorisieren Sie ein kontrolliertes Update und den Test gemischter Ketten. Lässt sich Isolation nicht nachweisen, pausieren Sie den betroffenen autonomen Ablauf oder verlagern Sie den Ausnahmevorgang in eine separat begrenzte Umgebung. Stellen Sie eine bekanntermaßen betroffene Version nicht allein deshalb wieder her, weil die neue Version eine zuvor funktionierende Kette ablehnt.
Die allgemeinere Anleitung zu Kontrollgrenzen für Agenten bleibt relevant. Diese Veröffentlichung verlangt jedoch eine engere Maßnahme: Prüfen Sie, ob die Einheit, der Sie eine Isolationsausnahme gewähren, wirklich der beabsichtigten Einheit entspricht. Daraus folgt eine konkrete Abnahmeentscheidung – kein pauschales Urteil, das gesamte Produkt sei sicher oder unsicher.
Nächster Schritt
Wählen Sie einen Ablauf mit Ausnahmen und verlangen Sie ein kompaktes Nachweispaket: laufende Client-Version, aufgelöste Einstellungen, Testbefehle, unabhängige Grenzbeobachtungen, Ergebnis der betrieblichen Regressionstests und verantwortete Freigabeentscheidung. Wenn Sie diese Prüfung und die umgebenden Laufzeitkontrollen aufbauen möchten, finden Sie Unterstützung in meinen Leistungen für KI-Automatisierung und Implementierung auf der englischsprachigen Leistungsseite.
