Entwicklung einer sicheren, effektiven Sandbox, die Codex unter Windows möglich macht

Als ich im September 2025 zum Codex-Engineering-Team kam, gab es für Codex unter Windows noch keine Sandbox-Implementierung. Das bedeutete, dass Windows-Nutzende bei der Verwendung der Coding-Agenten von OpenAI zwischen zwei suboptimalen Optionen wählen mussten:

1. Fast jeden Befehl genehmigen, den ein Coding-Agent ausführen wollte (sogar Lesevorgänge), was ineffizient und lästig ist. Einer der Hauptvorteile von Codex ist, dass du nicht die ganze mühsame Arbeit selbst erledigen musst.
2. Den Modus „Voller Zugriff“ aktivieren: Codex darf alle Befehle ohne Genehmigung oder Einschränkungen ausführen, was den Arbeitsaufwand verringert, aber zulasten der Kontrolle geht.

Codex⁠, unser Coding-Agent, läuft auf den Laptops von Entwickler:innen – ob über die CLI, die IDE-Erweiterung oder die Desktop-App. Er verwaltet eine Konversation zwischen einer Person an der Tastatur und einem in der Cloud laufenden Modell, das die Inferenz übernimmt.

Standardmäßig läuft Codex mit den Berechtigungen eines/einer echten Benutzer:in, das heißt, es kann alles tun, was die Person auch tun kann. Das ist leistungsfähig und potenziell gefährlich. Das Coding-Modell kann dem Harness mitteilen, Befehle lokal auszuführen – vom Ausführen von Tests über das Lesen oder Bearbeiten einer Datei bis hin zum Erstellen eines Git-Branch –, daher versucht der Standardmodus von Codex, die richtige Balance zwischen Effektivität und Sicherheit zu finden. Dieser Standardmodus erlaubt Codex, Dateien fast überall zu lesen und Dateien innerhalb deines Workspace zu schreiben (d. h. in dem Verzeichnis, in dem du Codex ausführst), ohne Internetzugang, sofern du ihn nicht ausdrücklich wünschst. Um diese automatische Begrenzung von Dateischreibvorgängen und Netzwerkzugriff innerhalb sicherer Grenzen zu erreichen, braucht Codex eine Sandbox-Umgebung, die diese Grenzen tatsächlich durchsetzt.

Eine Sandbox ist eine eingeschränkte Ausführungsumgebung. Wenn ein:e Entwickler:in Codex verwendet, startet das Betriebssystem des Computers einen Befehl mit reduzierten Berechtigungen, und diese Einschränkungen werden entlang des Prozessbaums weitergegeben. Jeder Codex-Befehl läuft von Anfang an in der Sandbox, und jeder nachgeordnete Prozess bleibt innerhalb derselben Grenze.

Codex benötigt Isolationsfunktionen, die vom Betriebssystem des Computers erzwungen werden, um eine effektive Sandbox zu implementieren. Einige Betriebssysteme bieten Dienstprogramme, die das gut leisten (z. B. Seatbelt auf MacOs, seccomp oder bubblewrap auf Linux); Windows stellt diese Art von Fähigkeit derzeit jedoch nicht standardmäßig bereit.

Um Codex unter Windows genauso sicher und angenehm nutzbar zu machen wie überall sonst, mussten wir unsere eigene Sandbox implementieren.

Windows bietet einige Tools und Primitive für Isolation. Obwohl keines davon unsere Anforderungen ganz erfüllte, haben wir uns eine Reihe potenzieller Lösungen angesehen – nämlich AppContainer, Windows Sandbox und Mandatory Integrity Control Labeling.

AppContainer

• Was: AppContainer ist die native Windows-Sandbox, ein fähigkeitsbasiertes Isolationsmodell für Apps, die im Voraus genau wissen, worauf sie zugreifen müssen.
• Warum: Attraktiv, weil es eine echte Betriebssystemgrenze statt nur Best-Effort-Einschränkungen bietet.
• Warum nicht: Codex ist keine einzelne, eng abgegrenzte App. Es unterstützt offene Entwickler-Workflows: Shells, Git, Python, Paketmanager, Build-Tools und alle anderen Binaries, die der Agent für erforderlich hält. In der Praxis passte AppContainer dadurch nicht zum Problem. Es handelte sich um starke Isolation, aber für eine deutlich engere Klasse von Workloads als „einen Agenten wie einen Entwickler arbeiten zu lassen“.

Windows Sandbox

• Was: Windows Sandbox ist Microsofts leichtgewichtige Einweg-VM. Du erhältst einen frischen Windows-Desktop mit einer starken Isolationsgrenze, und alles, was du darin tust, verschwindet am Ende der Sitzung.
• Warum: Aus offensichtlichen Gründen interessant – deutlich kompatibler mit beliebiger Software als AppContainer und aus Sicherheitssicht ein viel stärkerer Schutzraum.
• Warum nicht: Codex muss direkt mit dem tatsächlichen Checkout, den Tools und der Umgebung der Nutzer:innen arbeiten, nicht in einem separaten Wegwerf-Desktop, der erst eingerichtet und per Host-/Guest-Bridging angebunden werden müsste. Außerdem gab es ein grundlegendes Produktproblem: Windows Sandbox ist in Windows Home-SKUs nicht einmal verfügbar.

Integritätskennzeichnung mit Mandatory Integrity Control (MIC)

• Was: Windows kennt sogenannte „Integritätsstufen“ wie niedrig, mittel und hoch, die bestimmen, wie stark das System Objekten und Prozessen vertraut. Die Grundregel lautet, dass ein Prozess mit niedrigerer Integrität nicht in ein Objekt mit höherer Integritätsstufe schreiben kann, selbst wenn die normale ACL das sonst erlauben würde. Ein Prozess mit niedriger Integrität gilt zum Beispiel als weniger vertrauenswürdig, daher blockiert Windows ihn beim Schreiben in normale Objekte mittlerer Integrität – es sei denn, diese Objekte werden ausdrücklich neu gelabelt, um das zu erlauben.
• Warum: Auf dem Papier wirkte MIC elegant – Codex mit niedriger Integrität ausführen, die beschreibbaren Root-Verzeichnisse auf niedrige Integrität umstellen und Windows überall sonst Schreibschutz erzwingen lassen. Das hätte uns einen Weg ohne Adminrechte mit einem echten Betriebssystemmechanismus dahinter gegeben.
• Warum nicht: Wie ACLs verändern Integritätslabels das echte Host-Dateisystem, und in diesem Fall ist die semantische Änderung besonders weitreichend. Einen Workspace als „niedrige Integrität“ zu markieren bedeutet nicht nur: „Codex kann hier schreiben.“ Es bedeutet, dass Prozesse mit niedriger Integrität allgemein dorthin schreiben können. Auf einem echten Entwicklergerät wird der tatsächliche Checkout des/der Benutzer:in dadurch zu einem Bereich, in den beliebige Low-Integrity-Prozesse des Hosts schreiben können – deutlich riskanter als sorgfältig gezielte ACLs für ein einzelnes Sandbox-Design zu vergeben. Selbst wenn Entwickler-Tools mit mittlerer Integrität weiterhin funktionieren, hat sich das zugrunde liegende Vertrauensmodell des Workspace auf eine Weise verändert, die sich nur schwer eingrenzen und noch schwerer rechtfertigen lässt.

Nachdem wir alle Optionen als ungeeignet bewertet hatten, begannen wir, unsere eigene Lösung zu entwerfen, um Windows-Nutzenden ein gutes Codex-Erlebnis zu bieten.

Unser erster funktionierender Prototyp nutzte eine Kombination aus Windows-Konzepten und -Tools, um die benötigte Isolation umzusetzen. Eines der Ziele war von Anfang an, dies ohne Elevation zu ermöglichen, also ohne dass Codex den/die Benutzer:in allein zum Einrichten oder Ausführen der Sandbox nach Administratorrechten fragen muss. Das bedeutete, vernünftige Grenzen für zwei Dinge zu finden: Dateischreibvorgänge und Netzwerkzugriff.

Wenn wir Dateischreibvorgänge gar nicht begrenzt hätten, hätten wir ein Sicherheitsproblem. Wenn wir sie zu stark begrenzt hätten, würde die Sandbox die Produktivität der Nutzenden beeinträchtigen, weil ständig um Genehmigung gebeten werden müsste. Um dieses Problem zu lösen, stützten wir uns auf zwei wichtige Windows-Bausteine: SIDs und schreibbeschränkte Tokens.

Eine SID oder Security Identifier ist die Identität, an die Windows Berechtigungen knüpft. Jede:r Benutzer:in hat eine SID, Gruppen haben SIDs, und sogar eine einzelne Anmeldesitzung erhält eine eigene SID. Eine aktuell angemeldete Sitzung könnte zum Beispiel eine SID wie S-1-5-5-X-Y haben. Die der lokalen Administratorengruppe zugewiesene SID könnte S-1-5-32-544 sein.

Windows ermöglicht auch die Erstellung synthetischer SIDs, die keiner echten Benutzer:in entsprechen, aber dennoch in ACLs (Access Control Lists) erscheinen können, die definieren, wer bestimmte Dateien oder Verzeichnisse lesen, in sie schreiben oder sie ausführen darf. Dadurch sind SIDs ein nützliches Primitive für unsere Sandbox: Wir können SIDs ausschließlich für die Codex-Sandbox erstellen, ohne etwas anderes auf dem Rechner zu beeinflussen.

Prozesstokens sind Sicherheitsobjekte in Windows, die Identität und Berechtigungen für einen laufenden Prozess definieren. Sie bestimmen, welche Aktionen ein Prozess ausführen kann. Ein schreibbeschränkter Token ist ein spezieller Typ von Prozesstoken, der Windows bei Schreiboperationen eine zusätzliche Zugriffsprüfung durchführen lässt.

Damit ein Schreibvorgang erfolgreich ist, müssen zwei Prüfungen bestanden werden:

1. Die normale Benutzeridentität (der/die „Eigentümer:in“ des Tokens) muss dazu berechtigt sein.
2. Mindestens eine SID in der Liste der eingeschränkten SIDs des Tokens muss ebenfalls Zugriff erhalten.

In der Praxis erlaubten uns diese Prüfungen, mit ACLs genau festzulegen, wo die Sandbox das Dateisystem verändern durfte, was uns die benötigte Granularität bei Schreibvorgängen gab.

Mit SIDs und schreibbeschränkten Tokens funktionierte unsere Unelevated Sandbox so:

1. Das Sandbox-Setup erstellte eine synthetische SID namens sandbox-write.
2. Der sandbox-write-SID wurde Schreib-, Ausführungs- und Löschzugriff auf Folgendes gewährt:
   1. Das aktuelle Arbeitsverzeichnis
   2. Alle zusätzlichen writable_roots, die in config.toml konfiguriert sind.
3. Das Sandbox-Setup verweigerte derselben SID ausdrücklich den Schreibzugriff auf „read-only within writable“-Orte wie:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex startete Befehle unter einem schreibbeschränkten Token, dessen Liste beschränkter SIDs Everyone (Alle), die SID der aktuell angemeldeten Sitzung und die synthetische SID sandbox-write enthält.

Dieser Ablauf löste das Problem der Begrenzung von Dateischreibvorgängen effektiv und wirkte vielversprechend. Jetzt brauchten wir noch eine Lösung, um den Netzwerkzugriff der Sandbox zu begrenzen.

Die Begrenzung des Netzwerkzugriffs ist ein wichtiger Teil der Sandbox; ohne sie könnte bösartiger Code Daten vom Rechner ins Internet exfiltrieren. Da wir eine Elevation-Voraussetzung vermeiden wollten, hatten wir nur begrenzte Möglichkeiten, Netzwerkverkehr zuverlässig zu blockieren. Die Tools, die wir verwenden wollten, etwa die Windows-Firewall, lassen sich in der Regel nicht ohne Administratorrechte einrichten.

Ohne die Windows-Firewall als Option war unser Kontrollspielraum begrenzt. Wir versuchten, die untergeordnete Umgebung für die Arten von netzwerkfähigen Tools, die Entwickler:innen tatsächlich verwenden, fail-closed zu machen, damit Git-Befehle, Paketinstaller usw. in der Sandbox fehlschlagen und der/die Benutzer:in alle internetbezogenen Vorgänge genehmigen muss. Die Idee war, die offensichtlichen Auswege unbrauchbar zu machen: proxyfähigen Traffic an einen toten Endpunkt senden, Git-HTTP(S)-Transport dasselbe tun lassen und Git über SSH sofort scheitern lassen. Zusätzlich stellten wir PATH ein kleines denybin-Verzeichnis voran und ordneten PATHEXT neu, damit Stub-Skripte für SSH und SCP vor den echten Binaries aufgelöst wurden.

Hier sind zum Beispiel einige der konkreten Umgebungsüberschreibungen, die wir verwendet haben, um den Netzwerkzugriff zu begrenzen:

• HTTPS_PROXY=http://127.0.0.1:9
• ALL_PROXY=http://127.0.0.1:9
• GIT_HTTPS_PROXY=http://127.0.0.1:9
• NO_PROXY=localhost,127.0.0.1,::1
• GIT_SSH_COMMAND=cmd /c exit 1

Damit wurde viel normaler Tool-basierter Traffic abgefangen, aber es blieb eine rein beratende Maßnahme. Ein Prozess konnte die Umgebung ignorieren, PATH umgehen oder einfach direkt Sockets öffnen – zu riskant.

Wie bei jeder interessanten Software-Implementierung hatte der erste Prototyp Vor- und Nachteile. Er erledigte die Aufgabe zwar mit nur wenigen Standardfunktionen von Windows, erlaubte sehr explizite und granulare Dateisystem-Schreibvorgänge und lief ohne Elevation – wodurch Nutzende keine übermäßigen Elevation-Prompts akzeptieren oder auf ihrem lokalen Rechner Administrator:innen sein mussten –, hatte aber zu viele Nachteile, um als finales Design infrage zu kommen:

• Geschwindigkeit des Setups: Das Anwenden von Workspace-ACLs kann je nach Topologie des Workspace-Verzeichnisses ressourcenintensiv sein.
• Footprint: Wir haben echte ACLs auf das System des/der Entwickler:in angewendet, auch wenn der Footprint nicht besonders invasiv ist, weil sich alle angewendeten ACLs auf eine eigens erstellte synthetische SID beziehen, die nur von der Sandbox verwendet wird.
• Schwer zu ändernde Semantik: Die Abhängigkeit von ACLs für dateibasierte Einschränkungen bedeutet, dass es aufwändig und komplex ist, die Sandbox-Semantik zu ändern. Während wir auf macOS dynamisch ändern können, wie wir die zur Konfiguration von Seatbelt verwendete .sbpl -Datei erzeugen, könnte die Windows-Sandbox eine langsame und aufwändige Operation zum Anpassen von ACLs erfordern.
• Der Netzwerkschutz ist schwach. Wie bereits erwähnt, war er „beratend“, würde von manchen Programmen mit eigenem Netzwerk-Stack definitiv umgangen werden und war nicht dafür ausgelegt, adversarialem Code standzuhalten.

Die ersten drei Probleme sind einer benutzerdefinierten Sandbox-Implementierung inhärent, die flexibel genug für agentische Abläufe ist. Bei der Unterdrückung des Netzwerkzugriffs war die Lage jedoch anders.

Neben der Tatsache, dass ein bösartiger Agent die umgebungsbasierte Unterdrückung von Netzwerkzugriffen leicht umgehen könnte, würden auch viele gutartige Codepfade und Binaries sie umgehen – wenn sie schlicht und einfach die Proxy-Variablen der Umgebung nicht berücksichtigten oder eigenen Socket-basierten Netzwerkcode implementierten. Dieser Aspekt reichte aus unserer Sicht aus, um in einen besseren Sandbox-Modus zu investieren.

Um eine bessere Unterdrückung des Netzwerkzugriffs zu erreichen, wollten wir die Windows-Firewall verwenden, mit der sich ausgehender Netzwerkverkehr für Benutzer:innen oder Programme blockieren lässt. Leider konnten wir aus einigen Gründen keine funktionale Firewall-Regel erstellen, die nur für die vom Codex-Harness gestarteten Befehle galt:

• Windows erlaubt es nicht, eine Firewall-Regel anhand der zusätzlichen, nicht als Principal verwendeten Identität eines eingeschränkten Tokens abzugleichen. Das bedeutet, dass wir eine Firewall-Regel nicht auf „jeden Token, der unsere synthetische SID in seiner Liste eingeschränkter SIDs enthält“ anwenden konnten.
• Zwar konnten wir eine Firewall-Regel erstellen, die auf ein bestimmtes Binary passt, aber damit ließe sich der Netzwerkzugriff nur für codex.exe selbst begrenzen. Sie würde nicht für Prozesse gelten, die der Agent im Namen des/der Benutzer:in startet, etwa Git- oder Python-Prozesse.
• Auch andere Firewall-Match-Dimensionen hatten die falsche Form. Benutzerbezogene Regeln passten im Unelevated-Design weiterhin auf den/die echte:n Windows-Benutzer:in, nicht nur auf den eingeschränkten untergeordneten Ausführungskontext. Programmpfad-Regeln waren zu grob: Sie konnten codex.exe oder python.exe allgemein blockieren, aber nicht genau diese eine Sandbox-Ausführung von python.exe. Port- oder adressbasierte Regeln waren ebenfalls die falsche Art von Richtlinie. Wir wollten zum Beispiel nicht Port 443 blockieren; wir wollten beliebigen ausgehenden Zugriff für genau diesen eingeschränkten Prozessbaum blockieren.

Um eine Firewall-Regel gezielt auf unsere Sandbox-Befehle anzuwenden, mussten wir sie als separaten Sicherheitsprinzipal ausführen, nicht als den/die „echte:n“ Benutzer:in. Dieser Ansatz führte uns auf einen neuen Weg, bei dem wir unsere „Keine Elevation“-Vorgabe lockerten.

Die nächste Iteration der Sandbox, also unsere aktuelle Implementierung, erfordert beim Setup erhöhte („elevated“) Administratorrechte. Deshalb bezeichne ich sie als „Elevated Sandbox“. An der Grenze, an der Codex einen Befehl auf dem System startet, sieht die Elevated Sandbox ähnlich aus wie die Unelevated Sandbox. Untergeordnete Prozesse laufen weiterhin unter einem eingeschränkten Token – ähnlich einem write_restricted-Token mit derselben Liste eingeschränkter SIDs ([Everyone, Logon, Synthetic]) –, allerdings ist der Sicherheitsprinzipal dieses Tokens nicht mehr der/die tatsächliche Windows-Benutzer:in, sondern einer von zwei lokalen Benutzern, die Codex selbst erstellt:

• CodexSandboxOffline (der, auf den Firewall-Regeln abzielen)
• CodexSandboxOnline (der, auf den Firewall-Regeln nicht abzielen)

Dieses scheinbar kleine Detail hat tatsächlich große Auswirkungen auf die Sandbox, darauf, wer sie verwenden kann, und auf die Komplexität von Setup und Laufzeitausführung.

Visuell ähnelt sie dem Unelevated-Prototyp, allerdings mit Firewall-Regeln und einem dedizierten Windows-Benutzer, der die Befehle tatsächlich ausführt. (Die Einführung dieser neuen Konzepte bedeutet jedoch, dass mehr Setup-Arbeit nötig ist, bevor die Sandbox Befehle ausführen und schützen kann.)

Das Unelevated-Sandbox-Design hatte einen einfachen Setup-Schritt, der aber relativ klein war:

• Bei Bedarf eine synthetische SID erstellen
• ACLs für die synthetische SID sandbox-write anwenden

Die Elevated Sandbox hat jedoch mehr zu tun.

• Eine synthetische SID erstellen, falls sie noch nicht existiert
• Die Online- und Offline-Sandbox-Benutzer erstellen, falls sie noch nicht existieren
• Die Anmeldedaten der neu erstellten Benutzer lokal speichern und mit der Windows Data Protection API (DPAPI) an einem Ort verschlüsseln, den die Sandbox-Benutzer nicht lesen können
• Firewall-Regeln erstellen, die allen ausgehenden Netzwerkzugriff für den Benutzer CodexSandboxOffline blockieren, oder – falls sie bereits existieren – prüfen, ob sie korrekt sind

Im Setup gibt es noch eine zusätzliche Besonderheit. Von der Sandbox von Codex wird erwartet, dass sie Lesezugriff hat, der dem des/der tatsächlichen Windows-Benutzer:in entspricht. In der Unelevated Sandbox, in der die Principal-SID des eingeschränkten Tokens der/die Windows-Benutzer:in war, war das gegeben. Wenn der Principal jedoch ein neuer CodexSandbox-Benutzer wird, ist das nicht automatisch der Fall. Viele relevante Verzeichnisse unter Windows gewähren „Authentifizierten Benutzern“ Lese-/Ausführungsrechte. Ein bekanntes Beispiel ist das Profilverzeichnis des/der Benutzer:in. Standardmäßig können Windows-Benutzer:innen nicht die Profilverzeichnisse anderer Windows-Benutzer:innen lesen, sodass selbst einfache Dateilesevorgänge in vielen Szenarien fehlschlagen würden.

Um dieses Problem zu lösen, haben wir dem Sandbox-Setup-Prozess eine weitere Ebene hinzugefügt – eine zum Gewähren von Lese -ACLs für die Sandbox-Benutzer an Stellen, an denen solche ACLs möglicherweise noch nicht existieren. Zum Beispiel für einige häufig genutzte Windows-Verzeichnisse:

• C:\Users\<echte:r-benutzer:in>
• C:\Windows\
• C:\Program Files\
• C:\Program Files (x86)\
• C:\ProgramData\

Da diese Verzeichnisliste nicht garantiert vollständig ist und das Setzen von ACLs für jedes einzelne Verzeichnis recht aufwändig sein kann, führen wir diese Logik asynchron aus. So muss der für Nutzer:innen blockierende Sandbox-Setup-Schritt nicht warten, bis alle ACLs gesetzt sind.

Wir haben die Setup-Logik in einem eigenen Binary gekapselt, teils um die UAC-Grenze nur dann zu überschreiten, wenn es nötig ist. Der tiefere Grund war jedoch architektonischer Natur: Das Sandbox-Setup hat grundsätzlich eine andere Aufgabe als codex.exe. Wenn die Sandbox-Setup-Logik in einem dedizierten Binary bleibt, kann codex.exe ein normales Harness ohne Elevation bleiben; die nur für Windows nötige Setup-Mechanik bläht codex.exe auf anderen Plattformen nicht auf; länger laufende Setup-Arbeiten werden von der Lebensdauer des Hauptprozesses entkoppelt; und wir haben einen zentralen Ort, um die verschiedenen Setup-Pfade zu handhaben, die die Sandbox braucht.

Aufgrund der Funktionsweise von Windows-Nutzer- und Token-Anmeldegrenzen konnten wir nicht weiterhin einfach einen eingeschränkten Token erstellen und darunter einen Prozess starten, wie es mit der Unelevated Sandbox möglich war. Um Befehle tatsächlich als anderer Windows-Nutzer zu starten, sah unser erster Ansatz folgenden Ablauf vor:

• codex.exe wird als der tatsächliche Windows-Benutzer ausgeführt. Anschließend führt Codex der Reihe nach Folgendes aus:
  • Ruft LogonUserW(...) für den Sandbox-Benutzer auf.
  • Ruft CreateRestrictedToken(...) für diesen Sandbox-Benutzer-Token auf.
  • Ruft mit diesem eingeschränkten Sandbox-Benutzer-Token CreateProcessAsUserW(...) auf, um den endgültigen untergeordneten Prozess zu starten.

In der Praxis funktionierte dieser gewünschte Ablauf jedoch wegen einer Berechtigungsgrenze bei CreateProcessAsUserW(...) nicht. Das bedeutet: codex.exe konnte zwar einen eingeschränkten Token für den Sandbox-Benutzer erstellen, aber damit von der Seite des/der echten Benutzer:in aus nicht zuverlässig einen untergeordneten Prozess starten. Wir brauchten einen Prozess, der bereits als Sandbox-Benutzer läuft – so könnten der Einschränkungsschritt und der endgültige Start auf der Sandbox-Benutzer-Seite der Grenze erfolgen statt auf der Seite des/der echten Benutzer:in.

Diese Anforderung führte zu codex-command-runner.exe, einem neuen Binary, dessen einzige Aufgabe darin besteht, einen eingeschränkten Token zu erzeugen und den angeforderten Befehl zu starten. Statt codex.exe den gesamten Ablauf selbst ausführen zu lassen (echte:r Benutzer:in → Sandbox-Benutzer → eingeschränkter Token → untergeordneter Prozess), haben wir den Ablauf in zwei Teile aufgeteilt:

Teil 1

• codex.exe ruft CreateProcessWithLogonW(...) auf, um codex-command-runner.exe als Sandbox-Benutzer zu starten, zunächst noch ohne Verwendung eines eingeschränkten Token.

Teil 2

• Innerhalb des Runners öffnet OpenProcessToken(GetCurrentProcess(), ...) dessen eigenen Token, der bereits dem Sandbox-Benutzer gehört.
• Der Runner ruft GetTokenInformation(...) auf, um die Sandbox-Logon-SID zu extrahieren, und danach CreateRestrictedToken(...), um den endgültigen eingeschränkten Token zu erzeugen.
• Immer noch innerhalb des Runners ruft er CreateProcessAsUserW(...) mit diesem eingeschränkten Token auf, um den eigentlichen untergeordneten Prozess zu starten.

Albert Einstein sagte: „Man soll die Dinge so einfach wie möglich machen, aber nicht einfacher.“ In diesem Sinne löste unser Design jedes Problem angemessen. Die finale Architektur hat die vier Ebenen, die wir zuvor behandelt haben:

• codex.exe selbst
• codex-windows-sandbox-setup.exe für alle Setup-bezogenen Arbeiten mit erhöhten Rechten
• codex-command-runner.exe zum Ausführen von Befehlen mit eingeschränktem Token
• Den untergeordneten Prozess

Als ich dieses Projekt ursprünglich in Angriff nahm, hatte ich noch kein klares Gefühl dafür, wohin es führen würde. Mein Ansatz war, die Sandboxing-Funktion an der Grenze zwischen Codex und dem Betriebssystem zu instrumentieren. Dieser Ansatz entspricht weitgehend der Art und Weise, wie die Sandbox von Codex unter macOS und Linux umgesetzt ist.

Je mehr ich über die spezifischen Tools lernte, die Windows bereitstellt, und durch Dutzende Entscheidungen beim Abwägen von Sicherheit und Benutzerfreundlichkeit, desto stärker wuchs das System zu seiner heutigen Form heran – mehrere Binaries, eigene Benutzer, Firewall-Regeln, ein Setup-Schritt mit erhöhten Rechten, asynchrone Prozesse und mehr.

Es ist kein besonders einfaches System, aber jede zusätzliche Komplexität wurde aus Notwendigkeit eingeführt, um eine Sandbox zu entwickeln, die sowohl sicher ist als auch den Benutzer:innen so wenig wie möglich im Weg steht.

Bei der Arbeit daran, Codex-Nutzenden unter Windows ein gutes Nutzererlebnis zu bieten, bestand unser Ziel darin, etwas Sicheres zu schaffen, das die Nützlichkeit nicht beeinträchtigt – der ganze Sinn der Nutzung von Codex ist schließlich, dass Agenten Arbeit erledigen können, ohne deine ständige Aufmerksamkeit zu brauchen.

Eine der wichtigsten Erkenntnisse aus diesem Projekt war, dass Windows uns nicht ein einziges Primitive an die Hand gab, das sich nahtlos auf „sicherer autonomer Coding-Agent“ übertragen ließ. Wir haben mehrere Tools und Konzepte kombiniert, um etwas Kohärentes zu schaffen. Manche frühen Ideen erwiesen sich als Sackgassen. Das endgültige Design war ein Hybrid früherer Prototypen, die jeweils einen Teil des Problems lösten.

Die andere Erkenntnis war, dass Sicherheit für einen Coding-Agenten etwas grundsätzlich anderes ist als klassische Anwendungssicherheit. Codex muss für reale Entwickler-Workflows funktionieren. Bei der technischen Umsetzung ging es darum, die Kompatibilität mit agentischen Workloads gegen die tatsächliche Durchsetzung abzuwägen. Dieses Spannungsfeld prägte die Kompromisse im endgültigen Design.

Neugierig, die Codex-Sandbox in Aktion zu sehen? Probiere sie aus⁠.