Wie OpenAI eine Codex-Sandbox für Windows baute, ohne ein natives OS-Primitiv

Die Lücke, die mit einem fehlenden OS-Feature begann

Als David Wiesen im September 2025 zum Codex-Engineering-Team stieß, gab es für den Coding-Agenten unter Windows überhaupt keine Sandbox. Windows-Nutzer hatten dadurch nur zwei schlechte Optionen: fast jeden Befehl einzeln freigeben, den der Agent ausführen wollte, einschließlich Lesezugriffe, oder den Full-Access-Modus aktivieren und Codex ohne jede Kontrolle alles ausführen lassen.

Der Grund war banal, aber entscheidend. Der Standardmodus von Codex – lesen fast überall, schreiben nur innerhalb des Workspace, kein Internetzugriff außer auf Anfrage – setzt voraus, dass das Betriebssystem diese Grenzen selbst durchsetzt. macOS hat Seatbelt, Linux hat seccomp und bubblewrap. Windows liefert von Haus aus nichts Vergleichbares.

Die Aufgabe des Teams bestand also nicht darin, eine bestehende Sandbox zu konfigurieren, sondern eine aus unzusammenhängenden Windows-Bausteinen selbst zu konstruieren. Das erklärt, warum das fertige System so aufwendig ausfällt.

Drei Standard-Windows-Optionen, drei Sackgassen

Das Team prüfte AppContainer, Windows Sandbox und die Kennzeichnung über Mandatory Integrity Control – und verwarf alle drei aus jeweils eigenen, konkreten Gründen.

AppContainer bietet eine echte OS-Grenze, ist aber für Apps gedacht, die ihre Fähigkeiten von vornherein deklarieren – die falsche Form für einen Agenten, der Shells, Git, Python, Paketmanager und beliebige weitere Binärdateien steuert, je nach Bedarf. Windows Sandbox ist eine stärkere Box, eine wegwerfbare VM, aber Codex muss mit dem echten Checkout und den echten Tools des Nutzers arbeiten, nicht mit einem Wegwerf-Desktop; zudem ist sie auf Windows-Home-SKUs gar nicht verfügbar – ein Ausschlussgrund auf Produktebene.

Die MIC-Integritätskennzeichnung wirkte elegant – Codex mit niedriger Integrität laufen lassen und beschreibbare Wurzelverzeichnisse entsprechend markieren –, doch ein als niedrig eingestuftes Workspace-Verzeichnis bedeutet, dass jeder Prozess mit niedriger Integrität auf dem Host dort schreiben kann. Der reale Checkout des Entwicklers würde so zu einer systemweiten Ablage. Diese semantische Verschiebung war zu weitreichend, um sie zu rechtfertigen.

Der nicht privilegierte Prototyp und die eine Sache, die er nicht konnte

Das erste funktionierende Design verzichtete darauf, Nutzer um Administratorrechte zu bitten. Es stützte sich auf zwei Windows-Primitive: synthetische Security Identifiers und schreibeingeschränkte Tokens. Eine synthetische SID namens sandbox-write erhielt Schreib-, Ausführungs- und Löschrechte für das Arbeitsverzeichnis und alle konfigurierten writable_roots und wurde explizit vom Schreibzugriff auf sensible Pfade wie .git, .codex und .agents ausgeschlossen. Befehle liefen unter einem schreibeingeschränkten Token, dessen Liste eingeschränkter SIDs Everyone, die Session-SID und sandbox-write umfasste.

Schreibzugriffe waren damit sauber gelöst. Der Netzwerkzugriff nicht. Ohne Administratorrechte war die Windows-Firewall keine Option, sodass dem Team nur Umgebungsvariablen-Überschreibungen blieben – Proxys auf einen toten Endpunkt zeigen zu lassen (HTTPS_PROXY=http://127.0.0.1:9), GIT_SSH_COMMAND zum Abbruch mit Exit-Code 1 zu zwingen und ein denybin-Verzeichnis vorne an PATH anzuhängen.

Der Autor macht kein Geheimnis aus der Grenze dieses Ansatzes.

Das fing einen Großteil des normalen, tool-getriebenen Verkehrs ab, blieb aber letztlich nur eine Empfehlung. Ein Prozess konnte die Umgebungsvariablen ignorieren, PATH umgehen oder einfach direkt Sockets öffnen – zu riskant.Montana Labs

Entscheidend war: Selbst wohlverhaltene Binärdateien mit eigenem Netzwerk-Stack würden daran vorbeikommen. Genau diese Schwachstelle – nicht der Aufwand für die ACL-Einrichtung oder die Schwierigkeit, Semantiken zu ändern – brachte das Team dazu, die Beschränkung auf fehlende Rechteerhöhung aufzugeben.

Warum echte Netzwerkdurchsetzung vier Binärdateien und zwei fingierte Benutzer erforderte

Die Windows-Firewall konnte ausgehenden Verkehr blockieren – aber nur, wenn die Sandbox-Prozesse als eigenständiges Prinzipal liefen. Firewall-Regeln können nicht auf die synthetische SID eines eingeschränkten Tokens matchen, können einen sandboxed Aufruf von python.exe nicht von einem anderen unterscheiden, und einen Port wie 443 zu blockieren, war ohnehin die falsche Strategie – das Ziel war, beliebige ausgehende Zugriffe für einen bestimmten Prozessbaum zu blockieren, nicht generell.

Die Lösung bestand darin, zwei lokale Benutzer anzulegen, CodexSandboxOffline (Ziel der Firewall-Regeln) und CodexSandboxOnline (nicht betroffen), deren Zugangsdaten per DPAPI verschlüsselt gespeichert werden, sodass die Sandbox-Benutzer selbst sie nicht lesen können. Da diese Benutzer nicht der echte Windows-Nutzer sind, verloren sie den Lesezugriff auf Verzeichnisse, die normalerweise mit Authenticated Users geteilt werden. Der Einrichtungsschritt vergibt daher zusätzlich Lese-ACLs auf Pfade wie das Benutzerprofil, C:\Windows und Program Files – asynchronisiert ausgeführt, weil es langsam ist.

Prozesse unter einem anderen Benutzer zu starten, stieß an der API CreateProcessAsUserW auf eine Rechte-Hürde: Von der Seite des echten Nutzers aus ließ sich kein Kind-Prozess mit eingeschränktem Token zuverlässig starten. Als Workaround wurde codex-command-runner.exe eingeführt: codex.exe startet den Runner als Sandbox-Benutzer über CreateProcessWithLogonW, und der Runner – bereits auf der Seite des Sandbox-Benutzers – erzeugt das eingeschränkte Token und startet den eigentlichen Kind-Prozess. Zusammen mit einer eigenen, privilegierten Setup-Binärdatei ergeben sich damit vier Ebenen: codex.exe, die Setup-Binärdatei, der Command-Runner und der Kind-Prozess.

Die Konsequenz: Plattformparität für Codex ging auf Kosten eines administrativen Einrichtungsschritts

Das zentrale Ergebnis ist eng und konkret: Damit sich Codex unter Windows genauso verhält wie unter macOS und Linux, musste OpenAI zur Einrichtungszeit erhöhte Administratorrechte verlangen – genau die Einschränkung, die das Team mit seinem ersten Prototypen zu vermeiden versuchte. Eine Netzwerksperre, die auch gegenüber feindlichem Code standhält, erwies sich als nicht verhandelbar, und unter Windows bedeutete das Firewall-Regeln, was wiederum ein eigenes Prinzipal erforderte, was wiederum Rechteerhöhung bedeutete.

Für Teams, die Agenten bauen, die lokale Befehle ausführen, liegt die konkrete Lehre darin, dass die Durchsetzungsgrenze die Architektur bestimmt – nicht umgekehrt. Ein bequemes, nicht privilegiertes Design war für Schreibzugriffe technisch machbar und scheiterte an der einen Anforderung – dem Blockieren von Datenabfluss –, die sich nicht bloß empfehlend umsetzen ließ. Alles Nachgelagerte, von den per DPAPI gespeicherten Zugangsdaten bis zur Command-Runner-Binärdatei, existiert, um genau diese eine harte Anforderung zu erfüllen.

Wie Wiesen es formuliert, bot Windows kein Primitiv, das dem Konzept eines „sicheren autonomen Coding-Agenten“ entspricht – also baute das Team eines selbst zusammen. Das Ergebnis ist zugegebenermaßen nicht einfach, doch jedes einzelne Element – die synthetische SID, die zwei Benutzer, die asynchron vergebenen Lese-ACLs, der zweigeteilte Startprozess – lässt sich auf ein konkretes Scheitern eines einfacheren Ansatzes zurückführen.