Een veilige, effectieve sandbox bouwen om Codex op Windows mogelijk te maken

Toen ik in september 2025 bij het Codex-engineeringteam kwam, had Codex voor Windows nog geen sandboximplementatie, wat betekende dat Windows-gebruikers bij het gebruik van de programmeeragents van OpenAI moesten kiezen tussen twee ondermaatse opties:

1. Bijna elke opdracht moeten goedkeuren (zelfs leesacties) die een programmeeragent wil uitvoeren: inefficiënt en behoorlijk irritant. Een groot voordeel van het gebruik van Codex is dat je niet al het vervelende werk zelf hoeft te doen.
2. Full Access mode inschakelen: Codex alle opdrachten laten uitvoeren zonder goedkeuring of beperkingen. Dat werkt soepeler, maar gaat wel ten koste van toezicht.

Codex⁠, onze programmeeragent, draait op laptops van ontwikkelaars, of dat nu via de CLI, de IDE-extensie of de desktop-app is. Het beheert een gesprek tussen een mens achter een toetsenbord en een model dat in de cloud draait om inferentie af te handelen.

Codex draait standaard met de rechten van een echte gebruiker, wat betekent dat het alles kan doen wat de gebruiker kan doen. Dat is krachtig en potentieel gevaarlijk. Het programmeermodel kan de harness vragen om lokaal opdrachten uit te voeren, van tests draaien tot een bestand lezen of bewerken tot een Git-branch maken, dus probeert de standaardmodus van Codex de juiste balans te vinden tussen effectiviteit en veiligheid. Deze standaardmodus laat Codex bestanden bijna overal lezen en bestanden binnen je werkruimte schrijven (d.w.z. de map waarin je Codex uitvoert), zonder internettoegang tenzij je aangeeft dat je dat wilt. Om deze automatische beperking van het schrijven van bestanden en toegang tot het netwerk binnen veilige grenzen te bereiken, heeft Codex een sandboxomgeving nodig die deze beperkingen ook echt afdwingt.

Een sandbox is een beperkte uitvoeringsomgeving. Wanneer een ontwikkelaar Codex gebruikt, start het besturingssysteem van diens computer een opdracht met verminderde rechten, en die beperkingen gelden vervolgens ook voor alle onderliggende processen. Elke Codex-opdracht wordt vanaf het begin in een sandbox uitgevoerd, en elk onderliggend proces blijft binnen dezelfde grens.

Codex heeft isolatiefuncties nodig die door het besturingssysteem van de computer worden afgedwongen om een effectieve sandbox te implementeren. Sommige besturingssystemen bieden hulpmiddelen die dit goed doen (bijvoorbeeld Seatbelt op MacOs, seccomp of bubblewrap op Linux); Windows biedt dit type mogelijkheid momenteel echter niet standaard.

Om Codex op Windows net zo veilig en prettig in gebruik te maken als het elders al is, moesten we onze eigen sandbox implementeren.

Windows biedt verschillende tools en mechanismen voor isolatie. Hoewel geen daarvan volledig aan onze eisen voldeed, hebben we meerdere mogelijke oplossingen onderzocht, waaronder AppContainer, Windows Sandbox en Mandatory Integrity Control-labels.

AppContainer

• Wat: AppContainer is de native sandbox van Windows, een op mogelijkheden gebaseerd isolatiemodel voor apps die vooraf precies weten waartoe ze toegang nodig hebben.
• Waarom: Aantrekkelijk omdat het een echte scheiding op OS-niveau biedt in plaats van beperkingen die alleen op basis van best effort worden afgedwongen.
• Waarom niet: Codex is niet één app met een strikt afgebakende scope. Het stuurt flexibele ontwikkelaarsworkflows aan: shells, Git, Python, package managers, buildtools en alle andere uitvoerbare bestanden die de agent nodig acht. In de praktijk paste AppContainer daardoor niet goed bij het probleem. Het bood sterke isolatie, maar voor een veel beperktere categorie workloads dan "een agent laten werken als een ontwikkelaar."

Windows Sandbox

• Wat: Windows Sandbox is de tijdelijke, lichtgewicht VM van Microsoft. Je krijgt een schone Windows-desktop met een sterke isolatiegrens, en alles wat je daarin doet verdwijnt zodra de sessie eindigt.
• Waarom: Om voor de hand liggende redenen interessant: veel compatibeler met uiteenlopende software dan AppContainer, en vanuit beveiligingsoogpunt ook een veel sterkere isolatiegrens.
• Waarom niet: Codex moet direct kunnen handelen op de echte checkout, tools en omgeving van de gebruiker, niet binnen een aparte tijdelijke desktop die setup en host-/guest-koppeling zou vereisen. Het had bovendien een fundamenteel productprobleem: Windows Sandbox is niet eens beschikbaar in Windows Home-SKU's.

Mandatory Integrity Control (MIC)-integriteitslabeling

• Wat: Windows kent zogeheten 'integriteitsniveaus', zoals laag, gemiddeld en hoog, die bepalen hoeveel vertrouwen het systeem heeft in objecten en processen. De basisregel is dat een proces met een lager integriteitsniveau niet naar een object met een hoger integriteitsniveau kan schrijven, zelfs als de normale ACL dit anders wel zou toestaan. Een proces met laag integriteitsniveau wordt bijvoorbeeld als minder vertrouwd behandeld, waardoor Windows voorkomt dat het naar normale objecten met gemiddeld integriteitsniveau schrijft, tenzij die objecten expliciet opnieuw zijn gelabeld om dit toe te staan.
• Waarom: MIC zag er op papier elegant uit: Codex op lage integriteit draaien, de schrijfbare roots opnieuw labelen als lage integriteit en Windows overal elders geen schrijftoegang laten afdwingen. Dat had ons een pad zonder beheerdersrechten opgeleverd, met een echt OS-mechanisme erachter.
• Waarom niet: Net als ACL's wijzigen integriteitslabels het echte bestandssysteem van de host, en in dit geval is de semantische wijziging bijzonder ingrijpend. Een werkruimte markeren als werkruimte met lage integriteit betekent niet alleen 'Codex kan hier schrijven.' Dit betekent dat processen met lage integriteit in het algemeen daar kunnen schrijven. Op een echte ontwikkelaarsmachine maakt dat van de daadwerkelijke checkout van de gebruiker een sink met lage integriteit voor de host, wat veel riskanter is dan het toekennen van zorgvuldig afgebakende ACL’s aan één sandboxontwerp. Zelfs als ontwikkelaarstools met gemiddeld integriteitsniveau blijven werken, is het onderliggende vertrouwensmodel van de werkruimte veranderd op een manier die moeilijk te beheersen en nog moeilijker te rechtvaardigen is.

Nadat we alle opties als ongeschikt hadden beoordeeld, begonnen we onze eigen oplossing te ontwerpen om Windows-gebruikers een goede Codex-ervaring te bieden.

Ons eerste werkende prototype gebruikte een combinatie van Windows-concepten en -hulpprogramma's om de isolatie te implementeren die we nodig hadden. Vanaf het begin was één doel om dit te laten werken zonder verhoging van rechten te vereisen, wat betekent dat Codex de gebruiker geen prompt voor beheerdersrechten zou hoeven te tonen alleen maar om de sandbox in te stellen of uit te voeren. Dat betekende dat we moesten uitzoeken hoe we redelijke beperkingen konden stellen aan twee dingen: schrijfbewerkingen naar bestanden en netwerktoegang.

Als we bestandsschrijfacties helemaal niet zouden beperken, zouden we een veiligheidsprobleem hebben. Als we ze te veel zouden beperken, zou de sandbox de productiviteit van gebruikers schaden doordat constant om goedkeuring gevraagd moet worden. Om dit probleem op te lossen, vertrouwden we op twee belangrijke Windows-bouwstenen: SID’s en tokens met schrijfbeperking.

Een SID, of beveiligings-id, is de identiteit die Windows aan machtigingen koppelt. Elke gebruiker heeft een SID, groepen hebben SID’s en zelfs één enkele aanmeldsessie krijgt een eigen SID. Bijvoorbeeld, een momenteel aangemelde sessie kan een SID hebben zoals S-1-5-5-X-Y. De SID die is toegewezen aan de lokale groep Administrators kan S-1-5-32-544 zijn.

Windows laat je ook synthetische SID’s maken die niet overeenkomen met een echte gebruiker maar toch in ACL’s (access control lists) kunnen voorkomen, die bepalen wie specifieke bestanden of mappen mag lezen/schrijven/uitvoeren. Dat maakt SID’s een nuttige primitieve bouwsteen voor onze sandbox: we kunnen SID’s maken die uitsluitend voor de Codex-sandbox worden gebruikt, zonder iets anders op de machine te verstoren.

Tokens zijn beveiligingsobjecten in Windows die de identiteit en bevoegdheden voor een actief proces definiëren. Ze bepalen welke acties een proces kan uitvoeren. Een token met schrijfbeperkingen is een bepaald type procestoken dat ervoor zorgt dat Windows bij schrijfbewerkingen een extra toegangscontrole uitvoert.

Om een schrijfactie te laten slagen, moeten twee controles slagen:

1. De normale gebruikersidentiteit (de 'eigenaar' van het token) moet dit mogen doen
2. Minstens één SID in de lijst met beperkte SID’s van het token moet ook toegang hebben gekregen

In de praktijk lieten deze controles ons ACL’s gebruiken om exact te definiëren waar de sandbox het bestandssysteem mocht wijzigen, wat ons de granulariteit gaf die we rond schrijfbewerkingen nodig hadden.

Met SID’s en tokens met schrijfbeperking werkte onze unelevated sandbox als volgt:

1. De setup van de sandbox maakte een synthetische SID met de naam sandbox-write.
2. Aan de sandbox-write-SID is schrijf-, uitvoer- en verwijdertoegang verleend
   1. De huidige werkmap
   2. Eventuele aanvullende writable_roots die zijn geconfigureerd in config.toml.
3. De sandboxsetup ontzegde diezelfde SID expliciet schrijftoegang tot locaties die 'alleen-lezen binnen schrijfbaar' zijn, zoals:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex startte opdrachten onder een token met schrijfbeperking waarvan de beperkte SID-lijst Everyone, de SID van de huidige aangemelde sessie en de synthetische SID sandbox-write bevat.

Deze flow loste het beperken van schrijfacties effectief op en leek veelbelovend. Nu hadden we nog een oplossing nodig om de netwerktoegang van de sandbox te beperken.

Het beperken van netwerktoegang is een belangrijk onderdeel van de sandbox; zonder die beperking zou kwaadaardige code gegevens van de machine naar het internet kunnen exfiltreren. Omdat we een vereiste voor elevation wilden vermijden, hadden we beperkte mogelijkheden om netwerkverkeer sterk te blokkeren. De tools die we wilden gebruiken, zoals Windows Firewall, konden over het algemeen niet zonder beheerdersrechten worden geïnstalleerd.

Zonder Windows Firewall als optie waren we beperkt in wat we konden beheren. We hebben geprobeerd de child-omgeving fail-closed, dus standaard dicht, te maken voor de soorten tools met netwerktoegang die ontwikkelaars daadwerkelijk gebruiken, zodat Git-commando’s, pakketinstallatieprogramma’s, enzovoort, zouden mislukken in de sandbox en de gebruiker alle bewerkingen die met internet communiceren zou moeten goedkeuren. Het idee was om de voor de hand liggende uitwegen onbruikbaar te maken: proxybewust verkeer naar een dode endpoint sturen, Git’s HTTP(S)-transport hetzelfde laten doen en Git via SSH onmiddellijk laten mislukken. Daarnaast hebben we een kleine map denybin vooraan toegevoegd aan PATH en PATHEXT opnieuw geordend, zodat stub-SSH- en SCP-scripts eerder zouden worden gevonden dan de echte binaire bestanden.

Hier zijn bijvoorbeeld enkele van de specifieke omgevingsoverschrijvingen die we gebruikten om netwerktoegang te beperken:

• 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=lokale host,127.0.0.1,::1
• GIT_SSH_COMMAND=cmd /c exit 1

Daarmee werd veel normaal, toolgestuurd verkeer onderschept, maar het bleef slechts adviserend. Een proces kon de omgeving negeren, PATH omzeilen of gewoon direct sockets openen. Dit was te riskant.

Zoals bij elke interessante software-implementatie had het eerste prototype enkele voor- en nadelen. Hoewel het werkte met slechts een paar standaardmogelijkheden van Windows, zeer expliciete en gedetailleerde schrijfacties naar het bestandssysteem mogelijk maakte en zonder elevation draaide, waardoor gebruikers geen overmatige prompts voor beheerdersrechten hoefden te accepteren en ook geen administratorrechten op hun lokale machine hoefden te hebben, had het enkele echte nadelen, waarvan sommige het uitsloten als ons definitieve ontwerp:

• Snelheid van de setup: ACL’s toepassen op een werkruimte kan duur zijn, afhankelijk van de topologie van de werkruimtemap.
• Footprint: We hebben echte ACL’s toegepast op het systeem van de ontwikkelaar, al is die footprint niet bijzonder ingrijpend omdat alle toegepaste ACL’s betrekking hebben op een speciaal gemaakte synthetische SID die alleen door de sandbox wordt gebruikt.
• Moeilijk te wijzigen semantiek: de afhankelijkheid van ACL's voor bestandsgebaseerde beperkingen betekent dat het kostbaar en complex is om de sandbox-semantiek te wijzigen. Terwijl we op macOS dynamisch kunnen wijzigen hoe we het .sbpl -bestand genereren dat wordt gebruikt om Seatbelt te configureren, kan de Windows-sandbox een trage en intensieve bewerking vereisen om ACL's aan te passen.
• De netwerkbeveiliging is zwak. Zoals eerder vermeld was die 'adviserend', en zou die zeker worden omzeild door sommige programma’s die hun eigen netwerkstack implementeerden, en was die niet ontworpen om stand te houden tegen vijandige code.

De eerste drie problemen zijn inherent aan een aangepaste sandboximplementatie die flexibel genoeg is voor agentic flows. Het beperken van netwerktoegang lag echter anders.

Niet alleen kon een kwaadaardige agent de op omgevingsvariabelen gebaseerde netwerkbeperkingen eenvoudig omzeilen, ook veel legitieme code en binaries zouden daar probleemloos langsheen gaan als ze de proxyvariabelen niet gebruikten of hun eigen netwerkcode op socketniveau implementeerden. Dat vonden we een belangrijk genoeg probleem om te investeren in een betere sandboxmodus.

Om betere netwerkbeperkingen te krijgen, wilden we Windows Firewall gebruiken, waarmee we uitgaand netwerkverkeer voor gebruikers of programma’s kunnen blokkeren. Helaas konden we om een paar redenen niet effectief een werkende firewallregel maken die alleen gold voor de opdrachten die door de Codex-harness worden gestart:

• Windows staat niet toe dat een firewallregel wordt gekoppeld aan de niet-principal-identiteit van een beperkt token. Dat betekent dat we geen firewallregel konden toepassen op 'elk token dat onze synthetische SID in de lijst met beperkte SID’s bevat'.
• Hoewel we een firewallregel konden maken die overeenkomt met een specifieke binary, stelt dit ons alleen in staat om het netwerkverkeer van codex.exe zelf te beperken. Dit zou niet van toepassing zijn op de processen die de agent namens de gebruiker start, zoals Git- of Python-processen.
• Andere firewall-matchdimensies hadden ook een onjuiste structuur. Regels met gebruikersbereik kwamen in het 'unelevated' ontwerp nog steeds overeen met de werkelijke Windows-gebruiker, niet alleen met het beperkte child-proces. Regels voor programmapaden waren te grofmazig: ze konden codex.exe of python.exe in het algemeen blokkeren, maar niet deze ene in een sandbox uitgevoerde aanroep van python.exe. Poort- of adresgebaseerde regels waren bovendien volledig het verkeerde beleid. We wilden bijvoorbeeld niet poort 443 blokkeren; we wilden willekeurige uitgaande toegang blokkeren voor deze specifieke ingeperkte groep processen.

Om een firewallregel specifiek toe te passen op onze sandboxed opdrachten, moesten we ze als een aparte principal uitvoeren, niet als de 'echte' gebruiker. Deze aanpak bracht ons op een nieuw pad, waarin we onze beperking van 'unelevated' loslieten.

De volgende iteratie van de sandbox, onze huidige implementatie, vereist verhoogde beheerdersrechten tijdens de installatie. Daarom noem ik het 'de elevated sandbox'. Op de grens waar Codex een commando op het systeem start, ziet de elevated sandbox eruit als de unelevated sandbox. Het voert nog steeds onderliggende processen uit onder een beperkt token (ook een write_restricted token met dezelfde lijst van beperkte SID's van [Everyone, Logon, Synthetic]) maar de principal van dit token is niet langer de daadwerkelijke Windows-gebruiker, maar een van de twee lokale gebruikers die door Codex zelf zijn aangemaakt:

• CodexSandboxOffline (degene waarop firewallregels zijn gericht)
• CodexSandboxOnline (degene waarop firewallregels niet zijn gericht)

Dit ogenschijnlijk kleine detail heeft in werkelijkheid grote gevolgen voor de sandbox, wie die kan gebruiken en de complexiteit van setup en uitvoeringstijd.

Visueel lijkt die op het unelevated prototype, met de introductie van firewallregels en een speciale Windows-gebruiker die de opdrachten daadwerkelijk uitvoert. (Door de introductie van deze nieuwe concepten is er echter meer setupwerk nodig voordat de sandbox opdrachten kan uitvoeren en beschermen.)

Het ontwerp van de unelevated sandbox had een eenvoudige setupstap, maar die was relatief klein:

• Maak indien nodig een synthetische SID
• Pas ACL’s toe voor de synthetische SID sandbox-write.

De elevated sandbox heeft echter meer te doen.

• Maak een synthetische SID, als die nog niet is gemaakt
• Maak de online- en offline-sandboxgebruikers aan, als die nog niet zijn aangemaakt.
• Sla de referenties van de nieuw aangemaakte gebruikers lokaal op en versleutel ze met de Windows Data Protection API (DPAPI) op een plek die de sandboxgebruikers niet kunnen lezen
• Maak firewallregels die alle uitgaande netwerktoegang blokkeren voor de gebruiker CodexSandboxOffline, of valideer dat ze correct zijn als ze al bestaan

Er is nog een extra complicerende factor in de configuratiefase. De sandbox van Codex zou leestoegang moeten hebben die gelijkwaardig is aan die van de daadwerkelijke Windows-gebruiker. In de sandbox zonder verhoogde rechten, waarin de principal-SID van het beperkte token de Windows-gebruiker was, werd dit bereikt. Dat is echter niet zonder kosten wanneer de principal een nieuwe CodexSandbox -gebruiker wordt. Veel relevante mappen in Windows verlenen lees-/uitvoermachtigingen aan 'Geverifieerde gebruikers'. Een opmerkelijk voorbeeld is de profielmap van de gebruiker. Standaard kunnen Windows-gebruikers de profielmappen van andere Windows-gebruikers niet lezen, waardoor in veel scenario's zelfs eenvoudige leesbewerkingen op bestanden zouden mislukken.

Om dit aan te pakken, voegden we nog een laag toe aan het setup-proces van de sandbox: één voor het verlenen van read-ACL’s aan de sandboxgebruikers waar zulke ACL’s mogelijk nog niet bestaan. Bijvoorbeeld naar enkele veelgebruikte Windows-mappen:

• C:\Users\<real-user>
• C:\Windows\
• C:\Program Files\
• C:\Program Files (x86)\
• C:\ProgramData\

Omdat deze lijst van mappen een best-effortbenadering is en het installeren van ACL’s op elk ervan behoorlijk duur kan zijn, voeren we deze logica asynchroon uit zodat de sandboxsetupstap, die gebruikers blokkeert, niet hoeft te wachten tot alles is voltooid.

We hebben de installatielogica deels in een eigen uitvoerbaar bestand ondergebracht om de UAC-grens alleen te overschrijden wanneer dat nodig is. Maar de diepere reden was van architecturale aard: het instellen van de sandbox heeft een fundamenteel andere taak dan codex.exe. Door de sandboxsetuplogica in een speciale binary te houden, kon codex.exe een normale, unelevated harness blijven; bleef de Windows-specifieke setupmachinerie andere platforms niet onnodig verzwaren in codex.exe; werd langer lopend setupwerk losgekoppeld van de levensduur van het hoofdproces; en hadden we één plek om de verschillende setuppaden af te handelen die de sandbox nodig had.

Door de manier waarop aanmeldgrenzen van Windows-gebruikers en tokens werken, konden we niet doorgaan met het maken van een beperkt token en daaronder een proces starten zoals bij de unelevated sandbox. Om opdrachten daadwerkelijk als een andere Windows-gebruiker te starten, was ons eerste idee de volgende flow:

• codex.exe wordt uitgevoerd als de daadwerkelijke Windows-gebruiker. Vervolgens zet Codex de volgende stappen, in volgorde:
  • Het roept LogonUserW(...) aan voor de sandboxgebruiker.
  • Het roept CreateRestrictedToken(...) aan op dat token van de sandboxgebruiker.
  • Met dat token met beperkte rechten voor de sandboxgebruiker wordt CreateProcessAsUserW(...) aangeroepen om het uiteindelijke childproces te starten.

In de praktijk werkte die gewenste flow niet vanwege een rechtenbarrière bij CreateProcessAsUserW(...). Dit betekent dat codex.exe een beperkt token voor de sandboxgebruiker kon maken, maar vanaf de kant van de echte gebruiker van de scheiding niet betrouwbaar een childproces met dat token kon starten. We hadden een proces nodig dat al als de sandboxgebruiker draaide. Hierdoor zouden de beperkingsstap en de uiteindelijke spawn aan de kant van de sandboxgebruiker van de grens plaatsvinden in plaats van aan de kant van de werkelijke gebruiker.

Die vereiste heeft geleid tot codex-command-runner.exe, een nieuw binair bestand waarvan de enige taak is om een beperkt token aan te maken en de aangevraagde opdracht te starten. In plaats van codex.exe de hele flow zelf te laten doen (echte gebruiker → sandboxgebruiker → beperkt token → onderliggend proces), splitsten we de flow in tweeën:

Deel 1

• codex.exe roept CreateProcessWithLogonW(...) aan om codex-command-runner.exe als de sandboxgebruiker te starten, nog zonder een beperkt token te gebruiken.

Deel 2

• Binnen de runner opent OpenProcessToken(GetCurrentProcess(), ...) het eigen token van de runner, dat al toebehoort aan de sandboxgebruiker.
• De runner roept GetTokenInformation(...) aan om de logon-SID van de sandbox te extraheren, en vervolgens CreateRestrictedToken(...) om het uiteindelijke beperkte token te bouwen.
• Nog steeds binnen de runner roept die CreateProcessAsUserW(...) aan met dat beperkte token om het echte onderliggende proces te starten.

Albert Einstein zei: "Everything should be made as simple as possible, but no simpler." In die geest loste ons ontwerp elk probleem afdoende op. De uiteindelijke architectuur heeft de vier lagen die we eerder hebben behandeld:

• codex.exe zelf
• codex-windows-sandbox-setup.exe voor alle setupwerkzaamheden die elevation vereisen
• codex-command-runner.exe voor het uitvoeren van opdrachten met een beperkt token
• Het onderliggende proces

Toen ik dit project voor het eerst benaderde, had ik nog geen sterk beeld van waar het zou eindigen. Mijn aanpak was om te beginnen met het instrumenteren van de sandboxmogelijkheid op de grens tussen Codex en het besturingssysteem. Deze aanpak sluit nauw aan bij hoe de sandbox van Codex is geïmplementeerd op MacOs en Linux.

Naarmate ik meer leerde over de specifieke tools die Windows biedt, en via tientallen beslissingen waarin veiligheid en gebruiksgemak tegen elkaar werden afgewogen, groeide het systeem uit tot zijn huidige vorm: meerdere binaries, aangepaste gebruikers, firewallregels, een elevated setupstap, asynchrone processen en meer.

Het is geen bijzonder eenvoudig systeem, maar elk stuk complexiteit is uit noodzaak toegevoegd om een sandbox te bouwen die zowel veilig is als, zo veel mogelijk, de gebruiker niet in de weg zit.

Bij het werken aan een goede gebruikerservaring voor Codex-gebruikers op Windows was ons doel iets veiligs te maken zonder in te leveren op bruikbaarheid. Het hele punt van Codex is dat agents werk kunnen doen zonder jouw voortdurende aandacht.

Een van de grootste lessen van dit project was dat Windows ons niet één primitieve bouwsteen gaf die netjes overeenkomt met 'veilige autonome programmeeragent'. We hebben verschillende tools en concepten gecombineerd om iets samenhangends te bouwen. Sommige vroege ideeën bleken doodlopende wegen. Het uiteindelijke ontwerp was een hybride van eerdere prototypes die elk een deel van het probleem oplosten.

De andere les was dat beveiliging voor een programmeeragent fundamenteel verschilt van klassieke applicatiebeveiliging. Codex moet namelijk werken binnen echte ontwikkelaarsworkflows. Het engineeringwerk draaide om het vinden van de juiste balans tussen compatibiliteit met agentic workloads en daadwerkelijke afdwinging van beperkingen. Die spanning bepaalde uiteindelijk de afwegingen in het definitieve ontwerp.

Wil je de Codex-sandbox zelf in actie zien? Probeer het uit⁠.