Gradnja varnega in učinkovitega peskovnika za omogočanje Codexa v sistemu Windows

Ko sem se septembra 2025 pridružil inženirski ekipi Codexa, Codex za Windows še ni imel peskovniške implementacije, kar je pomenilo, da so morali uporabniki sistema Windows pri uporabi kodirnih agentov družbe OpenAI izbirati med dvema slabima možnostma:

1. Skoraj vsak ukaz, ki ga je želel izvesti kodirni agent, so morali odobriti sami (tudi branje), kar je bilo neučinkovito in nadležno. Ena glavnih prednosti Codexa je prav v tem, da vam ni treba samim opravljati vsega zamudnega dela.
2. Lahko so omogočili način Full Access: Codexu so dovolili izvajanje vseh ukazov brez odobritev ali omejitev, s čimer so odpravili trenje, vendar tudi zmanjšali nadzor.

Codex⁠, naš kodirni agent, deluje na prenosnikih razvijalcev – prek vmesnika z ukazno vrstico (CLI), razširitve za integrirano razvojno okolje ali namizne aplikacije. Skrbi za pogovor med človekom za tipkovnico in modelom, ki inferenco izvaja v oblaku.

Codex privzeto uporablja dovoljenja dejanskega uporabnika, zato lahko naredi vse, kar lahko naredi ta uporabnik. To je zmogljivo, hkrati pa potencialno nevarno. Kodirni model lahko upravljalnemu okolju naroči lokalno izvajanje ukazov, na primer zagon testov, branje ali urejanje datoteke ali ustvarjanje veje Git. Zato poskuša privzeti način Codexa vzpostaviti pravo ravnotežje med učinkovitostjo in varnostjo. V tem načinu lahko Codex bere datoteke skoraj kjer koli in piše datoteke znotraj vašega delovnega prostora (tj. imenika, v katerem izvajate Codex), dostopa do interneta pa nima, razen če to izrecno zahtevate. Da bi Codex lahko samodejno omejeval pisanje datotek in dostop do omrežja na varne meje, potrebuje peskovniško okolje, ki te omejitve dejansko uveljavlja.

Peskovnik je omejeno izvajalno okolje. Ko razvijalec uporablja Codex, operacijski sistem njegovega računalnika zažene ukaz z zmanjšanimi dovoljenji, te omejitve pa se prenesejo tudi na podrejene procese. Vsak ukaz Codexa je že od začetka izveden v peskovniku, vsi procesi, ki iz njega izhajajo, pa ostanejo znotraj iste meje.

Za učinkovit peskovnik Codex potrebuje izolacijske funkcionalnosti, ki jih uveljavlja operacijski sistem računalnika. Nekateri operacijski sistemi imajo orodja, ki to dobro omogočajo (npr. Seatbelt v macOS ter seccomp ali bubblewrap v Linuxu), Windows pa take zmožnosti trenutno ne ponuja privzeto.

Da bi bil Codex v sistemu Windows enako varen in prijeten za uporabo kot drugje, smo morali peskovnik implementirati sami.

Windows ponuja nekaj orodij in osnovnih gradnikov za izolacijo. Nobeden ni povsem ustrezal našim zahtevam, vseeno pa smo preučili več možnih rešitev, predvsem AppContainer, Windows Sandbox in označevanje z Mandatory Integrity Control.

AppContainer

• Kaj je to: AppContainer je nativni peskovnik sistema Windows, izolacijski model na osnovi zmožnosti, zasnovan za aplikacije, ki že vnaprej natančno vedo, do česa potrebujejo dostop.
• Zakaj je bil zanimiv: Ker vzpostavi dejansko mejo na ravni operacijskega sistema, ne le omejitev po najboljših močeh.
• Zakaj ga nismo uporabili: Codex ni ena sama ozko zamejena aplikacija. Upravlja odprte razvijalske delotoke: lupine, Git, Python, upravljalnike paketov, orodja za gradnjo in katere koli druge binarne datoteke, za katere agent presodi, da jih potrebuje. Zato AppContainer v praksi ni ustrezal obliki tega problema. Izolacija je bila močna, vendar namenjena veliko ožjemu razredu delovnih obremenitev kot »agent naj deluje kot razvijalec«.

Windows Sandbox

• Kaj je to: Windows Sandbox je Microsoftov začasni lahki navidezni računalnik. Odpre se sveže namizje sistema Windows z močno izolacijsko mejo, vse, kar v njem naredite, pa po koncu seje izgine.
• Zakaj je bil zanimiv: Razlogi so očitni – z poljubno programsko opremo je veliko bolj združljiv kot AppContainer, z varnostnega vidika pa zagotavlja bistveno močnejše zaprto okolje.
• Zakaj ga nismo uporabili: Codex mora delovati neposredno v uporabnikovi dejanski delovni kopiji, z njegovimi orodji in v njegovem okolju, ne pa v ločenem začasnem namizju, ki bi ga bilo treba nastaviti ter povezovati z gostiteljskim sistemom. Poleg tega je imel temeljno produktno omejitev: Windows Sandbox sploh ni na voljo v izdajah Windows Home.

Označevanje ravni integritete z Mandatory Integrity Control (MIC)

• Kaj je to: Windows pozna »ravni integritete«, na primer nizko, srednjo in visoko, s katerimi določa, koliko sistem zaupa objektom in procesom. Osnovno pravilo je, da proces z nižjo integriteto ne more pisati v objekt z višjo ravnjo integritete, tudi če bi mu to sicer dovoljeval običajni seznam za nadzor dostopa (ACL). Proces z nizko integriteto se na primer obravnava kot manj zaupanja vreden, zato mu Windows prepreči pisanje v običajne objekte s srednjo integriteto, razen če so ti izrecno ponovno označeni tako, da to dovoljujejo.
• Zakaj je bilo zanimivo: Na papirju je bil MIC videti eleganten – Codex bi zagnali z nizko integriteto, korene, v katere sme pisati, ponovno označili kot nizko integritetne, Windows pa bi nato sam uveljavljal prepoved pisanja povsod drugje. Tako bi dobili rešitev brez skrbniških pravic, podprto z dejanskim mehanizmom operacijskega sistema.
• Zakaj ga nismo uporabili: Tako kot ACL-ji tudi oznake integritete spreminjajo dejanski datotečni sistem gostitelja, pri čemer je pomenska sprememba v tem primeru še posebej široka. Če delovni prostor označite kot nizko integriteten, to ne pomeni samo »Codex lahko piše sem«. Pomeni tudi, da lahko tja pišejo nizko integritetni procesi na splošno. Na dejanskem računalniku razvijalca se tako uporabnikova delovna kopija spremeni v nizko integritetni ponor za gostitelja, kar je veliko bolj tvegano kot skrbno ciljno dodeljevanje ACL-jev eni zasnovi peskovnika. Tudi če razvijalska orodja s srednjo integriteto še naprej delujejo, se temeljni model zaupanja delovnega prostora spremeni na način, ki ga je težko omejiti in še težje upravičiti.

Ko smo vse možnosti ocenili kot neizvedljive, smo začeli oblikovati lastno rešitev, s katero bi uporabnikom sistema Windows omogočili dobro izkušnjo s Codexom.

V prvem delujočem prototipu smo potrebno izolacijo implementirali s kombinacijo konceptov in orodij sistema Windows. Že od začetka je bil eden od ciljev, da rešitev deluje brez povišanih pravic. Codex torej uporabnika ne bi smel pozivati k skrbniškim pravicam samo zato, da bi nastavil ali zagnal peskovnik. Zato smo morali najti način, kako smiselno omejiti dve stvari: pisanje datotek in dostop do omrežja.

Če pisanja datotek sploh ne bi omejili, bi nastalo varnostno tveganje. Če bi ga omejili preveč, bi peskovnik škodil produktivnosti uporabnikov, ker bi moral nenehno zahtevati odobritve. To smo rešili z dvema pomembnima gradnikoma sistema Windows: varnostnimi identifikatorji (SID-ji) in žetoni z omejenim pisanjem.

SID oziroma varnostni identifikator je identiteta, ki jo Windows poveže z dovoljenji. Vsak uporabnik ima svoj SID, skupine imajo svoje SID-je, svoj SID pa dobi celo posamezna prijavna seja. Na primer, trenutna prijavna seja ima lahko SID, kot je S-1-5-5-X-Y. SID, dodeljen lokalni skupini skrbnikov, je lahko S-1-5-32-544.

Windows omogoča tudi ustvarjanje sintetičnih SID-jev, ki ne ustrezajo dejanskemu uporabniku, vendar se lahko vseeno pojavijo v ACL-jih (seznamih za nadzor dostopa), ki določajo, kdo lahko bere, piše ali izvaja določene datoteke oziroma imenike. SID-ji so zato uporaben osnovni gradnik za naš peskovnik: ustvarimo lahko SID-je, namenjene izključno peskovniku Codexa, ne da bi posegali v kar koli drugega v računalniku.

Procesni žetoni so varnostni objekti v sistemu Windows, ki določajo identiteto in pravice procesa, ki se izvaja. Določajo, katera dejanja sme proces izvesti. Žeton z omejenim pisanjem je posebna vrsta procesnega žetona, zaradi katere Windows pri operacijah pisanja izvede dodatno preverjanje dostopa.

Da zapis uspe, morata biti uspešni dve preverjanji:

1. Običajna uporabniška identiteta (»lastnik« žetona) mora imeti dovoljenje za to
2. Dostop mora biti odobren tudi vsaj enemu SID-ju na seznamu omejenih SID-jev v žetonu

V praksi nam ta preverjanja omogočajo, da z ACL-ji natančno določimo, kje sme peskovnik spreminjati datotečni sistem. To nam je pri operacijah pisanja dalo potrebno natančnost.

S SID-ji in žetoni z omejenim pisanjem je naš peskovnik brez povišanih pravic deloval tako:

1. Nastavitev peskovnika je ustvarila sintetični SID z imenom sandbox-write.
2. SID-u sandbox-write je bil dodeljen dostop za pisanje, izvajanje in brisanje do
   1. Trenutni delovni imenik
   2. Morebitne dodatne korenske poti writable_roots, konfigurirane v datoteki config.toml.
3. Nastavitev peskovnika je istemu SID-ju izrecno zavrnila dostop za pisanje v mesta »samo za branje znotraj zapisljivega«, kot so:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex je ukaze zaganjal pod žetonom z omejitvijo pisanja, katerega seznam omejenih SID-jev vključuje Everyone (Vsi), SID trenutne prijavljene seje in sintetični SID sandbox-write.

Ta potek je učinkovito rešil omejevanje pisanja datotek in se je zdel obetaven. Rešiti smo morali še omejevanje omrežnega dostopa peskovnika.

Omejevanje omrežnega dostopa je pomemben del peskovnika; brez njega bi lahko zlonamerna koda eksfiltrirala podatke iz računalnika v internet. Ker smo se želeli izogniti zahtevi po povišanih pravicah, smo imeli za zanesljivo blokiranje omrežnega prometa na voljo malo možnosti. Orodij, ki smo jih želeli uporabiti, na primer Windows Firewall, praviloma ni bilo mogoče namestiti brez skrbniških dovoljenj.

Ker Požarni zid Windows ni bil na voljo kot možnost, smo omejili, kaj smo lahko nadzorovali. Podrejeno okolje smo poskušali nastaviti tako, da bi se pri vrstah omrežnih orodij, ki jih razvijalci dejansko uporabljajo, varno zaprlo ob napaki. Ukazi Git, nameščevalniki paketov in podobna orodja bi zato v peskovniku odpovedali, uporabnik pa bi moral odobriti vsako operacijo z dostopom do interneta. Zamisel je bila zapreti najbolj očitne izhode: promet, ki upošteva posredniške strežnike, preusmeriti na mrtvo končno točko, enako narediti za Gitov prenos prek HTTP(S) in doseči, da Git prek SSH odpove takoj. Poleg tega smo na začetek spremenljivke PATH dodali majhen imenik denybin in preuredili PATHEXT, tako da bi se nadomestni skripti SSH in SCP razrešili pred pravimi izvedljivimi datotekami.

To je, na primer, nekaj konkretnih preglasitev okolja, s katerimi smo omejevali omrežni dostop:

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

S tem smo prestregli veliko običajnega prometa, ki ga ustvarjajo orodja, vendar je bila omejitev še vedno samo priporočilna. Proces bi lahko prezrl okolje, obšel PATH ali preprosto neposredno odprl vtičnice, kar je bilo preveč tvegano.

Kot pri vsaki zanimivi implementaciji programske opreme je imel prvi prototip svoje prednosti in slabosti. Nalogo je sicer opravil z le nekaj standardnimi zmožnostmi sistema Windows, omogočal zelo izrecno in natančno pisanje v datotečni sistem ter deloval brez povišanih pravic. Uporabnikom zato ni bilo treba sprejemati pretiranega števila pozivov za povišanje pravic ali imeti skrbniških pravic na lokalnem računalniku. Vendar je imel tudi resne pomanjkljivosti, nekatere tako pomembne, da ni mogel postati naša končna zasnova:

• Hitrost nastavitve: Uporaba seznamov za nadzor dostopa (ACL-jev) v delovnem prostoru je lahko draga, odvisno od topologije imenika delovnega prostora.
• Odtis: Dejanske ACL-je smo uporabili v razvijalčevem sistemu, čeprav odtis ni posebej invaziven, saj se vsi uporabljeni ACL-ji nanašajo na namensko ustvarjen sintetični SID, ki ga uporablja samo peskovnik.
• Semantika, ki jo je težko spreminjati: Ker omejitve na ravni datotek temeljijo na ACL-jih, je spreminjanje semantike peskovnika drago in zapleteno. V sistemu macOS lahko dinamično spreminjamo način generiranja datoteke .sbpl, ki se uporablja za konfiguracijo orodja Seatbelt. V sistemu Windows pa bi lahko prilagajanje ACL-jev za peskovnik zahtevalo počasno in zahtevno operacijo.
• Zaščita omrežja je šibka. Kot že omenjeno, je bila »priporočilna«, nekateri programi z lastnim omrežnim skladom bi jo zagotovo obšli, poleg tega pa ni bila zasnovana tako, da bi vzdržala nasprotniško kodo.

Prve tri težave so neločljivo povezane z lastno implementacijo peskovnika, ki mora biti dovolj prilagodljiva za agentske poteke. Pri omejevanju omrežja pa je bila težava drugačna.

Zlonamerni agent bi lahko omrežno omejitev na osnovi okolja zlahka obšel. Poleg tega bi jo obšla tudi številna dobronamerna koda oziroma številne dobronamerne binarne datoteke, če ne bi upoštevale okoljskih spremenljivk za posredniški strežnik ali če bi uporabljale lastno omrežno kodo na osnovi vtičnic. Menili smo, da je že to dovolj dober razlog za vlaganje v boljši način peskovnika.

Za boljše omejevanje omrežja smo želeli uporabiti Windows Firewall, ki omogoča blokiranje odhodnega omrežnega prometa za uporabnike ali programe. Žal iz več razlogov nismo mogli učinkovito ustvariti delujočega pravila požarnega zidu, ki bi veljalo samo za ukaze, ki jih zažene upravljalno okolje Codexa:

• Windows ne omogoča, da bi se pravilo požarnega zidu ujemalo z neprimarno identiteto omejenega žetona. To pomeni, da pravila požarnega zidu nismo mogli uporabiti za »kateri koli žeton, ki na seznamu omejenih SID-jev vključuje naš sintetični SID«.
• Lahko bi ustvarili pravilo požarnega zidu, ki se ujema z določeno binarno datoteko, vendar bi s tem omejili omrežje samo za codex.exe. Pravilo ne bi veljalo za procese, ki jih agent zažene v imenu uporabnika, na primer za procese Git ali Python.
• Tudi druge možnosti ujemanja pravil požarnega zidu niso ustrezale tej težavi. Pravila, omejena na uporabnika, so se v zasnovi brez povišanih pravic še vedno ujemala z dejanskim uporabnikom sistema Windows, ne le z omejenim podrejenim procesom. Pravila za poti programov so bila preveč groba: na splošno so lahko blokirala codex.exe ali python.exe, ne pa tega posameznega zagona python.exe v peskovniku. Tudi pravila na osnovi vrat ali naslovov so temeljila na napačni politiki. Nismo, na primer, želeli blokirati vrat 443; želeli smo blokirati poljuben odhodni dostop za to konkretno omejeno drevo procesov.

Da bi pravilo požarnega zidu uporabili posebej za naše peskovniške ukaze, smo jih morali izvajati kot ločenega varnostnega subjekta, ne kot »dejanskega« uporabnika. Ta pristop nas je usmeril na novo pot, na kateri smo opustili strogo omejitev »brez povišanih pravic«.

Naslednja iteracija peskovnika, ki je naša trenutna implementacija, pri nastavitvi zahteva povišana skrbniška dovoljenja. Zato ji pravim »peskovnik s povišanimi pravicami«. Na meji, kjer Codex v sistemu zažene ukaz, je peskovnik s povišanimi pravicami videti enako kot peskovnik brez povišanih pravic. Še vedno izvaja podrejene procese pod omejenim žetonom — podobno kot žeton write_restricted z istim seznamom omejenih SID-ov [Everyone, Logon, Synthetic]— vendar varnostni subjekt tega žetona ni več dejanski uporabnik sistema Windows, temveč eden od dveh lokalnih uporabnikov, ki ju je ustvaril sam Codex:

• CodexSandboxOffline (ta je cilj pravil požarnega zidu)
• CodexSandboxOnline (ta ni cilj pravil požarnega zidu)

Ta na videz majhna podrobnost ima v resnici velike posledice za peskovnik, za to, kdo ga lahko uporablja, ter za zapletenost njegove nastavitve in izvajanja.

Vizualno je podoben prototipu brez povišanih pravic, le da uvaja pravila požarnega zidu in namenskega uporabnika sistema Windows, ki dejansko izvaja ukaze. (Zaradi uvedbe teh novih konceptov pa je treba pred začetkom izvajanja peskovnika in zaščite ukazov opraviti več nastavitvenega dela.)

Zasnova peskovnika brez povišanih pravic je imela preprost nastavitveni korak, vendar je bil ta razmeroma majhen:

• Po potrebi ustvariti sintetični SID
• Uporabiti ACL-je za sintetični SID sandbox-write

Peskovnik s povišanimi pravicami pa mora narediti več.

• Ustvariti sintetični SID, če še ni ustvarjen
• Ustvariti spletnega in nespletnega uporabnika peskovnika, če še nista ustvarjena
• Lokalno shraniti poverilnice novo ustvarjenih uporabnikov in jih šifrirati z Windows Data Protection API (DPAPI) na mestu, ki ga uporabniki peskovnika dejansko ne morejo prebrati
• Ustvariti pravila požarnega zidu, ki blokirajo ves odhodni omrežni dostop za uporabnika CodexSandboxOffline, ali pa, če že obstajajo, preveriti, ali so pravilna

V fazi nastavitve je še ena posebnost. Od peskovnika Codexa se pričakuje, da ima bralni dostop, enakovreden dejanskemu uporabniku sistema Windows. V peskovniku brez povišanih pravic je bilo to doseženo, ker je bil SID varnostnega subjekta omejenega žetona uporabnik sistema Windows. Ko pa varnostni subjekt postane nov uporabnik CodexSandbox, tega ne dobimo samodejno. Številni relevantni imeniki v sistemu Windows dovoljenja za branje in izvajanje dodelijo skupini »Authenticated Users«. Pomemben primer je uporabnikov profilni imenik. Windows uporabnikom privzeto ne dovoli branja profilnih imenikov drugih uporabnikov, zato bi v številnih scenarijih odpovedalo že preprosto branje datotek.

Da bi to rešili, smo postopku nastavitve peskovnika dodali še eno plast — takšno, ki uporabnikom peskovnika podeli ACL-je za branje, kjer ti ACL-ji morda še ne obstajajo. Na primer v nekatere pogosto uporabljene imenike sistema Windows:

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

Ker je ta seznam imenikov zasnovan po najboljših močeh in je lahko nameščanje ACL-jev na vsakega od njih precej drago, to logiko izvajamo asinhrono. Tako nastavitvenemu koraku peskovnika, ki uporabnika blokira, ni treba čakati, da se dokonča.

Nastavitveno logiko smo zaprli v ločeno binarno datoteko, delno zato, da mejo nadzora uporabniškega računa (UAC) prečkamo samo takrat, ko je to potrebno. Globlji razlog pa je bil arhitekturni: nastavitev peskovnika ima povsem drugačno nalogo kot codex.exe. Ker smo logiko za nastavitev peskovnika prestavili v namensko binarno datoteko, je lahko codex.exe ostal običajno upravljalno okolje brez povišanih pravic; nastavitveni mehanizmi, vezani izključno na Windows, niso po nepotrebnem obremenjevali codex.exe na drugih platformah; dalj časa trajajoče nastavitveno delo ni bilo več vezano na življenjsko dobo glavnega procesa; hkrati pa smo dobili eno mesto za obravnavo različnih nastavitvenih poti, ki jih je potreboval peskovnik.

Zaradi načina, kako Windows obravnava meje med uporabniki in prijavnimi žetoni, nismo mogli več ustvariti omejenega žetona in z njim zagnati procesa, kot smo to lahko storili pri peskovniku brez povišanih pravic. Da bi ukaze dejansko zagnali kot drug uporabnik sistema Windows, smo si najprej zamislili naslednji potek:

• codex.exe se izvaja kot dejanski uporabnik sistema Windows. Nato Codex zaporedoma:
  • Pokliče LogonUserW(...) za uporabnika peskovnika.
  • Na žetonu tega uporabnika peskovnika pokliče CreateRestrictedToken(...).
  • S tako omejenim žetonom uporabnika peskovnika pokliče CreateProcessAsUserW(...), da zažene končni podrejeni proces.

V praksi ta želeni potek ni deloval, ker smo pri CreateProcessAsUserW(...) naleteli na oviro pri pravicah. To pomeni, da je lahko codex.exe ustvaril omejeni žeton za uporabnika peskovnika, vendar z njim ni mogel zanesljivo zagnati podrejenega procesa na strani dejanskega uporabnika te meje. Potrebovali smo proces, ki se je že izvajal kot uporabnik peskovnika. Tako bi se lahko omejevanje in končni zagon izvedla na strani uporabnika peskovnika, ne na strani dejanskega uporabnika.

Ta zahteva je privedla do codex-command-runner.exe, nove binarne datoteke, katere edina naloga je ustvariti omejen žeton in zagnati zahtevani ukaz. Namesto da bi od codex.exe zahtevali, da sam opravi celoten tok (resnični uporabnik → uporabnik peskovnika → omejeni žeton → podrejeni proces), smo tok razdelili na dva dela:

1. del

• codex.exe pokliče CreateProcessWithLogonW(...), da kot uporabnik peskovnika zažene codex-command-runner.exe, še brez uporabe omejenega žetona.

2. del

• Znotraj izvajalnika ukaz OpenProcessToken(GetCurrentProcess(), ...) odpre žeton izvajalnika, ki že pripada uporabniku peskovnika.
• Izvajalnik pokliče GetTokenInformation(...), da izlušči SID prijave v peskovnik, nato pa CreateRestrictedToken(...) za izdelavo končnega omejenega žetona.
• Še vedno znotraj izvajalnika nato pokliče CreateProcessAsUserW(...) s tem omejenim žetonom, da zažene dejanski podrejeni proces.

Albert Einstein je rekel: »Vse naj bo narejeno kar se da preprosto, vendar ne preprosteje.« V tem duhu je naš načrt ustrezno rešil vsak problem. Končna arhitektura ima štiri plasti, ki smo jih že obravnavali:

• codex.exe sam
• codex-windows-sandbox-setup.exe za obravnavo vsega dela, povezanega s povišano nastavitvijo
• codex-command-runner.exe za izvajanje ukazov z omejenim žetonom
• Podrejeni proces

Ko sem se prvič lotil tega projekta, nisem imel jasne predstave, kam bo pripeljal. Najprej sem začel instrumentirati zmožnost peskovnika na meji med Codexom in operacijskim sistemom. Ta pristop je zelo podoben načinu, kako je peskovnik Codexa implementiran v sistemih macOS in Linux.

Bolj ko sem spoznaval konkretna orodja, ki jih ponuja Windows, in ko smo skozi več deset odločitev tehtali med varnostjo ter preprostostjo uporabe, bolj je sistem rasel v današnjo obliko: več binarnih datotek, uporabniki po meri, pravila požarnega zidu, nastavitveni korak s povišanimi pravicami, asinhroni procesi in še več.

Sistem ni posebej preprost, vendar smo vsak del kompleksnosti dodali iz nuje: zgraditi smo morali peskovnik, ki je varen in uporabniku čim manj v napoto.

Pri zagotavljanju dobre uporabniške izkušnje za uporabnike Codexa v sistemu Windows smo želeli ustvariti varno rešitev, ki ne bi žrtvovala uporabnosti. Smisel uporabe Codexa je namreč prav v tem, da lahko agenti opravljajo delo brez vaše stalne pozornosti.

Ena največjih lekcij tega projekta je bila, da Windows ne ponuja enega samega osnovnega gradnika, ki bi se jasno preslikal v »varnega avtonomnega kodirnega agenta«. Zato smo iz več orodij in konceptov sestavili koherentno rešitev. Nekatere zgodnje zamisli so se izkazale za slepe ulice. Končna zasnova je hibrid prejšnjih prototipov, od katerih je vsak rešil del težave.

Druga lekcija je bila, da je varnost kodirnega agenta drugačen izziv kot klasična varnost aplikacij. Codex mora delovati v resničnih razvijalskih delotokih. Inženirsko delo je bilo zato predvsem iskanje ravnotežja med združljivostjo z agentskimi delovnimi obremenitvami in dejanskim uveljavljanjem omejitev. Ta napetost je oblikovala kompromise v končni zasnovi.

Vas zanima, kako peskovnik Codex deluje v praksi? Preizkusite ga⁠.