Pagbuo ng ligtas at epektibong sandbox para paganahin ang Codex sa Windows

Nang sumali ako sa engineering team ng Codex noong Setyembre 2025, wala pang pagpapatupad sa sandbox ang Codex para sa Windows, ibig sabihin napipilitan ang mga user ng Windows na pumili sa dalawang opsyong hindi sapat ang kalidad kapag ginagamit ang mga coding agent ng OpenAI:

1. Aprubahan ang halos bawat command (kahit mga read) na gustong patakbuhin ng coding agent, na hindi episyente at nakakainis. Isang malaking benepisyo ng paggamit ng Codex ay hindi kailangang ikaw mismo ang gumawa ng lahat ng matrabahong gawain.
2. I-enable ang Full Access mode: hayaan ang Codex na patakbuhin ang lahat ng command nang walang pag-apruba o paghihigpit, na nag-aalis ng alitan kapalit ng mas kaunting pagbabantay.

Ang Codex⁠, ang aming coding agent, ay tumatakbo sa mga laptop ng developer—maging sa pamamagitan man ng CLI, IDE extension, o desktop app. Pinamamahalaan nito ang pag-uusap sa pagitan ng taong gumagamit ng keyboard at modelong tumatakbo sa cloud upang magsagawa ng konklusyon.

Bilang default, tumatakbo ang Codex gamit ang mga pahintulot ng totoong user, ibig sabihin magagawa nito ang lahat ng kayang gawin ng user. Makapangyarihan ito at posibleng mapanganib. Maaaring sabihin ng modelo sa pag-code sa harness na magpatakbo ng mga command nang lokal, mula sa pagpapatakbo ng mga pagsubok hanggang sa pagbabasa o pag-edit ng file hanggang sa paggawa ng Git branch, kaya sinusubukan ng default mode ng Codex na mahanap ang tamang balanse sa pagitan ng pagiging epektibo at kaligtasan. Pinapayagan ng default mode na ito ang Codex na magbasa ng mga file halos kahit saan at magsulat ng mga file sa loob ng iyong workspace (ibig sabihin, ang directory kung saan mo pinapatakbo ang Codex), nang walang internet access maliban kung tukuyin mong gusto mo ito. Para maipatupad ang awtomatikong limitasyong ito sa pagsusulat ng mga file at pag-access sa network sa loob ng ligtas na hangganan, kailangan ng Codex ng sandbox environment na talagang nagpapatupad ng mga limitasyong ito.

Ang sandbox environment ng pagpapatakbo na may mga limitasyon. Kapag gumagamit ang developer ng Codex, ang operating system ng kaniyang computer ay naglulunsad ng command na may mas mababang pahintulot, at ang mga limitasyong iyon ay naipapasa pababa sa process tree. Ang bawat command ng Codex ay naka-sandbox mula pa sa simula, at nananatili ang bawat descendant process sa loob ng parehong hangganan.

Kailangan ng Codex ng mga tampok ng pagbubukod na ipinapatupad ng operating system ng computer para makapagpatupad ng epektibong sandbox. May ilang operating system na may mga utility na mahusay dito (hal., Seatbelt sa MacOs, seccomp o bubblewrap sa Linux); gayunman, sa kasalukuyan ay walang ganitong kakayahan ang Windows bilang default.

Para gawing kasing ligtas at kasing saya gamitin ang Codex sa Windows gaya ng sa iba pang lugar, kinailangan naming gumawa ng sarili naming sandbox.

Nag-aalok ang Windows ng ilang tool at primitive para sa pagbubukod. Bagama't wala sa mga ito ang lubusang tumugon sa aming mga kinakailangan, tiningnan namin ang ilang posibleng solusyon—partikular ang pag-label sa AppContainer, Windows Sandbox, at Mandatory Integrity Control.

AppContainer

• Ano: Ang AppContainer ay ang katutubong sandbox ng Windows, isang modelo ng pagbubukod na nakabatay sa kakayahan na ginawa para sa mga app na alam na agad, mula sa simula, kung ano ang kailangan nilang i-access.
• Bakit: Kaakit-akit dahil nag-aalok ito ng tunay na OS boundary sa halip na best-effort na mga paghihigpit.
• Bakit hindi: Ang Codex ay hindi isang app na may napakahigpit na saklaw. Pinapatakbo nito ang mga open-ended na daloy ng trabaho ng developer: shells, Git, Python, package manager, tool sa pagbuo, at anumang iba pang binary na ipinapasya ng agent na kailangan nito. Sa aktuwal na paggamit, ginawa nitong hindi angkop ang AppContainer para sa problema. Mahigpit ang pagbubukod nito, pero para ito sa mas makitid na klase ng mga workload kaysa sa “hayaan ang isang agent na kumilos na parang developer.”

Windows Sandbox

• Ano: Ang Windows Sandbox ay pansamantala at magaan na VM ng Microsoft. Makakakuha ka ng bagong Windows desktop na may matibay na hangganan ng pagbubukod, at anumang gawin mo rito ay nawawala kapag natapos ang sesyon.
• Bakit: Nakakapukaw-interes dahil sa kapansin-pansing mga dahilan—mas tugma ito sa arbitrary na software kaysa AppContainer, at mula sa pananaw ng seguridad ay mas malakas itong box.
• Bakit hindi: Kailangang direktang kumilos ang Codex sa aktuwal na pag-checkout, mga tool, at environment ng user, hindi sa hiwalay na pansamantalang desktop na mangangailangan ng setup at host/guest bridging. Mayroon din itong pangunahing problema sa produkto: ni hindi available ang Windows Sandbox sa mga Windows Home SKU.

Mandatory Integrity Control (MIC) na pag-label ng integridad

• Ano: Ang Windows ay may konsepto na tinatawag na “mga antas ng integridad,” tulad ng mababa, katamtaman, at mataas, na nagtatakda kung gaano kalaki ang tiwala ng system sa mga bagay at proseso. Ang pangunahing panuntunan ay hindi maaaring magsulat ang isang prosesong may mas mababang integridad sa isang bagay na may mas mataas na antas ng integridad, kahit na papayagan sana ito ng karaniwang ACL. Halimbawa, ang prosesong may mababang integridad ay itinuturing na hindi gaanong pinagkakatiwalaan, kaya hinaharangan ito ng Windows sa pagsusulat sa mga karaniwang bagay na may katamtamang integridad, maliban kung ang mga bagay na iyon ay hayagang muling nilagyan ng label upang payagan ito.
• Bakit: Maganda sa papel ang MIC—patakbuhin ang Codex sa mababang integridad, lagyan muli ng mababang integridad ang mga writable root, at hayaang ipatupad ng Windows ang no-writes sa iba pa. Nakapagbigay sana iyon sa atin ng non-admin na paraan na sinusuportahan ng tunay na mekanismo ng OS.
• Bakit hindi: Tulad ng mga ACL, binabago ng mga label ng integridad ang aktuwal na filesystem ng host, at sa kasong ito, lalo nang malawak ang pagbabago sa semantika. Ang pagmamarka ng isang workspace bilang mababang integridad ay hindi lamang nangangahulugan na “maaaring magsulat dito ang Codex.” Ibig sabihin, ang mga prosesong may mababang integridad sa pangkalahatan ay maaaring magsulat doon. Sa isang tunay na makina sa pag-develop, ginagawa nitong imbakan ng mababang integridad para sa host ang aktuwal na pag-checkout ng user, na mas mapanganib kaysa sa pagbibigay ng maingat na naka-target na mga ACL sa disenyo ng sandbox. Kahit patuloy na gumana ang mga katamtamang integridad na tool sa pag-develop, nagbago ang pangunahing modelo ng tiwala ng workspace sa paraang mahirap kontrolin at mas mahirap pang bigyang-katwiran.

Matapos naming suriin ang lahat ng opsyon at makitang hindi uubra, nagsimula kaming magdisenyo ng sarili naming solusyon para makapaghatid ng magandang karanasan sa Codex para sa mga user ng Windows.

Ang una naming gumaganang prototype ay gumamit ng kumbinasyon ng mga konsepto at tool ng Windows upang ipatupad ang pagbubukod na kinailangan namin. Mula pa sa simula, isang layunin ay ang mapagana ito nang hindi nangangailangan ng elevation, ibig sabihin, hindi na kailangang mag-prompt ang Codex sa user para sa mga pribilehiyo ng administrator para lang i-set up o patakbuhin ang sandbox. Ang ibig sabihin noon ay ang pagtukoy sa kung paano magtakda ng mga makatwirang limitasyon sa dalawang bagay: pagsusulat sa file at pag-access sa network.

Kung hindi namin lilimitahan ang pagsusulat sa file, magkakaroon kami ng isyu sa kaligtasan. Kung sobra naman ang paglilimita, masasaktan ang produktibidad ng user dahil kailangan nitong palaging humingi ng pag-apruba. Para lutasin ito, umasa kami sa dalawang batayang elemento ng Windows: mga SID at write-restricted token.

Ang SID, o pantukoy ng seguridad, ay ang pagkakakilanlang iniuugnay ng Windows sa mga pahintulot. May SID ang bawat user, may mga SID ang mga grupo, at kahit ang iisang sesyon ng pag-login ay nagkakaroon ng sarili nitong SID. Halimbawa, maaaring magkaroon ang kasalukuyang naka-log in na sesyon ng SID gaya ng S-1-5-5-X-Y. Ang SID na nakatalaga sa pangkat ng mga lokal na administrator ay maaaring S-1-5-32-544.

Pinapayagan ka rin ng Windows na gumawa ng synthetic SID na hindi tumutugma sa totoong user pero maaari pa ring lumitaw sa mga ACL (access control list), na tumutukoy kung sino ang maaaring magbasa/magsulat/magpatupad ng mga partikular na file o directory. Dahil dito, kapaki-pakinabang na primitive ang mga SID para sa aming sandbox: makakagawa kami ng mga SID na eksklusibo para gamitin ng Codex sandbox, nang hindi nakikialam sa iba pang bagay sa makina.

Ang mga write-restricted token ay mga bagay na panseguridad sa Windows na tumutukoy sa pagkakakilanlan at mga pribilehiyo para sa isang tumatakbong proseso. Tinutukoy ng mga ito kung anong mga aksyon ang maaaring isagawa ng isang proseso. Ang write-restricted token ay isang partikular na uri ng token ng proseso na nagpapagawa sa Windows ng karagdagang pagsusuri sa access sa mga operasyon sa pagsusulat.

Para magtagumpay ang isang write, kailangang pumasa ang dalawang pagsusuri:

1. Dapat pahintulutan ito ng normal na pagkakakilanlan ng user (ang “owner” ng token)
2. Dapat bigyan ng access ang kahit isa sa mga SID na nasa listahan ng pinaghihigpitang SID ng token.

Sa praktika, hinayaan kami ng mga check na ito na gamitin ang mga ACL para tukuyin nang eksakto kung saan maaaring baguhin ng sandbox ang filesystem, na nagbigay ng antas ng detalye na kailangan namin sa mga gawaing pagsusulat.

Sa tulong ng mga SID at write-restricted token, ganito gumana ang aming unelevated sandbox:

1. Gumawa ang setup ng sandbox ng synthetic SID na tinawag na sandbox-write.
2. Ang sandbox-write SID ay binigyan ng access na magsulat, magpatakbo, at magtanggal sa
   1. Kasalukuyang gumaganang directory
   2. Anumang karagdagang writable_roots na naka-configure sa config.toml.
3. Tahasang ipinagbawal ng setup ng sandbox sa parehong SID ang access sa pagsusulat sa mga lokasyong “read-only within writable” gaya ng:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Naglunsad ang Codex ng mga command sa ilalim ng write-restricted token na ang listahan ng pinaghihigpitang SID ay may kasamang Everyone, the current logged in session SID, and the sandbox-write synthetic SID.

Epektibong nalutas ng daloy na ito ang paglilimita sa pagsusulat ng file at mukhang may potensyal. Ngayon, kailangan naman namin ng solusyon para limitahan ang access ng sandbox sa network.

Mahalagang bahagi ng sandbox ang paglilimita sa access sa network; kung wala ito, maaaring maglabas ng data ang mapaminsalang code mula sa makina papunta sa internet. Dahil gusto naming iwasan ang pangangailangan ng elevation, limitado ang mga opsyon namin para mahigpit na harangan ang trapiko sa network. Ang mga tool na gusto naming gamitin, gaya ng Windows Firewall, ay kadalasang hindi naii-install nang walang mga pahintulot ng admin.

Dahil walang Windows Firewall bilang opsyon, nalimitahan namin ang maaari naming kontrolin. Sinubukan naming gawing fail-closed ang child environment para sa mga uri ng tool na gumagamit ng network na aktuwal na ginagamit ng mga developer, para ang mga Git command, package installer, atbp. ay mabigo sa sandbox at kailangan munang aprubahan ng user ang anumang operasyong kumokonekta sa internet. Ang ideya ay gawing hindi magagamit ang mga halatang escape hatch: ipadala ang proxy-aware na trapiko sa isang patay na endpoint, gawin ding ganoon ang HTTP(S) na paglilipat ng Git, at gawing agaran ang pagkabigo ang Git over SSH. Bukod pa roon, idinagdag namin sa unahan ng PATH ang maliit na directory na denybin at inayos muli ang pagkakasunod-sunod ng PATHEXT upang malutas muna ang mga stub na script ng SSH at SCP bago ang mga tunay na binary.

Halimbawa, narito ang ilan sa mga partikular na environment override na ginamit namin para limitahan ang access sa network:

• 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

Nahuli nito ang maraming normal na trapikong dulot ng tool, pero payo lamang ito. Maaaring balewalain ng isang proseso ang environment, laktawan ang PATH, o diretsong magbukas ng mga socket—masyadong mapanganib.

Gaya ng anumang nakakapukaw-interes na implementasyon ng software, may ilang bentaha at disbentaha ang unang prototype. Bagama't nagawa nito ang trabaho gamit lamang ang ilang karaniwang kakayahan ng Windows, pinayagan ang napakalinaw at detalyadong pagsusulat sa filesystem, at tumakbong unelevated—na nagbawas sa pangangailangang tanggapin ng mga user ang labis na mga elevation prompt o maging mga admin sa kanilang lokal na makina—mayroon itong ilang seryosong kahinaan, na ang ilan ay nag-alis dito sa konsiderasyon bilang aming huling disenyo:

• Bilis ng setup: Maaaring magastos ang paglalapat ng mga ACL sa workspace depende sa topology ng directory ng workspace.
• Footprint: Naglapat kami ng mga totoong ACL sa system ng developer, bagama't hindi naman ito partikular na mapanghimasok dahil ang lahat ng inilapat na ACL ay nauukol sa custom na synthetic SID na ginawa para rito at ginagamit lamang ng sandbox.
• Semantika na mahirap baguhin: Ang ibig sabihin ng pagdepende sa mga ACL para sa mga paghihigpit na nakabatay sa file ay magastos at kumplikado ang pagbabago sa semantika ng sandbox. Samantalang sa macOS, maaari naming dinamikong baguhin kung paano namin binubuo ang .sbpl file na ginagamit upang i-configure ang Seatbelt, maaaring mangailangan ang Windows sandbox ng mabagal at masinsinang operasyon upang isaayos ang mga ACL.
• Mahina ang proteksyon ng network. Gaya ng nabanggit kanina, ito ay “advisory,” tiyak na malalampasan ng ilang program na may sarili nilang networking stack, at hindi ito dinisenyong tumagal laban sa mapaminsalang code.

Ang unang tatlong isyu ay likas sa isang custom na implementasyon ng sandbox na sapat ang kakayahang umangkop para sa mga agentic na daloy. Iba naman ang kuwento ng pagpigil sa network.

Bukod sa madaling pag-iwas ng mapaminsalang agent sa pagpigil sa network na batay sa environment, marami ring code/binary na may mabuting layunin ang makakaiwas dito kung hindi nila igagalang ang mga environment proxy variable, o kung gumamit sila ng sarili nilang network code na batay sa socket. Naisip naming sapat ang aspetong ito para isaalang-alang ang pamumuhunan sa mas mahusay na sandbox mode.

Para makakuha ng mas mahusay na pagpigil sa network, gusto naming gamitin ang Windows Firewall, na nagpapahintulot sa aming harangan ang palabas na trapiko sa network para sa mga user o program. Sa kasamaang-palad, hindi kami makagawa nang epektibo at gumaganang panuntunan ng firewall na naaangkop lamang sa mga command na nilikha ng Codex harness sa ilang dahilan:

• Hindi pinapayagan ng Windows na itugma ang panuntunan ng firewall sa hindi pangunahing pagkakakilanlan ng pinaghihigpitang token. Ibig sabihin, hindi namin mailalapat ang panuntunan ng firewal sa “anumang token kung saan kasama ang aming synthetic SID sa listahan ng pinaghihigpitang SID nito.”
• Bagama't pwede kaming gumawa ng pantuntunan ng firewall na tumutugma sa partikular na binary, pinapayagan lang kami nitong limitahan ang networking para sa codex.exe mismo. Hindi ito malalapat sa mga prosesong ini-spawn ng agent sa ngalan ng user, gaya ng mga proseso ng Git o Python.
• May maling istraktura rin ang iba pang mga dimensyon ng pagtutugma ng firewall. Tumutugma pa rin ang mga panuntunang saklaw ng user sa aktuwal na Windows user sa unelevated design, hindi lang sa restricted child. Masyadong malawak ang mga panuntunan sa program path: kaya nilang i-block ang codex.exe o python.exe sa pangkalahatan, pero hindi ang partikular na naka-sandbox na pagpapatakbong ito ng python.exe. Ang mga panuntunang nakabatay sa port o address ay lubos ding maling patakaran. Halimbawa, hindi namin nilayong harangan ang port 443; nilayon naming harangan ng arbitrary outbound access para sa partikular na pinaghihigpitang process tree na ito.

Para mailapat ang panuntunan ng firewall nang partikular sa aming mga naka-sandbox na command, kinailangan naming patakbuhin ang mga ito bilang hiwalay na principal, hindi bilang “totoong” user. Dinala kami ng paraang ito sa bagong landas, kung saan niluwagan namin ang aming limitasyong “walang elevation.”

Ang susunod na iterasyon ng sandbox, na siyang kasalukuyan naming implementasyon, ay nangangailangan ng mas mataas na mga pahintulot ng admin sa panahon ng pag-setup. Samakatuwid, tinutukoy ko ito bilang “ang elevated na sandbox.” Sa hangganan kung saan nag-spawn ang Codex ng command sa system, ang elevated na sandbox ay mukhang kapareho ng unelevated. Pinapatakbo pa rin nito ang mga child process sa ilalim ng pinaghihigpitang token—katulad din ng write_restricted token na may parehong listahan ng pinaghihigpitang SID na [Everyone, Logon, Synthetic]—gayunpaman, ang principal ng token na ito ay hindi na ang aktuwal na Windows user kundi isa sa dalawang lokal na user na ginawa mismo ng Codex:

• CodexSandboxOffline (ang pinupuntirya ng mga panuntunan ng firewall)
• CodexSandboxOnline (ang hindi pinupuntirya ng mga panuntunan ng firewall)

Ang mukhang maliit na detalyeng ito ay may malalaking implikasyon sa sandbox, sa kung sino ang makakagamit nito, at sa pagiging kumplikado ng setup at pagpapatupad sa runtime nito.

Kahawig nito sa paningin ang unelevated prototype, kasama ang pagdagdag ng mga panuntunan ng firewall at isang dedikadong user ng Windows, na siyang aktuwal na nagpapatakbo ng mga command. (Gayunman, ang ibig sabihin ng pagdagdag ng mga bagong konseptong ito ay mas marami nang pagsisikap sa pag-setup na kailangang gawin bago makapagsimulang magpatakbo at magprotekta ng mga command ang sandbox.)

May simpleng hakbang sa pag-setup ang unelevated sandbox na disenyo, pero medyo maliit lang ito:

• Gumawa ng synthetic SID kung kailangan
• Maglapat ng mga ACL para sa synthetic SID na sandbox-write

Gayunman, mas marami nang kailangang gawin ang elevated sandbox.

• Gumawa ng synthetic SID, kung hindi pa ito nalilikha
• Gumawa ng mga online at offline na sandbox user, kung hindi pa nalilikha
• I-store nang lokal ang mga kredensyal ng mga bagong likhang user at i-encrypt gamit ang Windows Data Protection API (DPAPI) sa lugar na hindi talaga mababasa ng mga sandbox user
• Gumawa ng mga panuntunan ng firewall na humaharang sa lahat ng palabas na access sa network para sa user na CodexSandboxOffline o, kung umiiral na ang mga ito, tiyaking tama ang mga ito

May karagdagang komplikasyon sa yugto ng pag-setup. Inaasahang may read access ang sandbox ng Codex na katumbas ng aktuwal na Windows user. Sa unelevated sandbox, kung saan ang principal SID ng pinaghihigpitang token ay ang Windows user, naisakatuparan ito. Gayunpaman, hindi iyon kusang kasama kapag naging bagong user ng CodexSandbox ang principal. Maraming nauugnay na directory sa Windows ang magbibigay ng mga pahintulot na read/execute sa “Mga Awtentikadong User”. Isang kapansin-pansing halimbawa ang directory ng profile ng user. Sa default na setting, hindi mababasa ng mga user ng Windows ang mga directory ng profile ng ibang mga user ng Windows, kaya kahit ang mga simpleng operasyon ng pagbasa ng file ay mabibigo sa maraming sitwasyon.

Para tugunan ito, nagdagdag kami ng isa pang layer sa proseso ng pag-setup ng sandbox—isa para magbigay ng mga read ACL sa mga sandbox user kung saan maaaring wala pa ang gayong mga ACL. Halimbawa, sa ilang karaniwang ginagamit na directory ng Windows:

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

Dahil best-effort ang listahang ito ng mga directory at maaaring maging magastos ang pag-install ng mga ACL sa bawat isa, pinapatakbo namin ang lohikang ito nang asynchronous para ang hakbang sa pag-setup ng sandbox, na nakakaharang sa mga user, ay hindi na kailangang maghintay na matapos ang mga ito.

Isinama namin ang lohika ng pag-setup sa sarili nitong binary, bahagyang para tumawid lang sa hangganan ng UAC kapag kinakailangan. Ngunit ang mas malalim na dahilan ay pang-arkitektura: ang setup ng sandbox ay may pangunahing naiibang tungkulin kumpara sa codex.exe. Ang pagpapanatili ng lohika ng pag-setup ng sandbox sa dedikadong binary ay nagbigay-daan para manatiling normal at unelevated na harness ang codex.exe; napigilan ang pagbigat ng codex.exe ng Windows-only na setup machinery sa iba pang platform; nahiwalay ang mas matagal na pagsisikap sa pag-setup mula sa itatagal ng pangunahing proseso; at nagbigay sa amin ng lugar para hawakan ang iba't ibang setup path na kailangan ng sandbox.

Dahil sa paraan ng paggana ng mga hangganan sa pag-log in ng user at token sa Windows, hindi na namin maipagpatuloy ang paglikha ng pinaghihigpitang token at paglulunsad ng proseso sa ilalim nito gaya ng nagawa namin sa unelevated sandbox. Para aktuwal na makapaglunsad ng mga command bilang ibang user ng Windows, ang una naming ideya ay ang sumusunod na daloy:

• Tumatakbo ang codex.exe bilang aktuwal na user ng Windows. Pagkatapos, nang magkakasunod, ang Codex:
  • Tinatawag ang LogonUserW(...) para sa sandbox user.
  • Tinatawag ang CreateRestrictedToken(...) sa token ng sandbox-user na iyon.
  • Gamit ang pinaghihigpitang sandbox-user token na iyon, tinatawag ang CreateProcessAsUserW(...) upang ilunsad ang huling child.

Sa aktuwal na paggamit, hindi gumana ang ninanais na daloy na iyon dahil sa hadlang sa pribilehiyo sa CreateProcessAsUserW(...). Ang ibig sabihin ito ay maaaring gumawa ang codex.exe ng pinaghihigpitang token para sa sandbox user, ngunit hindi nito maaasahang mailunsad ang isang child process gamit ang token na iyon mula sa panig ng totoong user ng hangganan. Kailangan namin ng prosesong tumatakbo na bilang sandbox user—magbibigay-daan ito na mangyari ang hakbang ng paghihigpit at ang panghuling pag-spawn sa panig ng sandbox user ng hangganan sa halip na sa panig ng totoong user.

Ang kinakailangang iyon ang humantong sa codex-command-runner.exe, isang bagong binary na ang tanging trabaho ay gumawa ng pinaghihigpitang token at i-spawn ang hiniling na command. Sa halip na hilingin sa codex.exe na gawin ang buong daloy mismo (totoong user → sandbox user → pinaghihigpitang token → child process), hinati namin ang daloy sa dalawa:

Bahagi 1

• tumatawag ang codex.exe sa CreateProcessWithLogonW(...) para ilunsad ang codex-command-runner.exe bilang sandbox user, nang hindi pa gumagamit ng pinaghihigpitang token.

Bahagi 2

• Sa loob ng runner, binubuksan ng OpenProcessToken(GetCurrentProcess(), ...) ang sariling token ng runner, na pag-aari na ng sandbox user.
• Tumatawag ang runner sa GetTokenInformation(...) para kunin ang sandbox logon SID, pagkatapos ay sa CreateRestrictedToken(...) para buuin ang panghuling pinaghihigpitang token.
• Nasa loob pa rin ng runner, tumatawag ito sa CreateProcessAsUserW(...) gamit ang pinaghihigpitang token na iyon para ilunsad ang totoong child.

Sinabi ni Albert Einstein, “Everything should be made as simple as possible, but no simpler.” Sa diwang iyon, sapat na nalutas ng aming disenyo ang bawat problema. May apat na layer ang panghuling arkitektura na natalakay na namin dati:

• ang codex.exe mismo
• ang codex-windows-sandbox-setup.exe para sa lahat ng trabahong may kaugnayan sa elevated na setup
• ang codex-command-runner.exe para sa pagpapatakbo ng mga command na may pinaghihigpitang token
• Ang child process

Nang una kong lapitan ang proyektong ito, wala akong malinaw na pakiramdam kung saan ito hahantong. Ang diskarte ko ay magsimula sa pamamagitan ng paggamit ng kakayahan sa sandboxing sa hangganan sa pagitan ng Codex at ng operating system. Malapit itong tumutugma sa paraan ng pagpapatupad ng sandbox ng Codex sa MacOs at Linux.

Habang mas marami akong natututuhan tungkol sa mga partikular na tool na ibinibigay ng Windows, at sa pamamagitan ng dose-dosenang desisyong tumitimbang sa seguridad at kadalian ng paggamit, lumago ang system sa kasalukuyan nitong anyo—maramihang binary, mga custom na user, mga panuntunan ng firewall, isang elevated na hakbang sa pag-setup, mga asynchronous na proesso, at marami pang iba.

Hindi ito partikular na simpleng system, pero bawat bahagi ng pagiging kumplikado ay idinagdag dahil kinakailangan, para makabuo ng sandbox na parehong ligtas at, hangga't maaari, hindi sagabal sa user.

Sa pagsisikap na maghatid ng magandang karanasan para sa mga user ng Codex sa Windows, layunin naming gumawa ng bagay na ligtas nang hindi isinasakripisyo ang kapakinabangan—ang buong punto ng paggamit ng Codex ay ang makapagtrabaho ang mga agent nang hindi nangangailangan ng palagi mong atensyon.

Isa sa pinakamalaking aral mula sa proyektong ito ay na walang iisang primitive na ibinigay sa amin ang Windows na malinis na tumutugma sa “ligtas na awtonomong coding agent.” Pinagsama-sama namin ang ilang tool at konsepto para makabuo ng magkakaugnay na sistema. Ang ilang maagang ideya ay nauwi sa wala. Ang panghuling disenyo ay paghahalo ng mga naunang prototype na bawat isa ay lumutas sa bahagi ng problema.

Ang isa pang aral ay na ibang klase ang seguridad para sa coding agent kaysa sa mas klasikong application ng seguridad. Kailangang gumana ang Codex para sa totoong daloy ng trabaho ng developer. Ang gawaing engineering ay tungkol sa pagtitimbang ng pagkakatugma sa mga agentic workload laban sa tunay na pagpapatupad. Ang tensyong iyon ang humubog sa mga kapalit sa panghuling disenyo.

Gusto mo bang makitang gumagana ang Codex sandbox ? Subukan ito⁠.