Izgradnja sigurnog i efikasnog sandboxa za omogućavanje Codexa na Windowsu

Kada sam se u septembru 2025. pridružio inženjerskom timu za Codex, Codex za Windows nije imao implementaciju sandboxa, što znači da su korisnici Windowsa bili primorani birati između dvije nezadovoljavajuće opcije pri korištenju OpenAI agenata za kodiranje:

1. Odobravati gotovo svaku naredbu (čak i čitanja) koju je agent za kodiranje želio pokrenuti, što je neefikasno i naporno. Velika prednost korištenja Codex je što ne morate sami raditi sav taj zamoran posao.
2. Omogućiti režim Full Access: pustiti Codex da pokreće sve naredbe bez odobrenja ili ograničenja, čime se uklanja trenje nauštrb nadzora.

Codex⁠, naš agent za kodiranje, radi na laptopima programera — bilo kroz CLI, proširenje za IDE ili desktop aplikaciju. Upravlja razgovorom između osobe za tastaturom i modela koji radi u oblaku da bi obrađivao inferenciju.

Codex po zadanim postavkama radi sa dozvolama stvarnog korisnika, što znači da može raditi sve što i korisnik može. To je moćno i potencijalno opasno. Model za kodiranje može reći harnessu da lokalno pokrene naredbe, od pokretanja testova do čitanja ili uređivanja datoteke ili kreiranja Git grane, pa zato Codexov zadani režim pokušava pronaći pravu ravnotežu između efikasnosti i sigurnosti. Ovaj zadani režim omogućava Codexu da čita datoteke gotovo bilo gdje i upisuje datoteke unutar vašeg radnog prostora (tj. direktorija u kojem pokrećete Codex), bez pristupa internetu osim ako ne navedete da ga želite. Da bi se postiglo ovo automatsko ograničavanje upisa datoteka i pristupa mreži unutar sigurnih granica, Codexu je potrebno sandbox okruženje koje zaista provodi ta ograničenja.

Sandbox je ograničeno okruženje za izvršavanje. Kada programer koristi Codex, operativni sistem njegovog računara pokreće naredbu sa smanjenim dozvolama, a ta se ograničenja propagiraju niz stablo procesa. Svaka Codex komanda je od samog početka izolirana u sandbox okruženju, a svaki proces-potomak ostaje unutar iste granice.

Codexu su potrebne funkcije izolacije koje provodi operativni sistem računara kako bi se implementirao efikasan sandbox. Neki operativni sistemi nude alate koji to dobro rade (npr. Seatbelt na MacOs-u, seccomp ili bubblewrap na Linuxu); međutim, Windows trenutno ne pruža ovu vrstu mogućnosti odmah po instalaciji.

Da bismo učinili Codex jednako sigurnim i ugodnim za korištenje na Windowsu kao što je već svuda drugdje, morali smo implementirati vlastiti sandbox.

Windows nudi neke alate i primitive za izolaciju. Iako nijedan nije u potpunosti zadovoljio naše zahtjeve, razmotrili smo više mogućih rješenja — konkretno AppContainer, Windows Sandbox i označavanje obaveznom kontrolom integriteta.

AppContainer

• Šta: AppContainer je izvorni Windows sandbox, model izolacije zasnovan na mogućnostima, napravljen za aplikacije koje unaprijed tačno znaju čemu trebaju pristupiti.
• Zašto: Privlačan jer nudi stvarnu granicu operativnog sistema umjesto ograničenja tipa best-effort.
• Zašto ne: Codex nije jedna aplikacija usko definiranog opsega. Pokreće programerske tokove rada otvorenog tipa: shellove, Git, Python, upravitelje paketima, alate za izgradnju i sve druge binarne datoteke za koje agent odluči da su mu potrebne. U praksi, to je značilo da AppContainer nije odgovarao prirodi problema. Bila je to snažna izolacija, ali za mnogo užu klasu radnih opterećenja nego „omogućiti agentu da radi kao programer“.

Windows Sandbox

• Šta: Windows Sandbox je Microsoftova jednokratna lagana virtuelna mašina. Dobijete svjež Windows desktop sa snažnom granicom izolacije, a sve što radite unutar njega nestaje kada se sesija završi.
• Zašto: Zanimljivo iz očiglednih razloga — daleko kompatibilnije sa proizvoljnim softverom nego AppContainer, a iz sigurnosne perspektive to je mnogo jača kutija.
• Zašto ne: Codex mora djelovati direktno na korisnikov stvarni checkout, alate i okruženje, a ne unutar zasebnog privremenog desktopa koji bi zahtijevao postavljanje i povezivanje hosta i gosta. Također je imao temeljni problem s proizvodom: Windows Sandbox nije čak ni dostupan za Windows Home SKU-ove.

Mandatory Integrity Control (MIC) označavanje integriteta

• Šta: Windows ima koncept koji se naziva „nivoi integriteta”, kao što su nizak, srednji i visok, koji određuju koliko sistem vjeruje objektima i procesima. Osnovno pravilo je da proces nižeg integriteta ne može upisivati u objekt s višim nivoom integriteta, čak i ako bi mu standardna ACL lista to inače dozvoljavala. Na primjer, proces niskog integriteta smatra se manje pouzdanim, pa mu Windows blokira pisanje u uobičajene objekte srednjeg integriteta, osim ako ti objekti nisu izričito ponovno označeni da mu to dozvole.
• Zašto: MIC je na papiru izgledao elegantno — pokrenuti Codex s niskim integritetom, ponovo označiti korijenske lokacije za upis kao niski integritet i pustiti Windows da svuda drugdje provodi zabranu upisa. To bi nam dalo opciju bez administratorskih ovlasti, podržanu stvarnim mehanizmom operativnog sistema.
• Zašto ne: Kao i ACL-ovi, oznake integriteta mijenjaju stvarni datotečni sistem hosta, a u ovom slučaju semantička promjena je posebno široka. Označavanje radnog prostora kao prostora niskog integriteta ne znači samo „Codex ovdje može pisati.” To znači da procesi niskog integriteta općenito mogu pisati na tu lokaciju. Na stvarnom računaru programera, to pretvara korisnikovu stvarnu radnu kopiju repozitorija u ponor niskog integriteta za host, što je mnogo rizičnije nego dodijeliti pažljivo ciljane ACL-ove jednom dizajnu sandboxa. Čak i ako alati za programere srednjeg integriteta nastave funkcionisati, temeljni model povjerenja radnog prostora promijenio se na način koji je teško držati pod kontrolom, a još teže opravdati.

Nakon što smo sve opcije ocijenili kao neprihvatljive, počeli smo dizajnirati vlastito rješenje kako bismo korisnicima Windowsa donijeli dobro Codex iskustvo.

Naš prvi funkcionalni prototip koristio je kombinaciju koncepata i alata sistema Windows za implementaciju izolacije koja nam je bila potrebna. Od početka, jedan cilj je bio da se ovo omogući bez zahtijevanja povišenja privilegija, što znači da Codex ne bi morao korisniku prikazivati upit za administratorske privilegije samo da bi postavio ili pokrenuo sandbox okruženje. To je značilo pronaći način kako postaviti razumna ograničenja za dvije stvari: pisanje u datoteke i pristup mreži.

Ako uopće ne bismo ograničili upis datoteka, imali bismo sigurnosni problem. Ako bismo ga previše ograničili, sandbox bi štetio produktivnosti korisnika jer bi stalno tražio odobrenje. Da bismo riješili ovaj problem, oslonili smo se na dvije važne Windows gradivne komponente: SID-ove i tokene ograničene za upis.

SID, ili sigurnosni identifikator, jeste identitet koji Windows povezuje sa dozvolama. Svaki korisnik ima SID, grupe imaju SID-ove, a čak i jedna sesija prijave dobija vlastiti SID. Na primjer, trenutna prijavljena sesija može imati SID poput S-1-5-5-X-Y. SID dodijeljen lokalnoj grupi administratora mogao bi biti S-1-5-32-544.

Windows vam također omogućava kreiranje sintetičkih SID-ova koji ne odgovaraju stvarnom korisniku, ali se ipak mogu pojaviti u ACL-ovima (listama kontrole pristupa), koji definiraju ko može čitati/upisivati/izvršavati određene datoteke ili direktorije. To SID-ove čini korisnom primitivom za naš sandbox: možemo kreirati SID-ove isključivo za Codex sandbox, bez ometanja bilo čega drugog na mašini.

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

Da bi upis uspio, moraju proći dvije provjere:

1. Normalni korisnički identitet (vlasnik tokena) mora imati dozvolu za to
2. Najmanje jedan SID na listi ograničenih SID-ova tokena također mora imati odobren pristup

U praksi su nam ove provjere omogućile da koristimo ACL-ove za tačno definiranje mjesta na kojima sandbox može mijenjati datotečni sistem, što nam je pružilo granularnost potrebnu oko operacija upisa.

Sa SID-ovima i tokenima ograničenim za upis, naš unelevated sandbox radio je ovako:

1. Postavljanje sandboxa kreiralo je sintetički SID nazvan sandbox-write.
2. SID-u sandbox-write dodijeljen je pristup za pisanje, izvršavanje i brisanje za
   1. Trenutni radni direktorij
   2. Svi dodatni writable_roots konfigurirani u config.toml.
3. Postavljanje sandboxa eksplicitno je zabranilo tom istom SID-u pristup za upis na lokacijama „samo za čitanje unutar onih za pisanje“, kao što su:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex je pokretao naredbe pod tokenom ograničenim za upis, čija lista ograničenih SID-ova uključuje Everyone, SID trenutne prijavljene sesije i sintetički SID sandbox-write.

Ovaj tok je efikasno riješio ograničavanje upisa datoteka i djelovao je obećavajuće. Sada nam je trebalo rješenje za ograničavanje mrežnog pristupa sandboxa.

Ograničavanje mrežnog pristupa važan je dio sandboxa; bez toga bi zlonamjerni kod mogao eksfiltrirati podatke sa mašine na internet. Budući da smo željeli izbjeći zahtjev za elevationom, imali smo ograničene mogućnosti da snažno blokiramo mrežni saobraćaj. Alati koje smo htjeli koristiti, poput Windows Firewalla, uglavnom se nisu mogli instalirati bez administratorskih dozvola.

Budući da Windows zaštitni zid nije bio opcija, ograničili smo ono što smo mogli kontrolisati. Pokušali smo podesiti podređeno okruženje tako da se ponaša po principu fail-closed, odnosno da se zatvori pri grešci, za vrste umreženih alata koje programeri zaista koriste, kako bi Git komande, instalateri paketa itd. otkazali u izolovanom okruženju, a korisnik morao odobriti sve operacije koje pristupaju internetu. Ideja je bila zatrovati očigledne izlazne puteve: usmjeriti saobraćaj koji podržava proxy na mrtvu krajnju tačku, natjerati Gitov HTTP(S) transport da uradi isto i učiniti da Git preko SSH-a odmah otkaže. Povrh toga, dodali smo mali direktorij denybin na početak PATH-a i promijenili redoslijed u PATHEXT -u kako bi se stub skripte za SSH i SCP pronalazile prije stvarnih binarnih datoteka.

Naprimjer, evo nekih konkretnih zamjena 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 zahvatilo mnogo normalnog saobraćaja koji pokreću alati, ali je i dalje bilo samo savjetodavno. Proces je mogao ignorirati okruženje, zaobići PATH ili jednostavno direktno otvoriti socket-e — previše rizično.

Kao i kod svake zanimljive softverske implementacije, prvi prototip je imao određene prednosti i nedostatke. Iako je obavio posao koristeći samo nekoliko standardnih Windows mogućnosti, omogućio vrlo eksplicitne i granularne upise u datotečni sistem i radio bez upita — čime je smanjena potreba da korisnici prihvataju previše upita za upit ili da budu administratori na svojoj lokalnoj mašini — imao je neke stvarne nedostatke, od kojih su ga neki diskvalificirali da postane naš konačni dizajn:

• 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 sistem programera, iako otisak nije naročito invazivan jer se svi primijenjeni ACL-ovi odnose na posebno kreiran sintetički SID koji koristi samo sandbox.
• Semantika koju je teško promijeniti: Oslanjanje na ACL-ove za ograničenja zasnovana na datotekama znači da je promjena semantike sandboxa skupa i složena. Dok na macOS-u možemo dinamički promijeniti način na koji generišemo .sbpl datoteka koja se koristi za konfiguriranje Seatbelta, Windows sandbox bi mogao zahtijevati sporu i zahtjevnu operaciju za prilagođavanje ACL-ova.
• Zaštita mreže je slaba. Kao što je ranije spomenuto, bila je „savjetodavna“, neki programi koji implementiraju vlastiti mrežni stek sigurno bi je zaobišli i nije bila osmišljena da izdrži protivnički kod.

Prva tri problema inherentna su prilagođenoj implementaciji sandboxa dovoljno fleksibilnoj za agentne tokove. Priča o potiskivanju mreže bila je, međutim, drugačija.

Osim što je zlonamjerni agent mogao lako zaobići potiskivanje mreže zasnovano na okruženju, mnogo dobronamjernog koda/binarnih datoteka također bi ga zaobišlo jednostavno ako ne bi poštovalo proxy varijable okruženja ili ako bi implementiralo vlastiti socket-bazirani mrežni kod. Smatrali smo da je taj aspekt dovoljan razlog da uložimo u bolji režim sandboxa.

Da bismo dobili bolje potiskivanje mreže, željeli smo koristiti Windows Firewall, koji nam omogućava da blokiramo odlazni mrežni saobraćaj za korisnike ili programe. Nažalost, nismo mogli efikasno kreirati funkcionalno pravilo vatrozida koje bi se primjenjivalo samo na naredbe koje Codex harness pokreće iz nekoliko razloga:

• Windows ne dozvoljava podudaranje pravila vatrozida s neprimarnim identitetom ograničenog tokena. To znači da nismo mogli primijeniti pravilo vatrozida na „bilo koji token koji uključuje naš sintetički SID na svojoj listi ograničenih SID-ova“.
• Iako smo mogli kreirati pravilo vatrozida koje odgovara određenoj binarnoj datoteci, to nam omogućava samo da ograničimo umrežavanje samog codex.exe. To se ne bi primjenjivalo na procese koje agent pokreće u ime korisnika, poput Git ili Python procesa.
• I druge dimenzije podudaranja vatrozida imale su pogrešan oblik. Pravila ograničena na korisnika i dalje su se podudarala sa stvarnim Windows korisnikom u dizajnu bez povišenih privilegija, a ne samo s ograničenim podređenim procesom. Pravila za putanje programa bila su previše neprecizna: mogla su općenito blokirati codex.exe ili python.exe, ali ne i ovo jedno izolirano pokretanje programa python.exe. Pravila zasnovana na portovima ili adresama također su bila potpuno pogrešna politika. Na primjer, nismo željeli blokirati port 443; željeli smo blokirati proizvoljni odlazni pristup za ovo konkretno ograničeno stablo procesa.

Da bismo primijenili pravilo vatrozida specifično na naše sandboxirane naredbe, morali smo ih pokretati kao zaseban principal, a ne kao „stvarnog“ korisnika. Taj pristup nas je odveo novim putem, na kojem smo ublažili naše ograničenje „bez elevationa“.

Sljedeća iteracija sandboxa, koja je naša trenutna implementacija, zahtijeva povišene administratorske privilegije tokom postavljanja. Stoga ga nazivam „povišeni sandbox“. Na granici na kojoj Codex pokreće naredbu na sistemu, sandbox s povišenim privilegijama izgleda kao onaj bez povišenih privilegija. I dalje pokreće podređene procese pod ograničenim tokenom—slično tome, pod tokenom write_restricted s istom listom ograničenih SID-ova [Everyone, Logon, Synthetic]—međutim, sigurnosni principal ovog tokena više nije stvarni Windows korisnik, već jedan od dva lokalna korisnika koje je kreirao sam Codex:

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

Ovaj naizgled mali detalj zapravo ima velike implikacije za sandbox, za to ko ga može koristiti i za složenost njegovog postavljanja i izvršavanja u radu.

Vizuelno je sličan prototipu bez elevationa, uz uvođenje pravila vatrozida i namjenskog Windows korisnika koji zapravo pokreće naredbe. (Međutim, uvođenje ovih novih koncepata znači da postoji više posla pri postavljanju prije nego što sandbox može početi pokretati i štititi naredbe.)

Dizajn sandboxa bez elevationa imao je jednostavan korak postavljanja, ali je bio relativno mali:

• Kreirati sintetički SID ako je potrebno
• Primijeniti ACL-ove za sintetički SID sandbox-write

Elevated sandbox, međutim, ima više posla.

• Kreirati sintetički SID, ako već nije kreiran
• Kreirati online i offline sandbox korisnike, ako već nisu kreirani
• Lokalno pohraniti vjerodajnice novokreiranih korisnika i šifrirati ih pomoću Windows Data Protection API-ja (DPAPI) na mjestu koje sandbox korisnici zapravo ne mogu čitati
• Kreirati pravila vatrozida koja blokiraju sav odlazni mrežni pristup za korisnika CodexSandboxOffline ili, ako već postoje, potvrditi da su ispravna

U fazi konfiguracije postoji dodatna komplikacija. Očekuje se da Codex sandbox okruženje ima pristup za čitanje jednak onom stvarnog Windows korisnika. U sandboxu bez povišenih privilegija, gdje je principal SID ograničenog tokena bio Windows korisnik, to je postignuto. Međutim, to nije bez troška kada principal postane novi korisnik CodexSandbox -a. Mnogi relevantni direktoriji u sistemu Windows dodijelit će dozvole za čitanje/izvršavanje grupi „Autentificirani korisnici“. Jedan značajan primjer je direktorij profila korisnika. Prema zadanim postavkama, korisnici Windowsa ne mogu čitati direktorije profila drugih korisnika Windowsa, pa bi u mnogim scenarijima čak i jednostavna čitanja datoteka bila neuspješna.

Da bismo to riješili, dodali smo još jedan sloj u proces postavljanja sandboxa — sloj za dodjeljivanje ACL-ova za čitanje sandbox korisnicima tamo gdje takvi ACL-ovi možda već ne postoje. Na primjer, u neke često korištene Windows direktorije:

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

Budući da je ova lista direktorija best-effort i da instaliranje ACL-ova na svaki od njih može biti prilično skupo, ovu logiku pokrećemo asinhrono kako korak postavljanja sandboxa, koji blokira korisnike, ne bi morao čekati da se dovrše.

Logiku postavljanja smo enkapsulirali u zasebnu binarnu datoteku, dijelom kako bismo granicu UAC-a prelazili samo kada je to potrebno. Ali dublji razlog bio je arhitektonske prirode: postavljanje sandboxa ima suštinski drugačiji zadatak od codex.exe. Zadržavanje logike postavljanja sandboxa u namjenskoj binarnoj datoteci omogućilo je da codex.exe ostane normalan harness bez elevationa; spriječilo da Windows-specifična mašinerija za postavljanje naduje codex.exe na drugim platformama; odvojilo duže poslove postavljanja od životnog vijeka glavnog procesa; i dalo nam jedno mjesto za rukovanje različitim putevima postavljanja koji su sandboxu bili potrebni.

Zbog načina na koji na Windowsu funkcioniraju granice prijave korisnika i tokena, nismo mogli nastaviti kreirati ograničeni token i pod njim pokretati proces kao što smo mogli sa sandboxom bez elevationa. Da bismo zaista pokretali naredbe kao drugi Windows korisnik, naša prva ideja bila je sljedeći tok:

• codex.exe pokreće se kao stvarni korisnik Windowsa. Zatim, redom, Codex:
  • Poziva LogonUserW(...) za korisnika sandboxa.
  • Poziva CreateRestrictedToken(...) nad tim tokenom sandbox korisnika.
  • Koristeći taj ograničeni token sandbox korisnika, poziva CreateProcessAsUserW(...) za pokretanje konačnog podređenog procesa.

U praksi, taj željeni tok nije funkcionisao zbog prepreke u vezi s privilegijama pri pozivu CreateProcessAsUserW(...). To znači da je codex.exe mogao kreirati ograničeni token za korisnika sandbox okruženja, ali nije mogao pouzdano pokrenuti podređeni proces s tim tokenom sa strane granice stvarnog korisnika. Trebao nam je proces koji se već izvršavao kao sandbox korisnik — to bi omogućilo da se korak ograničavanja i završno pokretanje procesa dogode na strani granice sandbox korisnika, umjesto na strani stvarnog korisnika.

Taj zahtjev doveo je do codex-command-runner.exe, nove binarne datoteke čiji je jedini zadatak da izda ograničeni token i pokrene zatraženu komandu. Umjesto da od codex.exe tražimo da sam obavi cijeli tok (stvarni korisnik → sandbox korisnik → ograničeni token → podređeni proces), podijelili smo tok na dva dijela:

Dio 1

• codex.exe poziva CreateProcessWithLogonW(...) da pokrene codex-command-runner.exe kao sandbox korisnika, bez korištenja ograničenog tokena u toj fazi.

Dio 2

• Unutar runnera, OpenProcessToken(GetCurrentProcess(), ...) otvara token samog runnera, koji već pripada sandbox korisniku.
• Runner poziva GetTokenInformation(...) da izdvoji SID prijave sandboxa, zatim CreateRestrictedToken(...) da izgradi konačni ograničeni token.
• I dalje unutar runnera, poziva CreateProcessAsUserW(...) s tim ograničenim tokenom da pokrene stvarni podređeni proces.

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

• sam codex.exe
• codex-windows-sandbox-setup.exe za rukovanje svim poslovima postavljanja koji zahtijevaju elevation
• codex-command-runner.exe za pokretanje naredbi s ograničenim token
• podređeni proces

Kada sam prvi put pristupio ovom projektu, nisam imao jasan osjećaj gdje će završiti. Moj pristup bio je da počnem instrumentiranjem sandbox sposobnosti na granici između Codexa i operativnog sistema. Ovaj pristup usko odgovara načinu na koji je Codex sandbox implementiran na MacOs-u i Linuxu.

Kako sam učio više o konkretnim alatima koje Windows pruža i kroz desetine odluka kojima se balansirala sigurnost i jednostavnost korištenja, sistem je izrastao u svoj sadašnji oblik — više binarnih datoteka, prilagođeni korisnici, pravila vatrozida, korak postavljanja s elevationom, asinhroni procesi i još mnogo toga.

To nije naročito jednostavan sistem, ali svaki dio složenosti dodat je iz nužde, kako bi se izgradio sandbox koji je i siguran i, koliko god je moguće, ne stoji korisniku na putu.

Radeći na tome da korisnicima Codexa na Windowsu pružimo dobro korisničko iskustvo, naš cilj bio je napraviti nešto sigurno što ne kompromitira korisnost — cijela poenta korištenja Codexa je da agenti mogu obavljati posao bez vaše stalne pažnje.

Jedna od najvećih lekcija iz ovog projekta bila je da nam Windows nije dao jednu primitivu koja se čisto mapira na „sigurnog autonomnog agenta za kodiranje“. Sastavili smo nekoliko alata i koncepata da bismo izgradili nešto koherentno. Neke rane ideje bile su slijepa ulica. Konačni dizajn bio je hibrid ranijih prototipa od kojih je svaki rješavao dio problema.

Druga lekcija bila je da je sigurnost za agenta za kodiranje drugačija zvijer od klasičnije sigurnosti aplikacija. Codex mora raditi za stvarne tokove rada programera. Inženjerski rad odnosio se na balansiranje kompatibilnosti s agentnim opterećenjima i stvarnog provođenja. Ta napetost oblikovala je kompromise u konačnom dizajnu.

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