Claude Code: Neue Variable hebt die letzte Löschsperre auf
28. Oktober 2026
KI-generiert, redaktionell von 8thsense ausgewählt, geprüft und freigegeben. EU AI Act, Art. 50
Anthropic hat seinem Programmier-Agenten Claude Code eine neue Umgebungsvariable spendiert, deren Name kaum deutlicher warnen könnte: CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS. Ist sie gesetzt, darf der KI-Agent selbst Löschbefehle auf das Home-Verzeichnis oder Systemordner ohne Rückfrage ausführen. Das ist kein neuer Standard, sondern ein bewusstes Opt-in für Spezialfälle. Für Geschäftsführer, in deren Betrieb KI-Agenten auf Laptops oder Servern arbeiten, ist die Neuerung trotzdem ein guter Anlass, eine Grundsatzfrage zu klären: Wer zieht eigentlich die Grenzen, die Software oder das Unternehmen?
Was sich in Claude Code geändert hat
Claude Code kennt mehrere Berechtigungsmodi. Im Standardmodus fragt der Agent vor fast jeder Aktion nach. Im Modus „auto” prüft ein separates Klassifizierungsmodell im Hintergrund, ob ein Befehl riskant ist; laut The Register ist dieser Modus seit August voreingestellt. Ganz oben steht der Modus bypassPermissions, in dem Befehle ohne Prüfung sofort laufen. Bisher gab es selbst dort eine letzte Sperre: Löschbefehle (rm, rmdir) auf sogenannte kritische Pfade, also Wurzelverzeichnis, Home-Ordner, Systemordner wie /usr oder /etc und das eigene Arbeitsverzeichnis, lösten immer eine Rückfrage aus. Genau diese Rückfrage lässt sich ab Version 2.1.311 mit der neuen Variable abschalten (Quelle: code.claude.com). Bekannt gemacht hat das laut The Register eine Anthropic-Mitarbeiterin in den sozialen Medien, im Changelog taucht die Änderung nicht auf (Quelle: theregister.com). Crypto Briefing bestätigt Version und Funktion (Quelle: cryptobriefing.com).
Weniger dramatisch, als die Schlagzeilen klingen
The Register spricht vom Sprung aus dem Flugzeug ohne Fallschirm. Ein Blick in die offizielle Dokumentation relativiert das. Die Variable wirkt nur unter engen Bedingungen:
Sie greift ausschließlich im Modus bypassPermissions, nicht im Standard- oder Auto-Modus.
Sie muss in der Umgebung gesetzt werden, aus der Claude Code gestartet wird. In Konfigurationsdateien wird sie ignoriert.
Ausdrückliche Verbotsregeln (Deny-Regeln) blockieren laut Anthropic in jedem Modus, auch hier.
Zentral verwaltete Einstellungen, die die IT vorgibt, können die Variable wirkungslos machen.
Als Administrator (root) verweigert Claude Code den Bypass-Modus ohnehin, sofern keine erkannte Sandbox vorliegt.
Anthropic selbst warnt in der Doku, die Variable nur in einer isolierten Umgebung zu setzen, „deren Inhalte Sie verlieren können”. Der eigentliche Anwendungsfall sind Wegwerf-Container, in denen ein Agent stundenlang unbeaufsichtigt arbeitet.
Die Sperre war nie eine Sicherheitsgrenze
Der interessanteste Satz steht nicht in der Ankündigung, sondern in der Dokumentation: Die Prüfung auf kritische Pfade könne Befehle übersehen und ersetze keine Kontrolle auf Betriebssystemebene wie eine Sandbox. Zudem gelte sie nur für rm und rmdir, andere freigegebene Befehle könnten kritische Pfade genauso löschen. Mit anderen Worten: Wer sich bisher auf diese eingebaute Sperre verlassen hat, war nie wirklich geschützt. Dass auch Rückfragen allein nicht reichen, zeigt ein Fall aus dem Bugtracker von Claude Code. Im Dezember 2025 schlug der Agent (Version 2.0.60) einen langen Aufräumbefehl vor, der Nutzer bestätigte ihn ohne genaues Lesen, und der Befehl begann, die gesamte Festplatte zu löschen. Laut Meldung gingen Tage bis Wochen an Arbeit verloren (Quelle: github.com). Wer zwanzigmal am Tag auf „Ausführen” klickt, liest beim einundzwanzigsten Mal nicht mehr genau hin.
Warum das Thema auch kleinere Betriebe betrifft
KI-Agenten sind längst nicht mehr nur ein Werkzeug für Softwarefirmen. Sie räumen Dateiablagen auf, pflegen Websites, bauen Auswertungen oder erledigen Workflow-Automation zwischen Buchhaltung, CRM und E-Mail. Oft richtet sie ein einzelner technikaffiner Mitarbeiter ein, auf dem eigenen Laptop, mit Zugriff auf das Firmenlaufwerk und gespeicherten Zugangsdaten. Anthropic beschreibt den Auto-Modus selbst als Kompromiss, der das Risiko senke, aber nicht beseitige (Quelle: claude.com). Die Hersteller verschieben die Verantwortung damit sichtbar zum Anwender. Das ist legitim, denn kein Hersteller kennt die Ablagestruktur einer Pflegevermittlung oder die Kundendatenbank einer Tanzschule. Es heißt aber auch: Die Leitplanken müssen im Unternehmen entstehen, passend zu den eigenen Systemen und Prozessen.
Was das für Unternehmen bedeutet
Die wichtigste Konsequenz ist organisatorisch, nicht technisch. Bevor ein KI-Agent im Betrieb mehr darf als lesen, sollte die Geschäftsführung ein paar Pflichtregeln schriftlich festlegen:
Isolation: Agenten mit weitreichenden Rechten laufen nur in einem Container oder einer virtuellen Maschine, nie direkt auf Arbeitslaptops oder Produktivservern, und nie mit Administratorrechten.
Keine Produktivzugänge: Der Agent bekommt Testdaten und eingeschränkte Zugangsdaten, nicht das Passwort zur Kundendatenbank.
Zentrale Vorgaben: Verbotsregeln und verwaltete Einstellungen legt die zuständige IT fest, nicht jeder Mitarbeiter für sich.
Backups mit Probe: Versionierte Sicherungen, deren Wiederherstellung tatsächlich getestet wurde.
Klare Freigabe: Wer darf den Bypass-Modus überhaupt aktivieren? Die neue Variable gehört auf Firmenrechnern auf die Verbotsliste.
Der Aufwand dafür ist überschaubar: Ein sauber aufgesetzter Container und ein Regelwerk sind eher eine Sache von Tagen als von Monaten. Schwieriger ist meist die Bestandsaufnahme, wo im Betrieb überhaupt schon Agenten laufen und mit welchen Rechten. Ein strukturierter KI-Potenzial-Check kann helfen, diese Schatten-Automatisierung sichtbar zu machen, bevor sie zum Problem wird. Wer klein anfangen will, startet mit einem einzigen Anwendungsfall in einer isolierten Umgebung und erweitert die Rechte erst, wenn die Prozesse dahinter verstanden sind.