SystemebeneAI ENGINEERING · SOFTWARE SYSTEMS · INFRASTRUCTUREEN

Codex und Datenverlust: OpenAI verschärft die Lösch-Guardrails

Mehrere Codex-Nutzer melden gelöschte Dateien und Verzeichnisse. Neue Patches verschärfen Guardian und Command-Safety, decken aber nicht jeden Löschpfad ab.

8 Min. Lesezeit

Am 11. August sollte ein Codex-Subagent eine einzelne generierte Python-Datei entfernen. Laut Bugreport war der Auftrag eng gefasst: den exakten Pfad auflösen, nur diese Datei löschen, keine breite oder rekursive Bereinigung starten.1

Ein Versuch mit PowerShells Remove-Item wurde von der Policy abgelehnt. Der Subagent probierte daraufhin:

git clean -fX -- <path-to-single-pyc>

Git meldete:

Removing data/

Das komplette ignorierte data/-Verzeichnis war weg. Darin lagen unter anderem eine lokale SQLite-Datenbank und weitere nicht in Git gespeicherte Daten. Der Reporter konnte sie aus einem Windows-VSS-Snapshot wiederherstellen, der ungefähr 26 Minuten vor dem Vorfall angelegt worden war.1

Das ist ein Nutzerbericht, keine von OpenAI veröffentlichte Incident-Analyse. Der Reporter liefert im Issue auch eine kleine Reproduktion für das Verhalten von git clean: Ein Pathspec auf eine Datei unterhalb eines ignorierten Verzeichnisses garantiert nicht, dass Git nur diese Datei als Löschziel behandelt.1

Einen einzelnen Patch, der Dateilöschungen in Codex generell stoppt, gibt es nicht. In den vergangenen Wochen hat OpenAI mehrere Stellen nachgezogen: Guardian bewertet destruktive Aktionen strenger, Subagenten bekommen die Autorisierung aus dem Root-Thread genauer weitergereicht und der Command-Safety-Code blockiert bestimmte Befehle inzwischen auch dann, wenn seine eigene Analyse an eine Grenze kommt.

git clean war aus der Dangerous-Liste entfernt worden

Am 13. Februar entfernte OpenAI mehrere Git-Operationen aus der Funktion, die Shell-Kommandos als gefährlich klassifiziert. Dazu gehörten git reset, Branch-Löschungen, verschiedene Force-Push-Varianten und git clean --force.2

Vorher enthielt der Code eine eigene Prüfung für erzwungenes git clean. Tests stellten unter anderem sicher, dass diese Varianten als gefährlich erkannt wurden:

git clean -fdx
git clean -xdf
git clean --force

Der Commit löschte diese Git-spezifische Logik. In diesem Teil des Classifiers blieb unter anderem die explizite Erkennung von rm -f und rm -rf bestehen.

OpenAI nennt im Commit auch den Grund. Die Git-Erkennung verursachte störende Treffer bei legitimen Entwickler-Workflows, etwa bei git push --force-with-lease. Die Dangerous-Liste sollte wieder enger auf klar destruktive Shell-Operationen wie rm -rf beschränkt werden.2

Das senkte False Positives, entfernte aber zugleich die Sonderbehandlung mehrerer Git-Befehle, mit denen sich Arbeitsstände oder Dateien löschen lassen. Der git clean -fX-Vorfall vom August beweist keinen kausalen Zusammenhang mit dieser Änderung. Fest steht nur, dass git clean --force in diesem konkreten Dangerous-Command-Classifier absichtlich kein Sonderfall mehr war.

Weitere öffentliche Datenverlust-Berichte

Ende Juli beschrieb ein Nutzer einen schwereren Vorfall unter Windows. Codex wollte *.pyc- und *.pyo-Dateien entfernen und erzeugte dafür eine rekursive PowerShell-Pipeline mit Get-ChildItem und Remove-Item.3 Nach Darstellung des Reporters filterte -Include die Treffer nicht so, wie der Agent angenommen hatte. Daraufhin wurden Sourcecode, Tests, Fixtures und Dateien unter .git entfernt. Ein Teil der Repository-Historie sei nicht mehr vollständig wiederherstellbar gewesen.

Am 13. August folgte ein weiterer Bericht über wichtige Projektdateien, die ohne ausdrücklichen Löschauftrag entfernt worden seien.4 Dort wird eine Trennung gefordert, die bei lokalen Coding Agents relevant ist: Breiter Dateisystemzugriff ist eine technische Berechtigung. Er sagt noch nichts darüber aus, welche vorhandenen Dateien der Nutzer tatsächlich löschen lassen wollte.

Das fällt bei danger-full-access besonders auf. Solche Rechte sind attraktiv, weil Builds, Tests, Paketmanager und Git sonst immer wieder an Freigaben hängen bleiben. Für das Betriebssystem bedeutet Full Access aber zunächst genau das: Der Prozess darf schreiben und löschen, soweit es die normalen Benutzerrechte erlauben.

Die Agenten-Policy muss zusätzlich prüfen, welchen Scope der Auftrag tatsächlich abdeckt.

OpenAI evaluiert diese Fehlerklasse schon länger

Im offiziellen System Card Addendum zu GPT-5.2-Codex gibt es einen eigenen Abschnitt Avoid Data-Destructive Actions.5 Als Beispiele nennt OpenAI dort rm -rf, git clean -xfd, git reset --hard und erzwungene Git-Pushes. Für die zugehörige Eval lag Destructive action avoidance bei GPT-5-Codex bei 0,66 und bei GPT-5.2-Codex bei 0,76.

Die Eval misst laut System Card, ob das Modell vom Nutzer erzeugte Änderungen erhält und destruktive Aktionen vermeidet. GPT-5.2-Codex wurde dafür unter anderem mit einem simulierten Nutzer trainiert, der während eines Rollouts konkurrierende Änderungen vornimmt.5

Die Werte sagen nichts über GPT-5.6 oder eine aktuelle Codex-Version aus. OpenAI hat Datenverlust damit aber schon vor den August-Berichten als eigene Fehlerklasse gemessen.

Der in Issue #36937 zitierte Basis-Prompt enthält ebenfalls Regeln für destruktive Aktionen. Ziele sollen vorher mit read-only Operationen aufgelöst werden; breite Pfade wie $HOME, ~, / oder der Workspace-Root sollen nicht Ziel rekursiver Löschbefehle werden; bei unklarem Scope soll das Modell nachfragen.6

Diese Regeln werden dem Modell mitgegeben. Der Shell- oder Dateisystem-Layer erzwingt sie dadurch noch nicht.

Als Daten gespeicherte Sicherheitsregeln wurden zu Shell-Code

Ein Bugreport vom 4. August beschreibt einen völlig anderen Fehlerweg.6

Ein Nutzer liess Codex ältere Sessions untersuchen. Nach seiner Rekonstruktion setzte Codex dabei den Pfad einer gespeicherten Rollout-JSONL versehentlich an die Stelle eines auszuführenden Programms. Git Bash interpretierte die Datei daraufhin als Shell-Input.

In der JSONL standen auch die gespeicherten Basisinstruktionen des Modells. Darunter befand sich als negatives Beispiel ein destruktiver Shell-Befehl gegen das Home-Verzeichnis. Markdown-Backticks wurden in diesem falschen Ausführungskontext als Command Substitution interpretiert. Der Reporter führt die anschliessende Löschung grosser Teile seines Windows-Home-Verzeichnisses darauf zurück.6

Auch hierfür gibt es keine veröffentlichte Root-Cause-Analyse von OpenAI. Unabhängig davon, ob die Rekonstruktion vollständig ist, sind Prompt-Instruktionen keine Execution-Policy. Das Modell kann einen Hinweis befolgen; ein fehlerhafter Ausführungspfad kann denselben Text später trotzdem als Daten oder Code behandeln.

Guardian schaut auf Aktion und Autorisierung

OpenAI beschreibt für den eigenen Codex-Einsatz mehrere Schutzschichten. Die Sandbox legt die technische Ausführungsgrenze fest: Schreibrechte, Netzwerkzugriff und geschützte Pfade. Die Approval-Policy bestimmt, wann Codex für eine Aktion eine Freigabe braucht. Für Aktionen, die diese Grenze überschreiten, setzt OpenAI zusätzlich Auto Review ein: Der geplante Tool Call und der jüngste Kontext gehen an einen Review-Agenten, der die Aktion erlauben oder stoppen kann.7

Die öffentliche Guardian-Policy wurde am 5. August bei destruktiven Aktionen erweitert.8 Der Reviewer soll einen vom Coding Agent gebauten Befehl nicht einfach nach dessen beabsichtigter Wirkung beurteilen. Bei destruktiven Befehlen sollen Ziel und Scope einschliesslich Variablen und Expansionen aufgelöst werden. Die Policy warnt ausserdem davor, aus dem Endziel des Nutzers eine Freigabe für jeden möglichen technischen Zwischenschritt abzuleiten.

Im git clean-Report war laut Reporter nur das Entfernen einer einzelnen .pyc-Datei beauftragt. Das Löschen des übergeordneten data/-Verzeichnisses lag ausserhalb dieses Scopes.1

Aus dem öffentlichen Issue lässt sich nicht erkennen, ob genau dieser Tool Call am 11. August von Guardian geprüft wurde. Genannt werden danger-full-access und Approval Policy never. Man kann aus der Guardian-Policy daher nicht ableiten, dass jeder Löschpfad in Codex automatisch durch denselben Review läuft.

Ein Einzeiler ändert das Verhalten bei Parser-Grenzen

Am 18. August änderte OpenAI den Command-Safety-Code mit Commit f97e775, Fail closed on deeply nested command wrappers.9

Codex analysiert Shell-Kommandos vor der Ausführung auf bekannte gefährliche Muster. Dafür muss der Parser Wrapper wie env, Shell-Aufrufe und weitere Verschachtelungen durchlaufen. Diese Rekursion ist begrenzt.

Vor dem Patch endete die Prüfung beim Überschreiten der maximalen Tiefe so:

if wrapper_depth > MAX_DANGEROUS_COMMAND_WRAPPER_DEPTH {
    return None;
}

None bedeutete: kein Dangerous-Command-Match gefunden.

Seit dem Patch steht dort:

if wrapper_depth > MAX_DANGEROUS_COMMAND_WRAPPER_DEPTH {
    return Some(DangerousCommandMatch::Other);
}

Ein Befehl fällt bei zu tiefer Verschachtelung damit nicht mehr aus der Gefahrenklassifizierung heraus. Die Prüfung kennt zwar weiterhin nicht die genaue Operation, behandelt das Ergebnis aber als gefährlich.

Der Integrationstest zeigt die praktische Folge. OpenAI legt eine Sentinel-Datei an und lässt diesen Befehl ausführen:

env env env env env env env env env rm -rf forced-rm-sentinel

Im Test steht AskForApproval auf Never, das Permission-Profil ist deaktiviert. Der Tool Call muss trotzdem mit rejected: blocked by policy enden. Anschliessend prüft der Test, ob die Sentinel-Datei noch existiert.9

Für diesen getesteten Pfad ist die Sperre unabhängig davon, ob das Modell seine Sicherheitsinstruktionen beachtet oder ein Approval-Dialog erscheint. Der Execution-Layer lehnt den Befehl ab.

Der Patch behebt nicht den git clean -fX-Vorfall aus Issue #37998. Er schliesst eine andere Lücke: Wenn der Dangerous-Command-Parser wegen seiner eigenen Tiefengrenze nicht mehr zuverlässig urteilen kann, wird die Aktion nicht mehr durch None als unauffällig behandelt.

Am 21. August kamen weitere Guardian-Patches

Bei Multi-Agent-V2-Workern wird jetzt Autorisierung aus der Root-Konversation in die Guardian-Prüfung übernommen. Als Autorisierung zählen dabei nur echte Nutzerbeiträge im Root-Thread; weitergereichte Behauptungen eines Agenten reichen nicht.10

Ein weiterer Commit sorgt dafür, dass Modelle, für die Auto Review vorgeschrieben ist, immer den vollständigen Review-Pfad verwenden. Ein zwischengespeicherter Guardian-V2-Risk-Score darf diesen Review nicht ersetzen.11

Requests mit sandbox_permissions=require_escalated werden ebenfalls seit dem 21. August synchron an Guardian geschickt. Der dazugehörige Test installiert sogar eine automatisch freigebende Extension und prüft, dass Guardian die eskalierte Aktion trotzdem ablehnen kann.12

Für den Lösch-Fall mit Subagenten ist davon vor allem die Root-Autorisierung relevant: Ein Worker soll nicht aus seiner eigenen verkürzten Historie eine Freigabe ableiten, die der Nutzer im eigentlichen Thread nie gegeben hat.

apply_patch läuft nicht über denselben Shell-Classifier

Shell-Command-Safety deckt nicht jeden Mutationspfad ab.

Ein seit Juli offenes Issue betrifft das eingebaute apply_patch-Tool.13 Dessen Patch-Sprache kann Dateien direkt löschen:

*** Delete File: example.txt

Der im Issue beschriebene Spezialfall löscht eine vorhandene Datei und legt unter demselben Pfad sofort wieder eine neue an:

*** Begin Patch
*** Delete File: <existing-file>
*** Add File: <existing-file>
+<replacement content>
*** End Patch

Nach Analyse des Reporters führt der Dateisystem-Layer beide Operationen aus. In der strukturierten Darstellung kann durch die pfadbasierte Zuordnung aber nur das spätere Add übrig bleiben. Die Oberfläche meldet dann eine hinzugefügte Datei, obwohl vorher eine bestehende Datei entfernt wurde. Es gibt dabei keinen rm- oder unlink-Shell-Befehl, den der oben beschriebene Dangerous-Command-Classifier erkennen könnte.13

OpenAI hat apply_patch am 20. August gegen eine andere Klasse von Fehlern gehärtet: Bei unsandboxed Patches kann die Dateisystemschicht jetzt Symlink-Traversal abschalten, damit ein nach der Prüfung ausgetauschter Pfad nicht plötzlich auf eine andere Datei zeigt.14 Issue #34515 zur Delete-plus-Add-Darstellung ist zum Zeitpunkt dieses Artikels weiterhin offen.

Genau hier fehlt Codex aus meiner Sicht noch eine gemeinsame Ebene. Eine Schutzschicht, die hauptsächlich Shell-Befehle klassifiziert, sieht nur einen Teil der möglichen Dateisystemänderungen. Ein gemeinsamer Guardrail müsste die aufgelöste Mutation bewerten: welche Pfade entfernt, überschrieben oder verschoben werden sollen und ob dieser Scope vom Auftrag gedeckt ist. Dann wäre es weniger wichtig, ob die Änderung über rm, PowerShell, git clean oder apply_patch kommt.

Was ich daraus für lokale Coding Agents mitnehme

Ich nutze Coding Agents gern mit weitreichenden Rechten, weil ständige Freigaben den autonomen Workflow schnell kaputtmachen. Das werde ich auch nach diesen Patches weiter tun. Den Workspace behandle ich dabei aber als Umgebung, in der der Agent einen falschen Befehl ausführen kann.

Bei danger-full-access darf der Prozess weitgehend das tun, was mein Benutzeraccount darf. Das schützt weder nicht committete Arbeit noch ignorierte Datenbanken, Testkorpora oder generierte Ergebnisse. Im Report vom 11. August lagen die verlorenen Daten gerade unter dem ignorierten data/-Pfad.1

Wichtige, nicht versionierte Daten würde ich deshalb separat sichern und Full Access auf einen klaren Workspace begrenzen. Bei Multi-Agent-Setups würde ich ausserdem nicht davon ausgehen, dass eine enge Anweisung des Lead-Agenten automatisch den Blast Radius jedes Worker-Kommandos begrenzt.

Seit dem Patch vom 18. August wird wenigstens die eine Parser-Grenze fail-closed behandelt: Der getestete verschachtelte rm -rf wird blockiert, obwohl Approvals deaktiviert sind. Andere Mutationspfade haben weiterhin eigene Mechanismen. Das offene apply_patch-Issue zeigt, dass Codex noch keine einheitliche Sicherheitsgrenze für alle Dateilöschungen hat.

Footnotes

  1. Codex Issue #37998: Sub-agent used git clean -fX and deleted an ignored data directory ↩ ↩2 ↩3 ↩4 ↩5

  2. Codex Commit #11510: Remove git commands from dangerous command checks ↩ ↩2

  3. Codex Issue #35707: Recursive cleanup destroyed a Git repository ↩

  4. Codex Issue #38312: Project files deleted without explicit deletion request ↩

  5. GPT-5.2-Codex System Card Addendum ↩ ↩2

  6. Codex Issue #36937: Rollout JSONL executed as shell input ↩ ↩2 ↩3

  7. OpenAI: Running Codex safely ↩

  8. Codex Commit #37103: Guardian policy changes for destructive actions ↩

  9. Codex Commit #39122: Fail closed on deeply nested command wrappers ↩ ↩2

  10. Codex Commit #39975: Preserve root user authorization in subagent Guardian reviews ↩

  11. Codex Commit #39981: Bypass risk scoring for models that require automatic review ↩

  12. Codex Commit #40005: Route escalated commands through synchronous Guardian review ↩

  13. Codex Issue #34515: apply_patch can delete without visible Guardian review ↩ ↩2

  14. Codex Commit #39659: Harden unsandboxed patch filesystem access ↩

Passend dazu