Opbygning af en sikker og effektiv sandbox til at aktivere Codex på Windows

Da jeg blev en del af Codex-engineeringteamet i september 2025, havde Codex til Windows ikke nogen sandbox-implementering, hvilket betød, at Windows-brugere var tvunget til at vælge mellem to mindre gode muligheder, når de brugte OpenAI's kodningsagenter:

1. Godkende næsten hver eneste kommando (selv læsninger), som en kodningsagent ville køre, hvilket er ineffektivt og tidskrævende. En stor fordel ved at bruge Codex er, at du ikke selv behøver at udføre alt det kedelige arbejde.
2. Aktivere Full Access-tilstand: lad Codex køre alle kommandoer uden godkendelse eller begrænsninger, hvilket fjerner friktion på bekostning af tilsyn.

Codex⁠, som er vores kodningsagent, kører på udvikleres laptops, uanset om det er via CLI'en, IDE-udvidelsen eller desktopappen. Den administrerer en samtale mellem et menneske ved et tastatur og en model, der kører i skyen for at håndtere inferens.

Codex kører som standard med tilladelserne for en virkelig bruger, hvilket betyder, at den kan gøre alt, hvad brugeren kan. Det er kraftfuldt, men kan også være potentielt farligt. Kodningsmodellen kan bede harnessen om at køre kommandoer lokalt, lige fra at køre tests til at læse eller redigere en fil eller oprette en Git-branch, så Codex's standardtilstand forsøger at finde den rette balance mellem effektivitet og sikkerhed. Denne standardtilstand giver Codex mulighed for at læse filer næsten overalt og skrive filer i dit arbejdsområde (dvs. den mappe, hvor du kører Codex), uden internetadgang, medmindre du angiver, at du ønsker det. For at opnå denne automatiske begrænsning af filskrivning og netværksadgang inden for sikre rammer har Codex brug for et sandbox-miljø, der rent faktisk håndhæver disse begrænsninger.

En sandbox er et afgrænset eksekveringsmiljø. Når en udvikler bruger Codex, starter computerens operativsystem en kommando med reducerede tilladelser, og disse begrænsninger forplanter sig ned gennem procestræet. Alle Codex-kommandoer køres i en sandbox fra starten, og alle efterfølgende processer forbliver inden for den samme afgrænsning.

Codex har brug for isolationsfunktioner, der håndhæves af computerens operativsystem, for at implementere en effektiv sandbox. Nogle operativsystemer tilbyder værktøjer, der gør dette godt (f.eks. Seatbelt på MacOs, seccomp eller bubblewrap på Linux). Windows tilbyder dog i øjeblikket ikke denne type funktionalitet som standard.

For at gøre Codex lige så sikker og behagelig at bruge på Windows, som det allerede er alle andre steder, var vi nødt til at implementere vores egen sandbox.

Windows tilbyder nogle værktøjer og primitiver til isolation. Selvom ingen af dem helt opfyldte vores krav, så vi på en række potentielle løsninger såsom AppContainer, Windows Sandbox og mærkning med Mandatory Integrity Control.

AppContainer

• Hvad: AppContainer er Windows' indbyggede sandbox, som er en kapacitetsbaseret isolationsmodel bygget til apps, der på forhånd præcist ved, hvad de har brug for adgang til.
• Hvorfor: Tiltrækkende, fordi den tilbyder en reel OS-grænse i stedet for begrænsninger baseret på bedste indsats.
• Hvorfor ikke: Codex er ikke én specifik afgrænset app. Den understøtter åbne udviklerarbejdsgange: shells, Git, Python, pakkehåndteringsværktøjer, build-værktøjer og alle andre eksekverbare filer, som agenten beslutter, at den har brug for. I praksis betød det, at AppContainer ikke passede til problemet. Det var stærk isolering, men for en langt snævrere klasse af arbejdsbelastninger end “lad en agent agere som en udvikler.”

Windows Sandbox

• Hvad: Windows Sandbox er Microsofts kasserbare letvægts-VM. Du får et nyt Windows-skrivebord med en stærk isolationsgrænse, og alt, hvad du gør inde i det, forsvinder, når sessionen slutter.
• Hvorfor: Interessant af indlysende årsager, da den er langt mere kompatibel med vilkårlig software end AppContainer, og fra et sikkerhedsperspektiv er det en meget stærkere sandbox.
• Hvorfor ikke: Codex skal agere direkte på brugerens faktiske checkout, værktøjer og miljø, og ikke inde i et separat midlertidigt skrivebord, der ville kræve opsætning og host/guest-brobygning. Den havde også et grundlæggende produktproblem: Windows Sandbox er endnu ikke tilgængelig på Windows Home-SKU'er.

Mandatory Integrity Control (MIC)-integritetsmærkning

• Hvad: Windows har et begreb, der kaldes ”integritetsniveauer”, såsom lavt, mellem og højt, som bestemmer, hvor meget systemet har tillid til objekter og processer. Grundreglen er, at en proces med lavere integritet ikke kan skrive til et objekt med et højere integritetsniveau, selv om den normale ACL ellers ville tillade det. For eksempel behandles en proces med lavt integritetsniveau som mindre betroet, så Windows blokerer den fra at skrive til normale objekter med mellemhøjt integritetsniveau, medmindre disse objekter eksplicit er mærket for at tillade det.
• Hvorfor: MIC så elegant ud på papiret. Den kører Codex med lav integritet, ommærker de skrivbare rødder som lav integritet, og lader Windows håndhæve ingen-skrivninger alle andre steder. Det ville have givet os en vej uden administratorrettigheder, understøttet af en reel OS-mekanisme.
• Hvorfor ikke: Ligesom ACL'er ændrer integritetsmærker det faktiske værtsfilsystem, og i dette tilfælde er den semantiske ændring særligt omfattende. At mærke et arbejdsområde som lav integritet betyder ikke bare “Codex kan skrive her.” Det betyder, at processer med lav integritet generelt kan skrive dér. På en virkelig udviklermaskine gør det brugerens faktiske checkout til et lav-integritets-opsamlingspunkt for værten, hvilket er langt mere risikabelt end at give omhyggeligt målrettede ACL'er til ét sandbox-design. Selv hvis udviklerværktøjer med mellem-integritet fortsat fungerer, har den underliggende tillidsmodel for arbejdsområdet ændret sig på en måde, der er svær at indeslutte og endnu sværere at retfærdiggøre.

Efter at have vurderet alle mulighederne som uegnede begyndte vi at designe vores egen løsning for at give Windows-brugere en god Codex-oplevelse.

Vores første fungerende prototype brugte en kombination af Windows-koncepter og -værktøjer til at implementere den isolering, vi havde brug for. Fra begyndelsen var ét mål at få dette til at fungere uden at kræve forhøjede rettigheder, hvilket betyder, at Codex ikke skulle prompte brugeren om administratorrettigheder blot for at konfigurere eller køre sandboxen. Det betød, at vi skulle finde ud af, hvordan vi kunne sætte rimelige grænser for to ting: filskrivninger og netværksadgang.

Hvis vi slet ikke begrænsede filskrivninger, ville vi have et sikkerhedsproblem. Hvis vi begrænsede filskrivninger for meget, ville sandboxen skade brugerproduktiviteten ved at kræve konstant godkendelse. For at løse dette problem byggede vi på to vigtige Windows-byggesten: SID'er og skrivebegrænsede tokens.

Et SID, eller en sikkerhedsidentifikator, er den identitet, som Windows knytter til tilladelser. Hver bruger har et SID, grupper har SID'er, og selv en enkelt loginsession får sit eget SID. For eksempel kan en aktuel logonsession have et SID som S-1-5-5-X-Y. Det SID, der er tildelt den lokale administratorgruppe, kan være S-1-5-32-544.

Windows gør det også muligt at oprette syntetiske SID'er, der ikke svarer til en virkelig bruger, men som stadig kan optræde i ACL'er (Access Control Lists), der definerer, hvem der kan læse/skrive/eksekvere bestemte filer eller mapper. Det gør SID'er til en nyttig primitiv for vores sandbox, eftersom vi kan oprette SID'er eksklusivt til brug for Codex-sandboxen uden at forstyrre andet på maskinen.

Proces-token er sikkerhedsobjekter i Windows, der definerer identitet og privilegier for en kørende proces. De bestemmer, hvilke handlinger en proces kan udføre. Et skrivebegrænset token er en bestemt type proces-token, der får Windows til at udføre en ekstra adgangskontrol ved skrivehandlinger.

For at en skrivning kan lykkes, skal to kontroller bestås:

1. Den normale brugeridentitet (tokenets “ejer”) skal have lov til at gøre det
2. Mindst én SID i tokenets liste over begrænsede SID'er skal også have tildelt adgang

I praksis lod disse kontroller os bruge ACL'er til præcist at definere, hvor sandboxen kunne ændre filsystemet, hvilket gav den granularitet, vi havde brug for med hensyn til skriveoperationer.

Med SID'er og skrivebegrænsede tokens fungerede vores ikke-forhøjede sandbox således:

1. Sandbox-opsætningen oprettede en syntetisk SID kaldet sandbox-write.
2. sandbox-write-SID'et fik tildelt skrive-, udførelses- og sletteadgang til
   1. Den aktuelle arbejdsmappe
   2. Eventuelle yderligere writable_roots konfigureret i config.toml.
3. Sandbox-opsætningen nægtede udtrykkeligt den samme SID skriveadgang til “skrivebeskyttet inden for skrivbart”-placeringer såsom:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex startede kommandoer under et skrivebegrænset token, hvis liste over begrænsede SID'er omfatter Everyone, SID'en for den aktuelt loggede session samt den syntetiske SID sandbox-write.

Dette flow løste effektivt begrænsning af filskrivninger og virkede lovende. Nu havde vi brug for en løsning til at begrænse sandboxens netværksadgang.

Begrænsning af netværksadgang er en vigtig del af sandboxen. Hvis der ikke var nogen begrænsning, kunne ondsindet kode eksfiltrere data fra maskinen ud på internettet. Eftersom vi ønskede at undgå et krav om forhøjelse, havde vi begrænsede muligheder for at blokere netværkstrafik effektivt. De værktøjer, vi gerne ville bruge, som f.eks. Windows Firewall, kunne generelt ikke installeres uden administratortilladelser.

Uden Windows Firewall som en mulighed begrænsede vi, hvad vi kunne styre. Vi forsøgte at få undermiljøet til at være “fail-closed”, hvilket betyder lukket som standard, for de typer netværksbaserede værktøjer, som udviklere rent faktisk bruger, så Git-kommandoer, pakkeinstallationsprogrammer osv. ville fejle i sandboxen, og brugeren skulle godkende alle internetrettede handlinger. Idéen var at forgifte de oplagte flugtveje ved at sende trafik, der tager højde for proxyer, til et dødt endepunkt, få Gits HTTP(S)-transport til at gøre det samme og få Git via SSH til at fejle med det samme. Derudover tilføjede vi en lille denybin-mappe forrest i PATH og ændrede rækkefølgen i PATHEXT, så stub-scripts til SSH og SCP blev fundet før de rigtige binære filer.

Her er f.eks. nogle af de specifikke miljøoverstyringer, som vi brugte til at begrænse netværksadgang:

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

Det fangede meget af den normale værktøjsdrevne trafik, men det var stadig kun vejledende. En proces kunne ignorere miljøet, omgå PATH eller bare åbne sockets direkte, hvilket var alt for risikabelt.

Som med enhver interessant softwareimplementering havde den første prototype nogle fordele og ulemper. Selvom den fik arbejdet gjort med blot nogle få standardfunktioner i Windows, som muliggjorde meget eksplicitte og granulære filsystemsskrivninger og kørsel uden forhøjede rettigheder, hvilket reducerede behovet for, at brugere skulle acceptere unødigt mange prompter om forhøjelse eller være administratorer på deres lokale maskine. Den havde dog nogle reelle ulemper, som gjorde, at den ikke kunne blive vores endelige design:

• Hastighed ved opsætning: Anvendelse af ACL'er på arbejdsområdet kan være dyrt afhængigt af topologien i arbejdsområdets mappestruktur.
• Aftryk: Vi anvendte reelle ACL'er på udviklerens system, selvom aftrykket ikke er særligt invasivt, fordi alle de anvendte ACL'er vedrører en specialoprettet syntetisk SID, der kun bruges af sandboxen.
• Semantik, der er vanskelig at ændre: Afhængigheden af ACL'er til filbaserede begrænsninger betyder, at det er dyrt og komplekst at ændre sandbox-semantik. Mens vi på macOS dynamisk kan ændre, hvordan vi genererer .sbpl-filen, der bruges til at konfigurere Seatbelt, kunne Windows-sandboxen kræve en langsom og intensiv handling for at justere ACL’er.
• Netværksbeskyttelsen er svag. Som nævnt tidligere var det “vejledende”, ville helt sikkert blive omgået af nogle programmer, der implementerede deres egen netværksstak, og var ikke designet til at modstå fjendtlig kode.

De første tre problemer er iboende i en tilpasset sandbox-implementering, der er fleksibel nok til agentiske flows. Udviklingen af netværksundertrykkelse var dog anderledes.

Ud over at en ondsindet agent nemt kunne omgå den miljøbaserede netværksundertrykkelse, ville mange kode/binære filer med gode intentioner også omgå den, hvis de ikke respekterede miljøets proxy-variabler, eller hvis de implementerede deres egen socket-baserede netværkskode. Vi følte, at dette aspekt i sig selv var nok til at overveje at investere i en bedre sandbox-tilstand.

For at opnå bedre netværksundertrykkelse ønskede vi at bruge Windows Firewall, som giver os mulighed for at blokere udgående netværkstrafik for brugere eller programmer. Desværre kunne vi ikke effektivt oprette en funktionel firewall-regel, der kun gjaldt for de kommandoer, som Codex-harnessen startede, af flere årsager:

• Windows tillader ikke, at en firewall-regel matches med den ikke-principale identitet for et begrænset token. Det betød, at vi ikke kunne anvende en firewall-regel på “ethvert token, der indeholder vores syntetiske SID i sin liste over begrænsede SID'er.”
• Selvom vi kunne oprette en firewall-regel, der matcher en bestemt binær fil, giver det os kun mulighed for at begrænse netværk for selve codex.exe. Det ville ikke omfatte de processer, som agenten starter på vegne af brugeren, f.eks. Git- eller Python-processer.
• Andre dimensioner for firewall-match havde også den forkerte form. Brugerafgrænsede regler matchede stadig den faktiske Windows-bruger i det ikke-forhøjede design og ikke kun den begrænsede underproces. Regler for programstier var for strenge: De kunne blokere codex.exe eller python.exe generelt, men ikke netop denne ene sandbox-isolerede kørsel af python.exe. Port- eller adressebaserede regler havde også en helt forkert politik. For eksempel ønskede vi ikke at blokere port 443. Vi ville blokere vilkårlig udgående adgang for dette specifikke begrænsede procestræ.

For at kunne anvende en firewall-regel specifikt på vores sandboxede kommandoer var vi nødt til at køre dem som en separat principal, i stedet for som den “rigtige” bruger. Denne tilgang førte os ad en ny vej, hvor vi lempede vores “ingen forhøjet”-begrænsning.

Den næste iteration af sandboxen, som er vores aktuelle implementering, kræver forhøjede administratorrettigheder under opsætningen. Jeg omtaler det derfor som “den forhøjede sandbox.” Ved grænsen, hvor Codex starter en kommando på systemet, ligner sandboxen med forhøjede rettigheder den uden forhøjede rettigheder. Den kører stadig underordnede processer under en begrænset token svarende til en write_restricted-token med den samme begrænsede SID-liste på [Everyone, Logon, Synthetic], men sikkerhedsprincipalen for denne token er ikke længere den faktiske Windows-bruger, men en af to lokale brugere, som Codex selv har oprettet:

• CodexSandboxOffline (den, som firewall-reglerne er målrettet mod)
• CodexSandboxOnline (den, som firewall-reglerne ikke er målrettet mod)

Denne tilsyneladende lille detalje har faktisk stor betydning for sandboxen, såsom hvem der kan bruge den, og kompleksiteten i dens opsætning og kørsel.

Den ligner visuelt den ikke-forhøjede prototype med introduktionen af firewall-regler og en dedikeret Windows-bruger, som faktisk kører kommandoerne. (Introduktionen af disse nye koncepter betyder dog, at der er mere opsætningsarbejde, der skal udføres, før sandboxen kan begynde at køre og beskytte kommandoer.)

Designet for den ikke-forhøjede sandbox havde et enkelt opsætningstrin, men det var relativt lille:

• Opret en syntetisk SID, hvis det er nødvendigt
• Anvend ACL'er for den syntetiske SID sandbox-skrivning

Den forhøjede sandbox har dog mere at gøre.

• Opret en syntetisk SID, hvis den ikke allerede er oprettet
• Opret online- og offline-sandboxbrugerne, hvis de ikke allerede er oprettet
• Gem legitimationsoplysningerne for de nyoprettede brugere lokalt, og kryptér dem ved hjælp af Windows Data Protection API (DPAPI) på et sted, hvor sandbox-brugerne faktisk ikke kan læse dem
• Opret firewall-regler, der blokerer al udgående netværksadgang for brugeren CodexSandboxOffline, eller kontrollér, at de er korrekte, hvis de allerede findes

Der er dog en ekstra komplikation i opsætningsfasen. Codex’ sandbox forventes at have samme læseadgang som den faktiske Windows-bruger. I sandboxen uden forhøjede rettigheder, hvor principal-SID’en for det begrænsede token var Windows-brugeren, blev dette opnået. Det sker dog ikke af sig selv, når principalen bliver en ny CodexSandbox-bruger. Mange relevante mapper i Windows giver læse- og kørselstilladelser til “Godkendte brugere”. Et bemærkelsesværdigt eksempel er brugerens profilmappe. Som standard kan Windows-brugere ikke læse andre Windows-brugeres profilmapper, så selv simpel fillæsning ville i mange scenarier mislykkes.

For at løse dette problem tilføjede vi endnu et lag til sandboxens opsætningsproces. Et lag til at give sandboxbrugerne læse-ACL'er, hvor sådanne ACL'er måske ikke allerede findes. For eksempel til nogle almindeligt anvendte Windows-mapper:

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

Eftersom denne liste over mapper er best effort, og fordi installation af ACL'er på hver enkelt kan være ret dyrt, kører vi denne logik asynkront, så sandboxens opsætningstrin, som er blokerende for brugerne, ikke behøver at vente på, at de bliver fuldført.

Vi indkapslede opsætningslogikken i sin egen eksekverbare binærfil, delvist for kun at skulle krydse UAC-grænsen, når det var nødvendigt. Men den dybereliggende årsag var arkitekturmæssig: sandbox-opsætningen har en grundlæggende anden opgave end codex.exe. Ved at holde sandbox-opsætningslogikken i en dedikeret binær fil kunne codex.exe forblive en normal, ikke-forhøjet harness. Vi undgik, at den Windows-specifikke opsætningsmekanik oppustede codex.exe på andre platforme. Vi afkoblede længerevarende opsætningsarbejde fra hovedprocessens levetid. Og vi fik ét sted til at håndtere de forskellige opsætningsveje, som sandboxen havde brug for.

På grund af den måde, som grænserne for Windows-brugere og token-logins fungerer på, kunne vi ikke fortsætte med at oprette et begrænset token og starte en proces under det på den måde, vi kunne med den ikke-forhøjede sandbox. For faktisk at starte kommandoer som en anden Windows-bruger var vores første idé følgende flow:

• codex.exe kører som den faktiske Windows-bruger. Derefter gør Codex følgende i rækkefølge:
  • Kalder LogonUserW(...) for sandbox-brugeren.
  • Kalder CreateRestrictedToken(...) på den pågældende sandbox-brugertoken.
  • Ved hjælp af det begrænsede sandbox-bruger-token kaldes CreateProcessAsUserW(...) for at starte den endelige underproces.

I praksis fungerede det ønskede flow ikke på grund af en privilegiebarriere ved CreateProcessAsUserW(...). Dette betyder, at codex.exe kunne oprette et begrænset token for sandbox-brugeren, men at programmet ikke pålideligt kunne starte en underordnet proces med det token fra den reelle brugers side af grænsen. Vi havde brug for en proces, der allerede kørte som sandbox-brugeren. Det ville lade begrænsningstrinnet og den endelige processtart ske på sandbox-brugerens side af grænsen i stedet for på den reelle brugers side.

Det krav førte til codex-command-runner.exe, en ny binærfil, hvis eneste opgave er at udstede et begrænset token og starte den anmodede kommando. I stedet for at bede codex.exe om selv at udføre hele flowet (virkelig bruger → sandbox-bruger → begrænset token → underordnet proces) delte vi flowet op i to dele:

Del 1

• codex.exe kalder CreateProcessWithLogonW(...) for at starte codex-command-runner.exe som sandbox-brugeren, endnu uden at bruge et begrænset token.

Del 2

• Inde i runneren åbner OpenProcessToken(GetCurrentProcess(), ...) runnerens eget token, som allerede tilhører sandbox-brugeren.
• Runneren kalder GetTokenInformation(...) for at udtrække sandboxens logon-SID og derefter CreateRestrictedToken(...) for at opbygge det endelige begrænsede token.
• Stadig inde i runneren kalder den CreateProcessAsUserW(...) med det begrænsede token for at starte den egentlige underordnede proces.

Albert Einstein sagde: “Alt bør gøres så enkelt som muligt, men ikke enklere.” I den ånd løste vores design hvert problem tilstrækkeligt. Den endelige arkitektur har de fire lag, vi tidligere har gennemgået:

• Selve codex.exe
• codex-windows-sandbox-setup.exe til håndtering af alt arbejde, der er relateret til forhøjet opsætning
• codex-command-runner.exe til kørsel af kommandoer med begrænset token
• Den underordnede proces

Da jeg først startede på dette projekt, havde jeg ikke en stærk fornemmelse af, hvor det ville ende. Min tilgang var at begynde med at instrumentere sandbox-kapaciteten i grænsen mellem Codex og operativsystemet. Denne tilgang svarer til, hvordan Codex's sandbox er implementeret på MacOs og Linux.

Efterhånden som jeg lærte mere om de specifikke værktøjer, som Windows stiller til rådighed, og gennem mange beslutninger, der balancerede sikkerhed og brugervenlighed, voksede systemet til sin nuværende form med flere binære filer, brugerdefinerede brugere, firewall-regler, et forhøjet opsætningstrin, asynkrone processer og mere.

Det er ikke et særligt enkelt system, men hvert element af kompleksitet blev tilføjet af nødvendighed for at bygge en sandbox, der både er sikker og, så vidt muligt, ikke hindrer brugeren.

I arbejdet med at levere en god brugeroplevelse for Codex-brugere på Windows var vores mål at skabe noget sikkert, som ikke gik på kompromis med anvendeligheden. Hele pointen med at bruge Codex er at lade agenter udføre arbejdet uden din konstante opmærksomhed.

En af de største læringer fra dette projekt var, at Windows ikke gav os én primitiv, der kortlægger til “sikker autonom kodningsagent”. Vi kombinerede flere værktøjer og koncepter for at bygge noget sammenhængende. Nogle tidlige idéer viste sig at være blindgyder. Det endelige design var en hybrid af tidligere prototyper, som hver løste en del af problemet.

Den anden læring var, at sikkerhed for en kodningsagent er et større problem end blot klassisk applikationssikkerhed. Codex skal fungere for virkelige udvikler-workflows. Engineering-arbejdet handlede om at balancere kompatibilitet med agentiske arbejdsbelastninger mod reel håndhævelse. Disse konstateringer formede afvejelserne i det endelige design.

Vil du gerne se Codex-sandboxen i aktion? Prøv den⁠.