OpenAI julkaisi 13. toukokuuta David Wiesenin kirjoittaman blogitekstin, jossa yhtiö purkaa auki, miten Codex-koodausagentin hiekkalaatikko toteutettiin Windowsille. Kun Wiesen liittyi tiimiin syksyllä 2025, Codexin Windows-käyttäjillä oli kaksi huonoa vaihtoehtoa: hyväksyä jokainen komento erikseen tai antaa agentille rajoittamaton Full Access -tila.
Ratkaisua ei voinut suoraan kopioida muista käyttöjärjestelmistä. macOSista löytyy Seatbelt ja Linuxista seccomp sekä bubblewrap, mutta Windowsista vastaavaa valmista työkalua ei ole. Niinpä OpenAI suunnitteli oman sandboxin, joka rajoittaa Codexin tiedostokirjoituksia ja verkkoliikennettä riittävän vahvasti, mutta ei estä agentin perustyötä.
Windowsin valmiit työkalut eivät riittäneet
OpenAI kävi läpi kolme valmista isolaatiomekanismia ennen kuin päätyi oman ratkaisun rakentamiseen. AppContainer on Windowsin natiivi hiekkalaatikko, mutta se on suunniteltu yhdelle tiukasti rajatulle sovellukselle. Codex sen sijaan ajaa Gitiä, Pythonia, paketinhallintaa ja mitä tahansa, mitä kehittäjä työvuonsa aikana tarvitsee.
Windows Sandbox eli kertakäyttöinen kevyt virtuaalikone tarjoaisi vahvan eristyksen, mutta sen sisällä toimittaisiin täysin erillisellä työpöydällä. Codexin pitäisi päästä käsiksi käyttäjän todelliseen koodikansioon ja työkaluihin, eikä ratkaisua olisi voinut käyttää Windowsin Home-versiossa, koska Microsoft ei jaa sandboxia siellä.
Mandatory Integrity Control -merkinnät näyttävät paperilla tyylikkäiltä: ajetaan Codex matalalla luottamustasolla ja merkitään kirjoituskelpoiset hakemistot saman tasoisiksi. Käytännössä se kuitenkin laskisi käyttäjän työkansion luottamustason koko järjestelmälle, mikä on liian laaja muutos.

Ensimmäinen prototyyppi tukeutui SIDeihin ja tokeneihin
Ensimmäinen prototyyppi pyöri ilman pääkäyttäjäoikeuksia. Se rakentui kahden Windows-rakennuspalikan varaan: synteettisiin SID-tunnisteisiin ja write-restricted-tokeneihin, jotka voivat lisätä kirjoitusoperaatioon ylimääräisen tarkastuksen.
Codex loi oman sandbox-write-nimisen SIDin ja antoi sille kirjoitusoikeudet vain nykyiseen työkansioon sekä erikseen määriteltyihin writable_roots-polkuihin. Samalla SIDiltä estettiin kirjoitus arkaluonteisiin alikansioihin, kuten .git, .codex ja .agents.
Tämä esti tehokkaasti, ettei agentti pääsisi koskemaan järjestelmän tiedostoihin oman työkansion ulkopuolella. Tiedostokirjoituksen osalta ratkaisu toimi, mutta verkkoliikenteen rajoittaminen osoittautui kompastuskiveksi.

Verkkoeristys kaatui ympäristömuuttujiin
Ilman pääkäyttäjäoikeuksia Windowsin palomuurin sääntöjä ei voinut asentaa. OpenAI yritti tukkia verkon näkyvimmät reitit ympäristömuuttujilla: HTTPS_PROXY, ALL_PROXY ja GIT_HTTPS_PROXY ohjattiin kuolleeseen päätepisteeseen, GIT_SSH_COMMAND rikottiin ja PATHiin lisättiin estopari SSH:lle ja SCP:lle.
Käytännössä tämä esti suuren osan tavallisista työkalujen verkkokutsuista, mutta jätti suuren porsaanreiän. Jos prosessi avasi oman socketin tai ei lukenut proxy-asetuksia, yhteys avautui. Suojaus oli neuvoa-antava, ei pakottava, eikä se kestäisi tahallisesti haitallista koodia.
Wiesen kirjoittaa, että juuri tämä heikkous päätti seuraavan vaiheen suunnan. Kunnollinen verkkoeristys edellytti Windowsin palomuurin käyttöä, ja palomuurisääntöjen lisääminen vaatii pääkäyttäjäoikeudet.

Lopullinen ratkaisu vaatii pääkäyttäjäoikeudet ja kaksi käyttäjää
Nykyisessä toteutuksessa Codex luo asennuksen yhteydessä kaksi paikallista käyttäjää: CodexSandboxOffline ja CodexSandboxOnline. Ensimmäiseen kohdistuu palomuurisääntö, joka estää kaiken ulospäin lähtevän liikenteen, jälkimmäiseen ei.
Kun Codex haluaa ajaa komennon, codex.exe käynnistää erillisen codex-command-runner.exe:n sandbox-käyttäjän tunnuksilla. Vasta runner luo write-restricted-tokenin ja käynnistää lopullisen lapsiprosessin sen sisällä, koska Windowsin oikeusrajat estävät tämän tekemisen suoraan oikean käyttäjän puolelta.
Asennusvaiheessa luodaan myös tarvittavat SIDit, talletetaan käyttäjien tunnukset Windowsin DPAPI:lla suojattuna ja jaetaan lukuoikeudet keskeisiin hakemistoihin kuten C:\Users, C:\Windows ja C:\Program Files, jotta sandbox näkee saman kuin oikea käyttäjä.

Yhteenveto
Codexin Windows-hiekkalaatikko on monikerroksinen kompromissi turvallisuuden, käytettävyyden ja Windowsin omien rajoitteiden välillä. Ratkaisu vaatii kertakaikkisen UAC-hyväksynnän, mutta sen jälkeen agentti ajaa komennot eri käyttäjätunnuksella, rajoitetussa tokenissa ja palomuurisääntöjen alla.
OpenAI:n blogi paljastaa myös, että koodausagenttien tietoturva on käytännössä uusi ohjelmistoturvallisuuden alalaji: agentin pitää saada tehdä kehittäjän työtä, mutta vain niissä rajoissa, joista käyttäjä on tietoinen. Tämä jännite näkyy jokaisessa Codex-sandboxin valinnassa.
