Izgradnja sigurnog, učinkovitog sandboxa za omogućavanje Codexa u sustavu Windows

Kad sam se u rujnu 2025. pridružio inženjerskom timu za Codex, Codex za Windows nije imao implementaciju sandboxa, što je značilo da su korisnici Windowsa pri upotrebi OpenAI-jevih agenata za kodiranje bili prisiljeni birati između dvije nezadovoljavajuće mogućnosti:

1. Odobravati gotovo svaku naredbu (čak i čitanja) koju je agent za kodiranje htio pokrenuti, što je neučinkovito i zamorno. Velika prednost upotrebe Codexa jest to što ne morate sami obavljati sav taj zamoran posao.
2. Omogućiti način Full Access: dopustiti Codexu pokretanje svih naredbi bez odobrenja ili ograničenja, čime se uklanja trenje nauštrb nadzora.

Codex⁠, naš agent za kodiranje, radi na prijenosnim računalima razvojnih programera – bilo putem CLI-ja, proširenja za IDE ili aplikacije za stolna računala. Upravlja razgovorom između čovjeka za tipkovnicom i modela koji se izvodi u oblaku za obradu zaključivanja.

Codex se prema zadanim postavkama pokreće s dopuštenjima stvarnog korisnika, što znači da može učiniti sve što i korisnik. To je moćno i potencijalno opasno. Model za kodiranje može izvršnom okruženju reći da lokalno pokrene naredbe, od pokretanja testova do čitanja ili uređivanja datoteke pa do stvaranja Git grane, pa zadani način rada Codexa pokušava pronaći pravu ravnotežu između učinkovitosti i sigurnosti. Taj zadani način omogućuje Codexu čitanje datoteka gotovo bilo gdje i pisanje datoteka unutar vašeg radnog prostora (tj. direktorija iz kojeg pokrećete Codex), bez pristupa internetu osim ako ne navedete da ga želite. Kako bi se automatski ograničilo pisanje datoteka i pristup mreži unutar sigurnih granica, Codexu je potrebno sandbox okruženje koje ta ograničenja doista provodi.

Sandbox je ograničeno okruženje za izvršavanje. Kad razvojni programer upotrebljava Codex, operativni sustav njegova računala pokreće naredbu sa smanjenim dopuštenjima, a ta se ograničenja prenose niz stablo procesa. Svaka naredba alata Codex od samog je početka pokrenuta u izoliranom okruženju, a svaki silazni proces ostaje unutar iste izolacijske granice.

Codex treba značajke izolacije koje provodi operativni sustav računala kako bi implementirao učinkovit sandbox. Neki operativni sustavi nude alate koji to dobro rade (npr. Seatbelt na MacOS-u, seccomp ili bubblewrap na Linuxu), no Windows trenutačno ne nudi takvu mogućnost odmah po instalaciji.

Da bismo Codex učinili jednako sigurnim i ugodnim za korištenje u sustavu Windows kao što već jest svugdje drugdje, morali smo implementirati vlastiti sandbox.

Windows nudi neke alate i osnovne mehanizme za izolaciju. Iako nijedan od njih nije u potpunosti ispunjavao naše zahtjeve, razmotrili smo niz mogućih rješenja – konkretno AppContainer, Windows Sandbox i označavanje Mandatory Integrity Control.

AppContainer

• Što: AppContainer je izvorni sandbox sustava Windows, model izolacije temeljen na mogućnostima, izgrađen za aplikacije koje unaprijed točno znaju čemu trebaju pristupiti.
• Zašto: privlačan je jer nudi stvarnu granicu operativnog sustava umjesto ograničenja po načelu best effort.
• Zašto ne: Codex nije jedna usko fokusirana aplikacija. Pokreće razvojne tijekove rada otvorenog tipa: naredbene ljuske, Git, Python, upravitelje paketa, alate za izgradnju i bilo koje druge binarne izvršne datoteke za koje agent odluči da su mu potrebne. U praksi zbog toga AppContainer nije bio prikladan za taj problem. Bila je to snažna izolacija, ali za znatno užu klasu radnih opterećenja od „dopustiti agentu da radi poput razvojnog programera”.

Windows Sandbox

• Što: Windows Sandbox Microsoftov je lagani jednokratni VM. Dobijete svježu radnu površinu Windowsa sa snažnom granicom izolacije, a sve što u njoj radite nestaje kada sesija završi.
• Zašto: Zanimljiv je iz očitih razloga – mnogo je kompatibilniji s proizvoljnim softverom nego AppContainer i, sa sigurnosnog stajališta, mnogo je čvršće okruženje.
• Zašto ne: Codex mora djelovati izravno na korisnikov stvarni checkout, alate i okruženje, a ne unutar odvojene privremene radne površine koja bi zahtijevala postavljanje i povezivanje hosta i gosta. Postojao je i temeljni problem vezan uz proizvod: Windows Sandbox nije čak ni dostupan u izdanjima Windows Home.

Označavanje Mandatory Integrity Control (MIC)

• Što: Windows ima koncept pod nazivom „razine integriteta”, kao što su niska, srednja i visoka, koje određuju koliko sustav vjeruje objektima i procesima. Osnovno je pravilo da proces niže razine integriteta ne može pisati u objekt s višom razinom integriteta, čak i ako bi mu uobičajeni ACL to inače dopuštao. Na primjer, proces niske razine integriteta smatra se manje pouzdanim, pa mu Windows blokira pisanje u normalne objekte srednje razine integriteta, osim ako ti objekti nisu izričito ponovno označeni kako bi mu to dopustili.
• Zašto: MIC je na papiru izgledao elegantno – pokrenuti Codex s oznakom low integrity, ponovno označiti korijene za pisanje kao low integrity i prepustiti sustavu Windows da svugdje drugdje provodi zabranu pisanja. To bi nam omogućilo put bez administratorskih ovlasti, potkrijepljen stvarnim mehanizmom operacijskog sustava.
• Zašto ne: Kao i ACL-ovi, oznake integriteta mijenjaju stvarni datotečni sustav hosta, a u ovom je slučaju semantička promjena osobito opsežna. Označavanje radnog prostora kao niskog integriteta ne znači samo „Codex može pisati ovdje.” To znači da procesi s niskom razinom integriteta općenito mogu pisati ondje. Na stvarnom razvojnom računalu to pretvara korisnikovu stvarnu radnu kopiju u odredište niskog integriteta za host, što je znatno rizičnije od dodjeljivanja pažljivo ciljanih ACL-ova jednom dizajnu sandboxa. Čak i ako razvojni alati srednjeg integriteta nastave funkcionirati, temeljni model povjerenja radnog prostora promijenjen je na način koji je teško obuzdati, a još teže opravdati.

Nakon što smo sve mogućnosti ocijenili kao neodržive, počeli smo osmišljavati vlastito rješenje kako bismo korisnicima Windowsa pružili dobro iskustvo s Codexom.

Naš prvi funkcionalni prototip upotrebljavao je kombinaciju koncepata i alata sustava Windows za implementaciju izolacije koja nam je bila potrebna. Od početka je jedan cilj bio omogućiti da ovo funkcionira bez potrebe za povišenjem ovlasti, što znači da Codex ne bi morao korisniku prikazivati upit za administratorske ovlasti samo radi postavljanja ili pokretanja sandboxa. To je značilo osmisliti kako postaviti razumna ograničenja za dvije stvari: zapisivanje u datoteke i mrežni pristup.

Kad uopće ne bismo ograničili pisanje datoteka, imali bismo sigurnosni problem. Kad bismo ga previše ograničili, sandbox bi štetio produktivnosti korisnika jer bi stalno morao tražiti odobrenje. Kako bismo riješili taj problem, oslonili smo se na dva važna osnovna mehanizma Windowsa: SID-ove i tokene ograničene za pisanje.

SID, odnosno sigurnosni identifikator, identitet je koji Windows povezuje s dozvolama. Svaki korisnik ima SID, grupe imaju SID-ove, a čak i pojedinačna sesija prijave dobiva vlastiti SID. Na primjer, trenutačno prijavljena sesija može imati SID kao što je S-1-5-5-X-Y. SID dodijeljen lokalnoj grupi administratora mogao bi biti S-1-5-32-544.

Windows vam također omogućuje stvaranje sintetičkih SID-ova koji ne odgovaraju stvarnom korisniku, ali se ipak mogu pojaviti u ACL-ovima (popisima za kontrolu pristupa), koji definiraju tko može čitati/pisati/izvršavati određene datoteke ili direktorije. Zbog toga su SID-ovi koristan osnovni mehanizam za naš sandbox: možemo stvoriti SID-ove namijenjene isključivo Codexovu sandboxu, bez utjecaja na bilo što drugo na računalu.

Tokeni procesa sigurnosni su objekti u sustavu Windows koji definiraju identitet i privilegije za pokretanje procesa. Određuju koje radnje proces može izvršiti. Token s ograničenjem pisanja posebna je vrsta tokena procesa zbog koje Windows izvodi dodatnu provjeru pristupa pri operacijama pisanja.

Da bi pisanje uspjelo, moraju se proći dvije provjere:

1. to mora biti dopušteno normalnom identitetu korisnika (vlasniku tokena)
2. pristup mora biti odobren barem jednom SID-u na popisu ograničenih SID-ova tokena.

U praksi su nam te provjere omogućile da ACL-ovima precizno definiramo gdje sandbox može mijenjati datotečni sustav, uz razinu granularnosti koja nam je bila potrebna za operacije pisanja.

Uz SID-ove i tokene ograničene za pisanje, naš sandbox bez administratorskih ovlasti radio je ovako:

1. Postavljanje sandboxa stvorilo je sintetički SID nazvan sandbox-write.
2. SID-u sandbox-write odobren je pristup za pisanje, izvršavanje i brisanje za
   1. Trenutačni radni direktorij
   2. Svi dodatni writable_roots konfigurirani u datoteci config.toml.
3. Postavljanje sandboxa istom je SID-u izričito uskratilo pristup za pisanje na lokacijama koje su „samo za čitanje unutar lokacije na kojoj je pisanje dopušteno”, kao što su:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex je pokretao naredbe pod tokenom ograničenim za pisanje čiji popis ograničenih SID-ova uključuje Everyone, SID trenutačno prijavljene sesije i sintetički SID sandbox-write.

Taj je tijek učinkovito riješio ograničavanje pisanja datoteka i djelovao obećavajuće. Sad nam je trebalo rješenje za ograničavanje mrežnog pristupa sandboxa.

Ograničavanje mrežnog pristupa važan je dio sandboxa; bez njega bi zlonamjerni kȏd mogao iznijeti podatke s računala na internet. Budući da smo htjeli izbjeći potrebu za administratorskim ovlastima, imali smo ograničene mogućnosti za pouzdano blokiranje mrežnog prometa. Alati koje smo htjeli koristiti, poput Windows Firewalla, općenito se nisu mogli instalirati bez administratorskih dozvola.

Bez Windows Firewalla nije bio opcija, ograničili smo ono što smo mogli kontrolirati. Pokušali smo postaviti podređeno okruženje tako da za vrste umreženih alata koje razvojni programeri stvarno koriste prema zadanim postavkama sigurno blokira pristup, tako da Git naredbe, instalacijski programi paketa itd. ne bi uspijevali u izoliranom okruženju, a korisnik bi morao odobriti sve operacije usmjerene prema internetu. Ideja je bila zatrovati očite izlazne mehanizme: slati promet koji prepoznaje proxy na mrtvu krajnju točku, natjerati Gitov HTTP(S) transport da učini isto i postići da Git preko SSH-a odmah ne uspije. Povrh toga, na početak varijable PATH dodali smo mali direktorij denybin i promijenili redoslijed u PATHEXT kako bi se stub skripte za SSH i SCP razriješile prije stvarnih binarnih datoteka.

Na primjer, evo nekih konkretnih nadjačavanja okruženja koje smo koristili za ograničavanje mrežnog pristupa:

• 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

To je obuhvatilo velik dio uobičajenog prometa koji generiraju alati, ali i dalje je služilo samo kao preporuka. Proces je mogao zanemariti okruženje, zaobići PATH ili jednostavno izravno otvoriti socket, što je bilo previše rizično..

Kao i svaka zanimljiva implementacija softvera, prvi je prototip imao neke prednosti i nedostatke. Iako je obavio posao sa samo nekoliko standardnih mogućnosti Windowsa, omogućio vrlo precizno i detaljno definiranje pisanja u datotečni sustav te radio bez povišenih ovlasti – čime se smanjila potreba da korisnici prihvaćaju prekomjerne upite za povišenje ovlasti ili budu administratori na lokalnom računalu – imao je neke stvarne nedostatke, od kojih su ga neki diskvalificirali kao naše konačno rješenje:

• Brzina postavljanja: primjena ACL-ova na radni prostor može biti skupa, ovisno o topologiji direktorija radnog prostora.
• Otisak: Primijenili smo stvarne ACL-ove na sustav razvojnog programera, iako taj otisak nije osobito invazivan jer se svi primijenjeni ACL-ovi odnose na prilagođeni sintetički SID stvoren samo za sandbox.
• Semantika koju je teško promijeniti: Oslanjanje na ACL-ove za ograničenja temeljena na datotekama znači da je promjena semantike sandboxa skupa i složena. Dok na macOS-u možemo dinamički mijenjati način na koji generiramo .sbpl datoteka koja se upotrebljava za konfiguriranje Seatbelta, Windowsov sandbox mogao bi zahtijevati sporu i zahtjevnu operaciju prilagodbe ACL-ova.
• Zaštita mreže je slaba. Kao što je ranije spomenuto, bila je „savjetodavna”, neki bi je programi koji implementiraju vlastiti mrežni stog sigurno zaobišli i nije bila osmišljena da izdrži protivnički kod.

Prva tri problema svojstvena su prilagođenoj implementaciji sandboxa koja je dovoljno fleksibilna za tijekove rada s agentima. No ograničavanje mrežnog pristupa bilo je drukčiji problem.

Osim što je zlonamjerni agent mogao lako zaobići ograničavanje mrežnog pristupa temeljeno na okruženju, zaobišao bi ga i velik dio dobroćudnog kȏda ili binarnih datoteka – jednostavno ako ne bi poštovali proxy varijable okruženja ili ako bi implementirali vlastiti mrežni kȏd koji izravno radi sa socketima. Smatrali smo da je taj aspekt dovoljan razlog za ulaganje u bolji način rada sandboxa.

Kako bismo bolje ograničili mrežni pristup, htjeli smo upotrijebiti Windows Firewall, koji nam omogućuje blokiranje odlaznog mrežnog prometa za korisnike ili programe. Nažalost, iz nekoliko razloga nismo mogli učinkovito stvoriti funkcionalno pravilo vatrozida koje bi se primjenjivalo samo na naredbe koje pokreće Codexovo izvršno okruženje:

• Windows ne dopušta podudaranje pravila vatrozida s identitetom ograničenog tokena koji nije principal. To znači da nismo mogli primijeniti pravilo vatrozida na „bilo koji token koji u svom popisu ograničenih SID-ova uključuje naš sintetički SID”.
• Iako bismo mogli stvoriti pravilo vatrozida koje odgovara određenoj binarnoj datoteci, to nam omogućuje samo da ograničimo mrežni pristup za sam codex.exe. Ne bi se primjenjivalo na procese koje agent pokreće u ime korisnika, kao što su procesi Gita ili Pythona.
• Ostale dimenzije podudaranja vatrozida također su bile pogrešnog oblika. Pravila u opsegu korisnika i dalje su se podudarala sa stvarnim korisnikom sustava Windows u dizajnu bez povišenih ovlasti, a ne samo s ograničenim podređenim procesom. Pravila prema putanji programa bila su pregruba: mogla su općenito blokirati codex.exe ili python.exe, ali ne i ovo konkretno pokretanje python.exe u izoliranom okruženju. Pravila temeljena na portu ili adresi također su bila potpuno pogrešan pristup. Na primjer, nismo htjeli blokirati priključak 443; htjeli smo blokirati proizvoljan odlazni pristup za ovo konkretno ograničeno stablo procesa.

Da bismo pravilo vatrozida primijenili baš na naše naredbe u sandboxu, morali smo ih pokretati kao zaseban principal, a ne kao „stvarnog” korisnika. Taj nas je pristup odveo novim putem, na kojem smo ublažili svoje ograničenje „bez administratorskih ovlasti”.

Sljedeća iteracija sandboxa, koja je naša trenutačna implementacija, zahtijeva povišene administratorske ovlasti prilikom postavljanja. Stoga ga nazivam „sandboxom s povišenim ovlastima”. Na granici na kojoj Codex pokreće naredbu u sustavu, sandbox s povišenim ovlastima izgleda kao onaj bez povišenih ovlasti. I dalje pokreće podređene procese pod ograničenim tokenom–slično kao token write_restricted s istim popisom ograničenih SID-ova [Everyone, Logon, Synthetic]–međutim, principal tog tokena više nije stvarni korisnik Windowsa, nego jedan od dva lokalna korisnika koje je stvorio sam Codex:

• CodexSandboxOffline (onaj na kojeg ciljaju pravila vatrozida)
• CodexSandboxOnline (onaj na kojeg pravila vatrozida ne ciljaju)

Taj naizgled sitan detalj zapravo ima velike posljedice za sandbox, za to tko ga može koristiti te za složenost njegova postavljanja i izvođenja u radu.

Vizualno je sličan prototipu bez administratorskih ovlasti, uz uvođenje pravila vatrozida i namjenskog korisnika Windowsa koji zapravo pokreće naredbe. (Međutim, uvođenje tih novih koncepata znači da treba obaviti više posla oko postavljanja prije nego što sandbox može početi pokretati i štititi naredbe.)

Dizajn sandboxa bez administratorskih ovlasti imao je jednostavan korak postavljanja, ali taj je korak bio razmjerno malen:

• po potrebi stvoriti sintetički SID
• primijeniti ACL-ove za sintetički SID sandbox-write

sandbox s administratorskim ovlastima, međutim, mora obaviti više toga.

• stvoriti sintetički SID, ako već nije stvoren
• stvorite online i offline korisnike sandboxa, ako već nisu stvoreni.
• Lokalno pohraniti vjerodajnice novostvorenih korisnika i šifrirati ih pomoću Windows Data Protection API-ja (DPAPI) na mjestu koje korisnici sandboxa zapravo ne mogu čitati
• Stvoriti pravila vatrozida koja blokiraju sav odlazni mrežni pristup za korisnika CodexSandboxOffline ili, ako već postoje, provjeriti jesu li ispravna

Postoji još jedna komplikacija u fazi postavljanja. Očekuje se da Codex izolirano okruženje ima pristup za čitanje ekvivalentan onome stvarnog korisnika sustava Windows. U sandboxu bez povišenih ovlasti, u kojem je glavni SID ograničenog tokena bio korisnik sustava Windows, to je postignuto. Međutim, to ne dolazi besplatno kada subjekt postane novi korisnik sustava CodexSandbox. Mnogi relevantni direktoriji u sustavu Windows dodjeljuju dozvole za čitanje/izvršavanje grupi „Autentificirani korisnici”. Jedan značajan primjer jest direktorij korisničkog profila. Prema zadanim postavkama, korisnici sustava Windows ne mogu čitati direktorije profila drugih korisnika sustava Windows, pa bi čak i jednostavne operacije čitanja datoteka u mnogim scenarijima bile neuspješne.

Kako bismo to riješili, dodali smo još jedan sloj procesu postavljanja sandboxa – sloj za dodjeljivanje read ACL-ova korisnicima sandboxa ondje gdje takvi ACL-ovi možda već ne postoje. Na primjer, do nekih često korištenih direktorija sustava Windows:

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

Budući da je ovaj popis direktorija sastavljen po načelu best effort i da primjena ACL-ova na svaki od njih može biti prilično skupa, tu logiku pokrećemo asinkrono kako korak postavljanja sandboxa, koji blokira korisnike, ne bi morao čekati njezin dovršetak.

Logiku postavljanja enkapsulirali smo u zasebnu izvršnu datoteku, djelomično zato da bismo granicu UAC-a prelazili samo kada je to potrebno. No dublji je razlog bio arhitekturne prirode: postavljanje sandboxa ima bitno drukčiju zadaću od codex.exe. Zadržavanje logike postavljanja sandboxa u namjenskoj binarnoj datoteci omogućilo je da codex.exe ostane uobičajeno izvršno okruženje bez administratorskih ovlasti; da infrastruktura za postavljanje specifična za Windows ne optereti codex.exe na drugim platformama; da se dugotrajniji poslovi postavljanja odvoje od životnog vijeka glavnog procesa i da imamo jedno mjesto za rukovanje različitim putovima postavljanja koji su sandboxu bili potrebni.

Zbog načina na koji u sustavu Windows funkcioniraju granice prijave korisnika i tokena, nismo mogli nastaviti stvarati ograničeni token i pod njim pokretati proces onako kako smo mogli sa sandboxom bez administratorskih ovlasti. Da bismo doista pokretali naredbe kao drugi korisnik Windowsa, naša prva ideja bila je sljedeći tijek:

• codex.exe pokreće se kao stvarni korisnik Windowsa. Zatim, u slijedu, Codex:
  • Poziva LogonUserW(...) za korisnika izoliranog okruženja.
  • Poziva CreateRestrictedToken(...) na tom tokenu korisnika sandboxa.
  • Pomoću tog ograničenog tokena korisnika sandboxa poziva CreateProcessAsUserW(...) kako bi pokrenuo konačni podređeni proces.

U praksi taj željeni tijek nije funkcionirao zbog prepreke povezane s privilegijama pri pozivu CreateProcessAsUserW(...). To znači da je codex.exe mogao stvoriti ograničeni token za korisnika sandboxa, ali nije mogao pouzdano pokrenuti podređeni proces s tim tokenom sa strane granice stvarnog korisnika. Trebao nam je proces koji se već izvodio kao korisnik sandboxa — time bi se omogućilo da se korak primjene ograničenja i završno pokretanje procesa dogode na strani korisnika sandboxa, a ne na strani stvarnog korisnika.

Taj je zahtjev doveo do codex-command-runner.exe, nove binarne izvršne datoteke čiji je jedini zadatak stvoriti ograničeni token i pokrenuti zatraženu naredbu. Umjesto da od codex.exe tražimo da sam obavi cijeli tijek (stvarni korisnik → korisnik sandboxa → ograničeni token → podređeni proces), podijelili smo ga na dva dijela:

1. dio

• codex.exe poziva CreateProcessWithLogonW(...) kako bi pokrenuo codex-command-runner.exe kao korisnika sandboxa, bez korištenja ograničenog tokena.

2. dio

• Unutar pokretača, OpenProcessToken(GetCurrentProcess(), ...) otvara vlastiti token pokretača, koji već pripada korisniku sandboxa.
• Runner poziva GetTokenInformation(...) kako bi izdvojio SID prijave sandboxa, a zatim CreateRestrictedToken(...) kako bi izgradio konačni ograničeni token.
• I dalje unutar runnera poziva CreateProcessAsUserW(...) s tim ograničenim tokenom kako bi pokrenuo stvarni podređeni proces.

Albert Einstein rekao je: „Sve treba učiniti što jednostavnijim, ali ne jednostavnijim od toga.” U tom duhu naš je dizajn primjereno riješio svaki problem. Konačna arhitektura ima četiri sloja koja smo prethodno obradili:

• sam codex.exe
• codex-windows-sandbox-setup.exe za rukovanje svim poslovima postavljanja povezanima s administratorskim ovlastima
• codex-command-runner.exe za pokretanje naredbi s ograničenim token
• Podređeni proces

Kad sam prvi put pristupio ovom projektu, nisam imao jasnu predodžbu o tome kamo će nas odvesti. Krenuo sam od instrumentiranja mogućnosti sandboxinga na granici između Codexa i operativnog sustava. Taj pristup vrlo je sličan načinu na koji je Codexov sandbox implementiran na macOS-u i Linuxu.

Kako sam učio više o specifičnim alatima koje Windows pruža i kroz desetke odluka u kojima smo balansirali sigurnost i jednostavnost uporabe, sustav je izrastao u svoj sadašnji oblik – više binarnih datoteka, prilagođeni korisnici, pravila vatrozida, korak postavljanja s administratorskim ovlastima, asinkroni procesi i još mnogo toga.

To nije osobito jednostavan sustav, ali svaki je sloj složenosti dodan iz nužde kako bi se izgradio sandbox koji je istodobno siguran i, koliko je god moguće, ne smeta korisniku.

Dok smo radili na pružanju dobrog korisničkog iskustva korisnicima Codexa u sustavu Windows, cilj nam je bio napraviti nešto sigurno što ne kompromitira uporabljivost – cijela poanta korištenja Codexa jest da agenti mogu obavljati posao bez vaše stalne pažnje.

Jedna od najvećih lekcija ovog projekta bila je da nam Windows nije pružio jedan osnovni mehanizam koji se jasno može preslikati na „sigurnog autonomnog agenta za kodiranje”. Kombinirali smo nekoliko alata i koncepata kako bismo izgradili nešto smisleno. Neke rane ideje pokazale su se kao slijepa ulica. Konačni dizajn bio je hibrid ranijih prototipova, od kojih je svaki rješavao dio problema.

Druga je lekcija bila da je sigurnost agenta za kodiranje nešto posve drukčije od klasičnije sigurnosti aplikacija. Codex mora funkcionirati u stvarnim tijekovima rada razvojnih programera. Inženjerski je izazov bio uskladiti kompatibilnost s radnim opterećenjima koja uključuju agente i stvarnu provedbu ograničenja. Ta je napetost oblikovala kompromise u konačnom dizajnu.

Zanima vas kako Codex sandbox izgleda u praksi? Isprobajte⁠.