Wie gpt-5.6-sol wegen eines Konflikts mit der PowerShell-Variable $HOME beinahe das Home-Verzeichnis eines Nutzers gelöscht hätte

Ich möchte einen schwerwiegenden Safety Incident teilen, den ich gerade bei der Nutzung des neuesten Flaggschiff-Modells gpt-5.6-sol in Codex erlebt habe. Obwohl das Sol-Modell bei Agent-Workflows und Benchmarks zur Tool-Ausführung unglaublich beeindruckende Ergebnisse gezeigt hat, hätte ein schlichtes Fehlen von Shell-Umgebungsisolation beinahe in einer Katastrophe geendet.

Ablauf:
Der Agent versuchte, für eine Debugging-Aufgabe ein temporäres Baseline-Verzeichnis einzurichten. Dazu erzeugte und ausführte der Agent einen PowerShell-Skriptblock, der eine lokale Variable namens $home initialisierte.

$home = Join-Path $env:TEMP 'temporary-build-folder'  
if (Test-Path -LiteralPath $home) { Remove-Item -LiteralPath $home -Recurse -Force }  

Ursache des Bugs:
In PowerShell ist $HOME eine eingebaute automatische Variable (built-in, automatic variable), die direkt auf das Profilverzeichnis des aktuellen Nutzers verweist (z. B. C:\Users<username>).

Das Problem ist, dass PowerShell nicht zwischen Groß- und Kleinschreibung unterscheidet (case-insensitive). Dadurch kollidierte die vom Agenten dynamisch deklarierte kleingeschriebene Variable $home mit dem globalen $HOME-Scope. Als das Skript die Remove-Item-Zeile erreichte, wurde dieser Pfad nicht als temporärer Ordner ausgewertet, sondern als mein tatsächliches Benutzer-Root-Verzeichnis.

In der Folge führte gpt-5.6-sol den folgenden Befehl aus:
Remove-Item -LiteralPath 'C:\Users<username>' -Recurse -Force

Schadenslage:
Glücklicherweise stoppte der Befehl während der Ausführung dank System-Locks auf aktuell aktiven Dateien mit dem Fehler WriteError: Directory is not empty, sodass die schreckliche Katastrophe einer vollständigen Löschung verhindert wurde. Der Agent bemerkte jedoch sofort seinen Fehler, brach die Aufgabe ab (abort) und führte eine Selbstprüfung durch. Dabei stellte sich heraus, dass einige Konfigurationsdateien und Dotfiles (.ssh, .config, .npm) bereits verändert worden oder verschwunden waren.

Implikationen:
gpt-5.6-sol ist bei der Durchführung von long-horizon tasks erstaunlich ausdauernd und leistungsfähig. Wenn wir solchen fortgeschrittenen Reasoning-Modellen jedoch direkten Zugriff auf ein Host-Terminal gewähren, werden die fehlende Unterscheidung von Groß- und Kleinschreibung und die Mechanismen des Variablen-Scopings in Shells wie PowerShell zu einem massiven Risk Vector.

Wenn ihr plant, CLI-Agenten mit der neuen GPT-5.6-Produktfamilie zu entwickeln oder bereitzustellen, sind striktes Sandboxing und robuste Containerisierung ab jetzt keine Option mehr, sondern eine absolute Notwendigkeit.

Hat jemand von euch bei der Nutzung von Sol oder anderen aktuellen Modellen ähnliche Fälle von variable-shadowing oder destruktivem Tool-Nutzungsverhalten erlebt?

Hier ist der Link zu den Screenshots der damaligen Situation: https://gist.github.com/xamong/e98478b333bb9951b175284f744eb0ed

[ggggnews]

Zum Glück hat Codex nicht eigenständig eine Rechteausweitung durchgeführt.

[1yoouoo]

Sollte man schon selbst hinbekommen.