Budovanie bezpečného a efektívneho sandboxu na sprístupnenie Codexu vo Windowse

Keď som sa v septembri 2025 pripojil k inžinierskemu tímu Codexu, Codex pre Windows nemal implementáciu sandboxu, čo znamenalo, že používatelia Windowsu boli pri používaní programovacích agentov OpenAI nútení vybrať si medzi dvoma nevyhovujúcimi možnosťami:

1. Schvaľovať takmer každý príkaz (dokonca aj čítanie), ktorý chcel programovací agent spustiť, čo je neefektívne a otravné. Významnou výhodou používania nástroja Codex je, že nemusíte všetku únavnú prácu robiť sami.
2. Povoliť režim Full Access: nechať Codex spúšťať všetky príkazy bez schválenia alebo obmedzení, čo odstraňuje trenie za cenu menšieho dohľadu.

Codex⁠, náš programovací agent, beží na notebookoch vývojárov — či už cez CLI, rozšírenie IDE alebo desktopovú aplikáciu. Riadi konverzáciu medzi človekom pri klávesnici a modelom bežiacim v cloude, ktorý spracúva inferenciu.

Codex štandardne beží s oprávneniami skutočného používateľa, čo znamená, že dokáže robiť všetko, čo môže robiť používateľ. Je to výkonné a potenciálne nebezpečné. Programovací model môže testovaciemu rámcu povedať, aby lokálne spustil príkazy — od spúšťania testov cez čítanie alebo úpravu súboru až po vytvorenie vetvy Gitu — takže predvolený režim Codexu sa snaží nájsť správnu rovnováhu medzi efektivitou a bezpečnosťou. Tento predvolený režim umožňuje Codexu čítať súbory takmer kdekoľvek a zapisovať súbory vo vašom pracovnom priestore (t. j. v adresári, kde Codex spúšťate), bez prístupu na internet, pokiaľ výslovne neurčíte, že ho chcete. Aby sa toto automatické obmedzenie zapisovania súborov a prístupu k sieti v bezpečných hraniciach dosiahlo, Codex potrebuje prostredie sandboxu, ktoré tieto obmedzenia skutočne vynucuje.

Sandbox je obmedzené vykonávacie prostredie. Keď vývojár používa Codex, operačný systém jeho počítača spustí príkaz so zníženými oprávneniami a tieto obmedzenia sa ďalej šíria stromom procesov. Každý príkaz Codexu je od začiatku v sandboxe a každý následný proces zostáva v tej istej hranici.

Codex potrebuje na implementáciu účinného sandboxu izolačné funkcie vynucované operačným systémom počítača. Niektoré operačné systémy poskytujú utility, ktoré to robia dobre (napr. Seatbelt v MacOs, seccomp alebo bubblewrap v Linuxe); Windows však v súčasnosti tento typ schopnosti štandardne neposkytuje.

Aby bol Codex vo Windowse rovnako bezpečný a príjemný na používanie, ako už je všade inde, museli sme implementovať vlastný sandbox.

Windows ponúka niektoré nástroje a primitíva na izoláciu. Hoci žiadny z nich celkom nespĺňal naše požiadavky, preskúmali sme viaceré potenciálne riešenia — konkrétne AppContainer, Windows Sandbox a označovanie Mandatory Integrity Control.

AppContainer

• Čo: AppContainer je natívny sandbox Windowsu, model izolácie založený na schopnostiach, vytvorený pre aplikácie, ktoré vopred presne vedia, ku čomu potrebujú pristupovať.
• Prečo: Bol lákavý, pretože ponúka skutočnú hranicu operačného systému namiesto obmedzení typu „best effort“.
• Prečo nie: Codex nie je jedna úzko vymedzená aplikácia. Riadi otvorené vývojárske workflowy: shelly, Git, Python, správcov balíkov, build nástroje a akékoľvek ďalšie binárky, ktoré sa agent rozhodne, že potrebuje. V praxi to znamenalo, že AppContainer mal pre tento problém nesprávny tvar. Bola to silná izolácia, ale pre oveľa užšiu triedu záťaží než „nechať agenta pracovať ako vývojár“.

Windows Sandbox

• Čo: Windows Sandbox je jednorazový ľahký VM od Microsoftu. Dostanete čerstvú pracovnú plochu Windowsu so silnou izolačnou hranicou a čokoľvek v nej urobíte, po skončení relácie zmizne.
• Prečo: Zaujímavý zo zrejmých dôvodov — oveľa kompatibilnejší s ľubovoľným softvérom než AppContainer a z bezpečnostného hľadiska je to omnoho silnejšia schránka.
• Prečo nie: Codex musí pôsobiť priamo na skutočný checkout, nástroje a prostredie používateľa, nie vo vnútri oddelenej dočasnej pracovnej plochy, ktorá by si vyžadovala nastavenie a premostenie hostiteľ/hosť. Mal aj zásadný produktový problém: Windows Sandbox nie je vôbec dostupný v edíciách Windows Home.

Označovanie integrity Mandatory Integrity Control (MIC)

• Čo: Windows má koncept nazývaný „úrovne integrity“, ako low, medium a high, ktoré určujú, nakoľko systém dôveruje objektom a procesom. Základné pravidlo je, že proces s nižšou integritou nemôže zapisovať do objektu s vyššou úrovňou integrity, aj keby to bežné ACL inak povoľovalo. Napríklad proces s low integrity sa považuje za menej dôveryhodný, takže mu Windows zablokuje zápis do bežných objektov s medium integrity, pokiaľ tieto objekty nie sú výslovne preoznačené tak, aby to umožňovali.
• Prečo: MIC vyzeral na papieri elegantne — spustiť Codex s low integrity, preoznačiť zapisovateľné korene na low integrity a nechať Windows vynucovať zákaz zápisu všade inde. To by nám poskytlo cestu bez admin oprávnení so skutočným mechanizmom operačného systému v pozadí.
• Prečo nie: Rovnako ako ACL, aj štítky integrity menia skutočný hostiteľský súborový systém, a v tomto prípade je zmena významu obzvlášť široká. Označiť pracovný priestor ako low integrity neznamená len „Codex tu môže zapisovať“. Znamená to, že tam môžu zapisovať procesy s low integrity vo všeobecnosti. Na skutočnom vývojárskom stroji to mení reálny checkout používateľa na cieľ s low integrity v rámci hostiteľa, čo je oveľa rizikovejšie než udeliť starostlivo cielené ACL jednému návrhu sandboxu. Aj keby vývojárske nástroje s medium integrity fungovali ďalej, základný model dôvery pracovného priestoru sa zmenil spôsobom, ktorý sa ťažko ohraničuje a ešte ťažšie odôvodňuje.

Po vyhodnotení všetkých možností ako slepých uličiek sme začali navrhovať vlastné riešenie, aby sme používateľom Windowsu priniesli dobrý zážitok z Codexu.

Náš prvý fungujúci prototyp používal kombináciu konceptov a nástrojov Windowsu na implementáciu potrebnej izolácie. Od začiatku bolo jedným z cieľov zabezpečiť, aby to fungovalo bez potreby zvýšenia oprávnení, čo znamená, že Codex by nemusel používateľa žiadať o oprávnenia správcu len na nastavenie alebo spustenie sandboxu. To znamenalo nájsť spôsob, ako rozumne obmedziť dve veci: zápisy do súborov a prístup k sieti.

Ak by sme zápisy do súborov neobmedzili vôbec, mali by sme bezpečnostný problém. Ak by sme ich obmedzili príliš, sandbox by poškodzoval produktivitu používateľa a neustále by žiadal o schválenie. Na vyriešenie tohto problému sme sa opreli o dva dôležité stavebné bloky Windowsu: SID a tokeny s obmedzeným zápisom.

SID, teda security identifier, je identita, ku ktorej Windows viaže oprávnenia. Každý používateľ má SID, skupiny majú SID a dokonca aj jednu prihlasovaciu reláciu má vlastný SID. Napríklad aktuálna prihlásená relácia môže mať SID ako S-1-5-5-X-Y. SID priradený skupine lokálnych administrátorov môže byť S-1-5-32-544.

Windows vám tiež umožňuje vytvárať syntetické SID, ktoré nezodpovedajú skutočnému používateľovi, ale stále sa môžu objavovať v ACL (access control listoch), ktoré definujú, kto môže čítať/zapisovať/spúšťať konkrétne súbory alebo adresáre. To robí zo SID užitočné primitívum pre náš sandbox: môžeme vytvoriť SID určené výhradne na použitie v sandboxe Codexu bez toho, aby sme zasahovali do čohokoľvek iného na počítači.

Tokeny procesov sú vo Windowse bezpečnostné objekty, ktoré definujú identitu a oprávnenia bežiaceho procesu. Určujú, aké akcie môže proces vykonávať. Token s obmedzeným zápisom je konkrétny typ procesového tokenu, ktorý núti Windows vykonať pri operáciách zápisu dodatočnú kontrolu prístupu.

Aby bol zápis úspešný, musia prejsť dve kontroly:

1. Bežná identita používateľa (vlastník tokenu) to musí mať povolené
2. Prístup musí byť udelený aj aspoň jednému SID v zozname obmedzených SID tokenu

V praxi nám tieto kontroly umožnili používať ACL na presné určenie miest, kde môže sandbox upravovať súborový systém, čo nám poskytlo potrebnú granularitu pri operáciách zápisu.

So SID a tokenmi s obmedzeným zápisom fungoval náš nezvýšený sandbox takto:

1. Nastavenie sandboxu vytvorilo syntetický SID s názvom sandbox-write.
2. Identifikátoru SID sandbox-write bol udelený prístup na zápis, spustenie a odstránenie prístupu do
   1. Aktuálny pracovný adresár
   2. Akékoľvek ďalšie writable_roots nakonfigurované v súbore config.toml.
3. Nastavenie sandboxu tomu istému SID výslovne zakázalo prístup na zápis do miest typu „iba na čítanie v rámci zapisovateľného“, ako sú:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex spúšťal príkazy pod tokenom s obmedzeným zápisom, ktorého zoznam obmedzených SID zahŕňa Everyone, SID aktuálne prihlásenej relácie a syntetický SID sandbox-write.

Tento postup účinne vyriešil obmedzenie zápisov do súborov a vyzeral sľubne. Teraz sme však potrebovali riešenie na obmedzenie prístupu sandboxu k sieti.

Obmedzenie prístupu k sieti je dôležitou súčasťou sandboxu; bez neho by škodlivý kód mohol z počítača odosielať dáta na internet. Keďže sme sa chceli vyhnúť požiadavke na zvýšenie oprávnení, mali sme len obmedzené možnosti, ako silno blokovať sieťovú prevádzku. Nástroje, ktoré sme chceli použiť, ako Windows Firewall, sa vo všeobecnosti nedali nainštalovať bez oprávnení správcu.

Keď Windows Firewall neprichádzal do úvahy, obmedzili sme to, čo sme vedeli ovplyvniť. Snažili sme sa, aby podradené prostredie pri typoch sieťových nástrojov, ktoré vývojári reálne používajú, zlyhávalo v uzavretom režime, takže príkazy Git, inštalátory balíkov atď. by v sandboxe zlyhali a používateľ by musel schváliť všetky operácie smerujúce na internet. Myšlienkou bolo otráviť zjavné únikové cesty: posielať prevádzku uvedomujúcu si proxy na mŕtvy koncový bod, prinútiť HTTP(S) transport Gitu robiť to isté a zabezpečiť, aby Git cez SSH zlyhal okamžite. Navyše sme na začiatok PATH pridali malý adresár denybin a preusporiadali PATHEXT tak, aby sa zástupné skripty SSH a SCP vyhodnotili skôr než skutočné binárky.

Napríklad tu sú niektoré konkrétne prepísania prostredia, ktoré sme použili na obmedzenie prístupu k sieti:

• 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

Tým sa zachytila veľká časť bežnej prevádzky riadenej nástrojmi, ale stále to bolo len poradné. Proces mohol ignorovať prostredie, obísť PATH alebo jednoducho otvoriť sockety priamo — príliš riskantné.

Ako pri každej zaujímavej softvérovej implementácii, aj prvý prototyp mal výhody aj nevýhody. Hoci splnil účel len s niekoľkými štandardnými schopnosťami Windowsu, umožňoval veľmi explicitné a granulárne zápisy do súborového systému a bežal bez zvýšenia oprávnení — čím znižoval potrebu, aby používatelia prijímali nadmerné výzvy na zvýšenie oprávnení alebo boli administrátormi na svojom lokálnom počítači — mal niekoľko skutočných nevýhod, z ktorých niektoré ho diskvalifikovali z toho, aby sa stal naším finálnym návrhom:

• Rýchlosť nastavenia: aplikovanie ACL na pracovný priestor môže byť drahé v závislosti od topológie adresára pracovného priestoru.
• Stopa: na systém vývojára sme aplikovali skutočné ACL, hoci táto stopa nie je zvlášť invazívna, pretože všetky aplikované ACL sa týkajú vlastnoručne vytvoreného syntetického SID, ktorý používa iba sandbox.
• Ťažko meniteľná sémantika: spoliehanie sa na ACL pri obmedzeniach založených na súboroch znamená, že meniť sémantiku sandboxu je drahé a zložité. Zatiaľ čo v macOS môžeme dynamicky meniť spôsob generovania súboru .sbpl používaného na konfiguráciu Seatbeltu, sandbox vo Windowse môže vyžadovať pomalú a náročnú operáciu úpravy ACL.
• Ochrana siete je slabá. Ako už bolo spomenuté, bola „poradná“, niektoré programy, ktoré implementujú vlastný sieťový stack, by ju určite obišli a nebola navrhnutá tak, aby odolala nepriateľskému kódu.

Prvé tri problémy sú inherentné vlastnej implementácii sandboxu, ktorá je dostatočne flexibilná pre agentické workflowy. Príbeh potláčania siete bol však iný.

Okrem toho, že škodlivý agent mohol ľahko obísť potláčanie siete založené na prostredí, obišlo by ho aj množstvo dobre mieneného kódu/binárok, ak by nerešpektovali proxy premenné prostredia alebo implementovali vlastný socketový sieťový kód. Mali sme pocit, že tento aspekt je dostatočne závažný na to, aby sme investovali do lepšieho režimu sandboxu.

Aby sme získali lepšie potláčanie siete, chceli sme použiť Windows Firewall, ktorý nám umožňuje blokovať odchádzajúcu sieťovú prevádzku pre používateľov alebo programy. Žiaľ, nedokázali sme účinne vytvoriť funkčné pravidlo firewallu, ktoré by sa vzťahovalo iba na príkazy spustené harnessom Codexu, a to z viacerých dôvodov:

• Windows neumožňuje priradiť pravidlo firewallu k nehlavnej identite obmedzeného tokenu. To znamená, že sme nemohli použiť pravidlo firewallu na „akýkoľvek token, ktorý obsahuje náš syntetický SID v zozname obmedzených SID“.
• Hoci sme mohli vytvoriť pravidlo firewallu, ktoré zodpovedá konkrétnej binárke, to nám umožňuje obmedziť sieť iba pre samotný codex.exe. Nevzťahovalo by sa na procesy, ktoré agent spúšťa v mene používateľa, ako procesy Git alebo Python.
• Aj ostatné rozmery zhody firewallu mali nesprávny tvar. Pravidlá viazané na používateľa stále zodpovedali skutočnému používateľovi Windowsu v nezvýšenom návrhu, nielen obmedzenému podriadenému procesu. Pravidlá podľa cesty k programu boli príliš hrubé: mohli blokovať codex.exe alebo python.exe všeobecne, ale nie toto jedno sandboxované spustenie python.exe. Pravidlá založené na porte alebo adrese boli tiež úplne nesprávnou politikou. Napríklad sme nechceli blokovať port 443; chceli sme blokovať ľubovoľný odchádzajúci prístup pre tento konkrétny strom obmedzených procesov.

Aby sme pravidlo firewallu použili konkrétne na naše sandboxované príkazy, museli sme ich spúšťať ako oddelený principal, nie ako „skutočného“ používateľa. Tento prístup nás nasmeroval na novú cestu, na ktorej sme uvoľnili naše obmedzenie „bez zvýšenia oprávnení“.

Ďalšia iterácia sandboxu, čo je naša aktuálna implementácia, vyžaduje pri nastavovaní zvýšené administrátorské oprávnenia. Preto ju označujem ako „zvýšený sandbox“. Na hranici, kde Codex v systéme spúšťa príkaz, vyzerá zvýšený sandbox podobne ako nezvýšený. Stále spúšťa podriadené procesy pod obmedzeným tokenom – podobne tokenom write_restricted s rovnakým zoznamom obmedzených SID [Everyone, Logon, Synthetic]–, principal tohto tokenu však už nie je skutočný používateľ Windowsu, ale jeden z dvoch lokálnych používateľov, ktorých vytvára samotný Codex::

• CodexSandboxOffline (ten, na ktorého mieria pravidlá firewallu)
• CodexSandboxOnline (ten, na ktorého pravidlá firewallu nemieria)

Tento zdanlivo malý detail má v skutočnosti veľké dôsledky pre sandbox, pre to, kto ho môže používať, a pre zložitosť jeho nastavenia a behu.

Vizuálne je podobný nezvýšenému prototypu, s pridaním pravidiel firewallu a vyhradeného používateľa Windowsu, ktorý skutočne spúšťa príkazy. (Zavedenie týchto nových konceptov však znamená, že predtým, než sandbox začne príkazy spúšťať a chrániť, je potrebné vykonať viac nastavovacej práce.)

Návrh nezvýšeného sandboxu mal jednoduchý krok nastavenia, no bol relatívne malý:

• V prípade potreby vytvoriť syntetický SID
• Použiť ACL pre syntetický SID sandbox-write

Zvýšený sandbox však musí urobiť viac.

• Vytvoriť syntetický SID, ak ešte nebol vytvorený
• Vytvoriť online a offline používateľov sandboxu, ak ešte neboli vytvorení
• Uložiť lokálne prihlasovacie údaje novovytvorených používateľov a zašifrovať ich pomocou Windows Data Protection API (DPAPI) na mieste, ku ktorému používatelia sandboxu v skutočnosti nemajú prístup na čítanie
• Vytvoriť pravidlá firewallu, ktoré zablokujú všetok odchádzajúci sieťový prístup pre používateľa CodexSandboxOffline, alebo ak už existujú, overiť, že sú správne.

Vo fáze nastavenia je ešte jeden háčik. Očakáva sa, že sandbox Codexu bude mať prístup na čítanie ekvivalentný skutočnému používateľovi Windowsu. V nezvýšenom sandboxe, kde bol principal SID obmedzeného tokenu používateľ Windowsu, to bolo splnené. To však neprichádza zadarmo, keď sa principalom stane nový používateľ CodexSandbox. Mnohé relevantné adresáre vo Windowse udeľujú oprávnenia na čítanie/spúšťanie skupine „Authenticated Users“. Jedným významným príkladom je profilový adresár používateľa. Predvolene používatelia Windowsu nemôžu čítať profilové adresáre iných používateľov Windowsu, takže aj jednoduché čítanie súborov by v mnohých scenároch zlyhalo.

Aby sme to vyriešili, pridali sme do procesu nastavenia sandboxu ďalšiu vrstvu — vrstvu na udeľovanie ACL na čítanie používateľom sandboxu tam, kde také ACL ešte nemusia existovať. Napríklad pre niektoré často používané adresáre Windowsu:

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

Keďže tento zoznam adresárov je len „best effort“ a inštalácia ACL na každý z nich môže byť dosť nákladná, spúšťame túto logiku asynchrónne, aby blokujúci krok nastavenia sandboxu, ktorý používateľov zdržuje, nemusel čakať na jej dokončenie.

Logiku nastavenia sme zapuzdrili do vlastnej binárky čiastočne preto, aby sme cez hranicu UAC prechádzali len vtedy, keď je to potrebné. Hlbší dôvod bol však architektonický: nastavenie sandboxu má zásadne inú úlohu než codex.exe. Udržiavanie logiky nastavenia sandboxu vo vyhradenej binárke umožnilo, aby codex.exe zostal normálnym, nezvýšeným harnessom; zabránilo tomu, aby windowsová nastavovacia infraštruktúra nafúkla codex.exe na iných platformách; oddelilo dlhšie bežiacu nastavovaciu prácu od životnosti hlavného procesu; a poskytlo nám jedno miesto na riešenie rôznych ciest nastavenia, ktoré sandbox potreboval.

Pre spôsob, akým vo Windowse fungujú hranice prihlasovania používateľov a tokenov, sme nemohli pokračovať vo vytváraní obmedzeného tokenu a spúšťaní procesu pod ním tak, ako sme to mohli pri nezvýšenom sandboxe. Na skutočné spúšťanie príkazov ako iný používateľ Windowsu bol náš prvý nápad nasledovný postup:

• codex.exe beží ako skutočný používateľ Windowsu. Potom Codex postupne:
  • Volá LogonUserW(...) pre používateľa sandboxu.
  • Volá CreateRestrictedToken(...) na daný token používateľa sandboxu.
  • Pomocou tohto obmedzeného tokenu používateľa sandboxu volá CreateProcessAsUserW(...) na spustenie podradeného procesu.

V praxi tento želaný postup nefungoval kvôli privilegovanému múru pri CreateProcessAsUserW(...). To znamená, že codex.exe dokázal vytvoriť obmedzený token pre používateľa sandboxu, ale nedokázal z používateľskej strany hranice spoľahlivo spustiť podradený proces s týmto tokenom. Potrebovali sme proces, ktorý už beží ako používateľ sandboxu – to by umožnilo, aby krok obmedzenia a finálne spustenie prebehli na strane používateľa sandboxu namiesto strany skutočného používateľa.

Táto požiadavka viedla k codex-command-runner.exe, novej binárke, ktorej jedinou úlohou je vytvoriť obmedzený token a spustiť požadovaný príkaz. Namiesto toho, aby codex.exe robil celý tok sám (skutočný používateľ → používateľ sandboxu → obmedzený token → podradený proces), rozdelili sme tok na dve časti:

Časť 1

• codex.exe volá CreateProcessWithLogonW(...) na spustenie codex-command-runner.exe ako používateľa sandboxu, zatiaľ bez použitia obmedzeného tokenu.

Časť 2

• Vo vnútri runnera OpenProcessToken(GetCurrentProcess(), ...) otvorí vlastný token runnera, ktorý už patrí používateľovi sandboxu.
• Runner volá GetTokenInformation(...) na extrakciu SID prihlásenia sandboxu a potom CreateRestrictedToken(...) na vytvorenie finálneho obmedzeného tokenu.
• Stále vo vnútri runnera potom volá CreateProcessAsUserW(...) s týmto obmedzeným tokenom, aby spustil skutočný podradený proces.

Albert Einstein povedal: „Všetko by malo byť čo najjednoduchšie, ale nie jednoduchšie.“ V tomto duchu náš návrh primerane vyriešil každý problém. Finálna architektúra má štyri vrstvy, ktoré sme už spomenuli:

• samotný codex.exe
• codex-windows-sandbox-setup.exe na spracovanie všetkej práce súvisiacej so zvýšeným nastavením
• codex-command-runner.exe na spúšťanie príkazov s obmedzeným tokenom
• podradený proces

Keď som k tomuto projektu pristupoval na začiatku, nemal som jasnú predstavu, kam povedie. Začal som tým, že som schopnosť sandboxovania inštrumentoval na hranici medzi Codexom a operačným systémom. Tento prístup úzko zodpovedá tomu, ako je sandbox Codexu implementovaný v MacOs a Linuxe.

Ako som sa viac učil o konkrétnych nástrojoch, ktoré Windows poskytuje, a cez desiatky rozhodnutí vyvažujúcich bezpečnosť a jednoduchosť používania systém dorástol do súčasnej podoby — viaceré binárky, vlastné používatelia, pravidlá firewallu, krok nastavenia so zvýšenými oprávneniami, asynchrónne procesy a ďalšie.

Nie je to zvlášť jednoduchý systém, ale každá vrstva zložitosti bola pridaná z nutnosti, aby sme vytvorili sandbox, ktorý je bezpečný a zároveň používateľovi čo najmenej zavadzia.

Pri snahe priniesť používateľom Codexu vo Windowse dobrý používateľský zážitok bolo naším cieľom vytvoriť niečo bezpečné, čo nebude robiť kompromisy v užitočnosti — celý zmysel používania Codexu je, aby agenti dokázali pracovať bez vašej neustálej pozornosti.

Jedným z najväčších ponaučení z tohto projektu bolo, že Windows nám neposkytol jeden primitív, ktorý by sa čisto mapoval na „bezpečný autonómny programovací agent“. Zložili sme niekoľko nástrojov a konceptov, aby sme vybudovali niečo koherentné. Niektoré skoré nápady boli slepé uličky. Finálny návrh bol hybridom skorších prototypov, z ktorých každý riešil časť problému.

Druhým ponaučením bolo, že bezpečnosť programovacieho agenta je iný živočích než klasickejšia bezpečnosť aplikácií. Codex musí fungovať pre skutočné vývojárske workflowy. Inžinierska práca spočívala vo vyvažovaní kompatibility s agentickými záťažami a skutočného vynucovania. Toto napätie formovalo kompromisy vo finálnom návrhu.

Zaujíma vás, ako vyzerá sandbox Codex v praxi? Vyskúšajte si to⁠.