Crearea unui sandbox sigur și eficient pentru a face posibil Codex pe Windows

Când m-am alăturat echipei de inginerie Codex, în septembrie 2025, Codex pentru Windows nu avea o implementare de mediu de izolare, ceea ce însemna că utilizatorii Windows erau obligați să aleagă între două opțiuni sub nivelul așteptărilor atunci când foloseau agenții de programare de la OpenAI:

1. Să aprobe aproape fiecare comandă (chiar și citirile) pe care un agent de programare voia să o ruleze, ceea ce este ineficient și enervant. Un avantaj major al folosirii Codex este că nu trebuie să faci toată munca plictisitoare pe cont propriu.
2. Să activeze modul Acces complet: să lase Codex să ruleze toate comenzile fără aprobare sau restricții, ceea ce elimină dificultățile în detrimentul supravegherii.

Codex⁠, agentul nostru de programare, rulează pe laptopurile dezvoltatorilor, fie prin CLI, extensia IDE sau aplicația pentru calculator. Acesta gestionează o conversație între o persoană aflată la tastatură și un model care rulează în cloud pentru a efectua inferența.

În mod implicit, Codex rulează cu permisiunile unui utilizator real, ceea ce înseamnă că poate efectua toate acțiunile pe care le poate efectua utilizatorul respectiv. Aceasta este o funcționalitate puternică, dar și potențial periculoasă. Modelul de programare poate instrui mediul de execuție să ruleze comenzi local, de la rularea testelor până la citirea sau modificarea unui fișier ori crearea unei ramuri Git, astfel încât modul implicit al Codex încearcă să găsească echilibrul potrivit între eficiență și siguranță. Acest mod implicit permite Codex să citească fișiere aproape de oriunde și să scrie fișiere în interiorul spațiului tău de lucru (adică directorul din care rulezi Codex), fără acces la internet, cu excepția cazului în care specifici că îl dorești. Pentru a aplica automat aceste restricții privind scrierea fișierelor și accesul la rețea în limite sigure, Codex are nevoie de un mediu de izolare care să impună efectiv aceste constrângeri.

Un mediu de izolare este un mediu de execuție restricționat. Când un dezvoltator folosește Codex, sistemul de operare al calculatorului său lansează o comandă cu permisiuni reduse, iar aceste constrângeri se propagă în arborele de procese. Fiecare comandă Codex este rulată într-un mediu de izolare încă de la început, iar fiecare proces descendent rămâne în interiorul aceleiași limite.

Codex are nevoie de funcții de izolare aplicate de sistemul de operare al calculatorului pentru a implementa un mediu de izolare eficient. Unele sisteme de operare oferă utilitare care îndeplinesc bine această funcție (de exemplu, Seatbelt pe MacOs, seccomp sau bubblewrap pe Linux); însă Windows nu oferă în prezent acest tip de capabilitate gata de utilizare.

Pentru a face Codex la fel de sigur și plăcut de folosit pe Windows cum este deja peste tot în altă parte, a trebuit să implementăm propriul nostru mediu de izolare.

Windows oferă unele instrumente și elemente fundamentale pentru izolare. Deși niciunul nu a îndeplinit pe deplin cerințele noastre, am analizat o serie de soluții potențiale, și anume AppContainer, Windows Sandbox și etichetarea Mandatory Integrity Control.

AppContainer

• Ce este: AppContainer este mediul de izolare nativ din Windows, un model de izolare bazat pe capabilități, construit pentru aplicații care știu dinainte exact la ce trebuie să aibă acces.
• De ce: este atractiv deoarece oferă o delimitare reală a sistemului de operare, în loc de restricții care se bazează doar pe eforturi de bună credință.
• De ce nu: Codex nu este o aplicație cu domeniu strict delimitat. Acesta susține fluxuri de lucru de dezvoltare deschise: comenzi shell, Git, Python, manageri de pachete, instrumente de compilare și orice alte binare de care agentul decide că are nevoie. În practică, acest lucru a făcut ca AppContainer să fie nepotrivit pentru problema respectivă. Era un mediu de izolare puternic, dar pentru o clasă mult mai restrânsă de sarcini de lucru decât „a lăsa un agent să opereze ca un dezvoltator”.

Windows Sandbox

• Ce: Windows Sandbox este mașina virtuală (VM) simplă și de unică folosință de la Microsoft. Primești un desktop Windows nou, cu o limită puternică de izolare, iar orice faci în interiorul acestuia dispare când sesiunea se încheie.
• De ce: interesant din motive evidente, fiind mult mai compatibil cu programe informatice arbitrare decât AppContainer și, din punct de vedere al securității, este un mediu mult mai puternic.
• De ce nu: Codex trebuie să acționeze direct asupra validărilor, instrumentelor și mediului real al utilizatorului, nu într-un desktop separat și temporar care ar necesita configurare și integrare între sistemul gazdă și cel de invitat. Avea și o problemă fundamentală de produs: Windows Sandbox nici măcar nu este disponibil pe SKU-urile Windows Home.

Etichetarea de integritate Mandatory Integrity Control (MIC)

• Ce: În Windows există un concept numit „niveluri de integritate”, cum ar fi scăzut, mediu și ridicat, care determină câtă încredere acordă sistemul obiectelor și proceselor. Regula de bază este că un proces cu un nivel de integritate mai scăzut nu poate scrie într-un obiect cu un nivel de integritate mai ridicat, chiar dacă ACL-ul normal i-ar permite acest lucru în alte condiții. De exemplu, un proces cu integritate scăzută este tratat ca fiind mai puțin de încredere, astfel că Windows îl blochează să scrie în obiecte obișnuite cu integritate medie, cu excepția cazului în care acele obiecte sunt reetichetate explicit pentru a-i permite acest lucru.
• De ce: MIC părea elegant pe hârtie: rulezi Codex la integritate scăzută, reetichetezi rădăcinile inscriptibile ca având o integritate scăzută și lași Windows să aplice interdicția de scriere peste tot în altă parte. Acest aspect ne-ar fi oferit o cale fără drepturi de administrator, susținută de un mecanism real al sistemului de operare.
• De ce nu: la fel ca ACL-urile, etichetele de integritate modifică sistemul de fișiere real al gazdei, iar în acest caz schimbarea semantică este deosebit de amplă. Marcarea unui spațiu de lucru ca având integritate scăzută nu înseamnă doar „Codex poate scrie aici”. Înseamnă că procesele cu integritate scăzută în general pot scrie acolo. Pe un dispozitiv real destinat dezvoltării, acest aspect transformă validarea efectivă din partea utilizatorului într-un receptor cu integritate scăzută pentru gazdă, ceea ce este mult mai riscant decât acordarea unor ACL-uri atent țintite pentru o singură structură de mediu de izolare. Chiar dacă instrumentele pentru dezvoltatori cu integritate medie continuă să funcționeze, modelul de încredere subiacent al spațiului de lucru s-a schimbat într-un mod greu de limitat și și mai greu de justificat.

După ce am evaluat toate opțiunile și am constatat că niciuna nu poate fi utilizată, am început să ne proiectăm propria soluție pentru a oferi utilizatorilor Windows o experiență bună cu Codex.

Primul nostru prototip funcțional a folosit o combinație de concepte și instrumente Windows pentru a implementa izolarea de care aveam nevoie. Încă de la început, unul dintre obiective a fost ca acest lucru să funcționeze fără a necesita drepturi sporite, ceea ce înseamnă că Codex nu ar avea nevoie să facă o solicitare utilizatorului pentru privilegii de administrator doar pentru a configura sau a rula mediul de izolare. Acest lucru a însemnat să găsim o modalitate de a impune limite rezonabile pentru două lucruri: operațiile de scriere în fișiere și accesul la rețea.

Dacă nu limitam deloc scrierile în fișiere, aveam o problemă de siguranță. Dacă le limitam prea mult, mediul de izolare afecta productivitatea utilizatorului, fiind nevoie să ceară aprobare constant. Pentru a rezolva această problemă, ne-am bazat pe două blocuri de construcție importante din Windows: SID-urile și tokenurile cu restricții de scriere.

Un SID, sau identificator de securitate, este identitatea pe care Windows o asociază permisiunilor. Fiecare utilizator are un SID, grupurile au SID-uri, iar chiar și o singură sesiune de autentificare primește propriul SID. De exemplu, o sesiune autentificată curentă ar putea avea un SID precum S-1-5-5-X-Y. SID-ul atribuit grupului de administratori locali ar putea fi S-1-5-32-544.

Windows permite, de asemenea, crearea unor SID-uri sintetice care nu corespund unui utilizator real, dar care pot apărea totuși în ACL-uri (liste de control al accesului), acestea definind cine poate citi/scrie/executa anumite fișiere sau directoare. Acest lucru face ca SID-urile să fie un mecanism util pentru mediul nostru: putem crea SID-uri folosite exclusiv de mediul de izolare Codex, fără să interferăm cu altceva de pe sistem.

Tokenurile de proces sunt obiecte de securitate în Windows care definesc identitatea și privilegiile unui proces aflat în execuție. Acestea determină ce acțiuni poate efectua un proces. Un token cu restricții la scriere este un tip specific de token de proces care determină Windows să efectueze o verificare suplimentară a accesului pentru operațiunile de scriere.

Pentru ca o scriere să aibă loc, trebuie să treacă două verificări:

1. Identitatea normală a utilizatorului („proprietarul” tokenului) trebuie să aibă permisiune să întreprindă această acțiune
2. Cel puțin un SID din lista de SID-uri restricționate a tokenului trebuie, de asemenea, să beneficieze de acces

În practică, aceste verificări ne-au permis să folosim ACL-uri pentru a defini exact unde putea mediul de izolare să modifice sistemul de fișiere, ceea ce ne-a oferit granularitatea de care aveam nevoie în jurul operațiilor de scriere.

Cu SID-uri și tokenuri cu restricții de scriere, mediul nostru fără drepturi sporite funcționa astfel:

1. Configurarea mediul de izolare a creat un SID sintetic numit sandbox-write.
2. SID-ului sandbox-write i s-a acordat acces de scriere, executare și ștergere la
   1. Directorul de lucru curent
   2. Orice writable_roots suplimentare configurate în config.toml.
3. Configurarea mediului de izolare a refuzat explicit pentru același SID accesul de scriere la locațiile „doar în citire în interiorul inscriptibilului”, precum:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex a lansat comenzile sub un token cu restricții de scriere a cărui listă de SID-uri restricționate include Everyone, SID-ul sesiunii autentificate curente și SID-ul sintetic sandbox-write.

Acest flux a rezolvat eficient limitarea scrierii în fișiere și părea promițător. Acum aveam nevoie de o soluție pentru limitarea accesului la rețea al mediului de izolare.

Limitarea accesului la rețea este o parte importantă a mediului de izolare; în lipsa acesteia, codul malițios ar putea exfiltra date de pe dispozitiv către internet. Deoarece voiam să evităm o cerință de elevare, aveam opțiuni limitate pentru a bloca puternic traficul de rețea. Instrumentele pe care voiam să le folosim, precum Paravanul de protecție Windows, în general nu puteau fi instalate fără permisiuni de administrator.

Fără Paravanul de protecție Windows ca opțiune, am fost limitați în ceea ce puteam controla. Am încercat să facem ca mediul-copil să eșueze în mod închis („fail-closed”) pentru tipurile de instrumente de rețea pe care dezvoltatorii le folosesc efectiv, astfel încât comenzile Git, instalatoarele de pachete etc. să eșueze în mediul de izolare, iar utilizatorul să trebuiască să aprobe orice operațiuni care implică accesul la internet. Ideea era să compromită căile evidente de scăpare: să trimită traficul care ține cont de proxy către un punct final inactiv, să facă transportul HTTP(S) al Git să procedeze la fel și să facă Git prin SSH să eșueze imediat. În plus, am adăugat la începutul variabilei PATH un mic director denybin și am reordonat PATHEXT, astfel încât scripturile stub SSH și SCP să fie rezolvate înaintea binarelor reale.

De exemplu, iată câteva dintre suprascrierile specifice de mediu pe care le-am folosit pentru a limita accesul la rețea:

• 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

Aceste măsuri au interceptat mult trafic normal generat de instrumente, dar tot era doar consultativ. Un proces putea ignora mediul, ocoli PATH-ul sau pur și simplu deschide socluri direct, acest aspect fiind prea riscant.

Ca în cazul oricărei implementări software interesante, primul prototip a avut câteva avantaje și dezavantaje. Deși își făcea treaba folosind doar câteva capabilități standard Windows, permitea scrieri în sistemul de fișiere foarte explicite și granulare și rula fără drepturi sporite, reducând nevoia ca utilizatorii să accepte solicitări excesive de acordare de drepturi sau să fie administratori pe dispozitivul lor local, avea unele neajunsuri reale, dintre care unele l-au împiedicat să devină structura noastră finală:

• Viteza de configurare: aplicarea ACL-urilor pentru spațiul de lucru poate fi costisitoare în funcție de topologia directorului spațiului de lucru.
• Amprentă asupra sistemului: am aplicat ACL-uri reale pe sistemul dezvoltatorului, deși impactul nu este deosebit de invaziv, deoarece toate ACL-urile aplicate se referă la un SID sintetic creat special, utilizat exclusiv de mediul de izolare.
• Semantică dificil de modificat: dependența de ACL-uri pentru restricțiile bazate pe fișiere înseamnă că modificarea semanticii mediului de izolare este costisitoare și complexă. Pe când pe macOS putem schimba dinamic modul în care generăm fișierul .sbpl utilizat pentru a configura Seatbelt, mediul de izolare Windows ar putea necesita o operațiune lentă și solicitantă pentru a ajusta ACL-urile.
• Protecția rețelei este slabă. Așa cum am menționat mai devreme, era „consultativă”, care ar fi fost cu siguranță ocolită de unele programe care își implementau propria stivă de rețea și care nu era concepută să reziste la coduri malicioase.

Primele trei probleme sunt inerente unei implementări personalizate de mediu de izolare suficient de flexibile pentru fluxuri agentice. Povestea suprimării rețelei a fost însă diferită.

Pe lângă faptul că un agent malițios ar putea ocoli ușor suprimarea rețelei bazată pe mediu, și multe bucăți de cod/binare bine intenționate ar ocoli-o pur și simplu dacă nu respectau variabilele de mediu proxy sau dacă își implementau propriul cod de rețea bazat pe socluri. Am considerat că acest aspect era suficient pentru a justifica investiția într-un mod de mediu de izolare mai bun.

Pentru a obține o restricționare mai eficientă a rețelei, am vrut să folosim Paravanul de protecție Windows, care ne permite să blocăm traficul de rețea de ieșire pentru utilizatori sau programe. Din păcate, nu am reușit să creăm eficient o regulă de paravan de protecție funcțională care să se aplice doar comenzilor lansate de mediul Codex, din câteva motive:

• Windows nu permite asocierea unei reguli de paravan de protecție cu identitatea non-principală a unui token restricționat. Acest lucru înseamnă că nu puteam aplica o regulă de paravan de protecție la „orice token care include SID-ul nostru sintetic în lista sa de SID-uri restricționate”.
• Deși puteam crea o regulă de paravan de protecție care se potrivește unui binar specific, această măsură ne permitea doar să limităm rețeaua pentru codex.exe în sine. Nu s-ar aplica proceselor pe care agentul le lansează în numele utilizatorului, cum ar fi procesele Git sau Python.
• Celelalte dimensiuni de potrivire ale paravanului de protecție aveau, de asemenea, o formă incorectă. Regulile la nivel de utilizator continuau să corespundă utilizatorului Windows real în structura fără drepturi sporite, nu doar procesului-copil restricționat. Regulile bazate pe calea programului erau prea grosiere: puteau bloca codex.exe sau python.exe în general, dar nu această invocare izolată a python.exe. Regulile bazate pe port sau pe adresă reprezentau, de asemenea, o politică complet greșită. De exemplu, nu doream să blocăm portul 443; doream să blocăm accesul arbitrar de ieșire pentru acest arbore specific de procese restricționate.

Pentru a aplica o regulă de paravan de protecție în mod specific comenzilor noastre din mediul de izolare, trebuia să le rulăm ca un cont principal separat, nu ca utilizatorul „real”. Această abordare ne-a condus pe un drum nou, unul în care ne-am relaxat constrângerea „fără drepturi sporite”.

Următoarea iterație a mediului de izolare, care reprezintă implementarea noastră actuală, necesită drepturi de administrator sporite în momentul configurării. Prin urmare, mă refer la aceasta ca fiind „mediul de izolare cu drepturi sporite”. La limita la care Codex lansează o comandă pe sistem, mediul de izolare cu drepturi sporite arată ca cel fără drepturi sporite. Acesta rulează în continuare procesele-copil sub un token restricționat: în mod similar, un token write_restricted cu aceeași listă de SID-uri restricționate [Everyone, Logon, Synthetic], însă contul principal al acestui token nu mai este utilizatorul Windows efectiv, ci unul dintre cei doi utilizatori locali creați de Codex însuși:

• CodexSandboxOffline (cel vizat de regulile de paravan de protecție)
• CodexSandboxOnline (cel nevizat de regulile de paravan de protecție)

Acest detaliu aparent minor are, de fapt, implicații majore asupra mediului de izolare, asupra utilizatorilor acestuia, precum și asupra complexității configurării și a execuției sale.

Este vizual similar cu prototipul fără drepturi sporite, prin introducerea regulilor de paravan de protecție și a unui utilizator Windows dedicat, care rulează efectiv comenzile. (Totuși, introducerea acestor noi concepte înseamnă că există mai multă muncă de configurare înainte ca mediul de izolare să poată începe să ruleze și să protejeze comenzile.)

Structura mediului de izolare fără drepturi sporite avea un pas de configurare simplu, dar relativ mic:

• Creează un SID sintetic dacă este necesar
• Aplică ACL-uri pentru SID-ul sintetic sandbox-write

Mediul de izolare cu drepturi sporite, însă, are mai multe de făcut.

• Creează un SID sintetic, dacă nu a fost deja creat
• Creează utilizatorii de mediu de izolare conectați și neconectați, dacă nu au fost deja creați
• Stochează local acreditările utilizatorilor nou creați și le criptează folosind Windows Data Protection API (DPAPI) într-un loc pe care utilizatorii de mediu de izolare nu îl pot citi efectiv
• Creează reguli de paravan de protecție care blochează tot traficul de rețea de ieșire pentru utilizatorul CodexSandboxOffline sau, dacă acestea există deja, verifică dacă sunt corecte

Există o problemă suplimentară în etapa de configurare. Se așteaptă ca mediul de izolare al Codex să aibă acces de citire echivalent cu cel al utilizatorului Windows real. În mediul de izolare fără drepturi sporite, unde SID-ul principal al token restricționat era utilizatorul Windows, acest lucru a fost realizat. Totuși, acest lucru nu vine de la sine atunci când contul principal devine un nou utilizator CodexSandbox. Multe directoare relevante din Windows vor acorda permisiuni de citire/executare pentru „Utilizatori autentificați”. Un exemplu notabil este directorul de profil al utilizatorului. În mod implicit, utilizatorii Windows nu pot citi directoarele de profil ale altor utilizatori Windows, astfel că, în multe scenarii, chiar și operațiunile simple de citire a fișierelor ar fi nereușite.

Pentru a rezolva această problemă, am adăugat un alt nivel procesului de configurare a mediului de izolare: unul pentru acordarea ACL-urilor de citire utilizatorilor de mediu de izolare acolo unde astfel de ACL-uri poate că nu există deja. De exemplu, către unele directoare Windows utilizate frecvent:

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

Deoarece această listă de directoare este cea mai eficientă, iar instalarea ACL-urilor pe fiecare dintre acestea poate fi destul de costisitoare, rulăm această logică asincron, astfel încât pasul de configurare a mediului de izolare, care blochează utilizatorii, să nu fie nevoit să aștepte finalizarea acestora.

Am încapsulat logica de configurare în propriul fișier binar, parțial pentru a trece de limita UAC numai atunci când este necesar. Însă motivul mai profund era unul arhitectural: configurarea mediului de izolare are un rol fundamental diferit de cel al codex.exe. Menținerea logicii de configurare a mediului de izolare într-un binar dedicat a permis ca codex.exe să rămână un sistem normal, fără drepturi sporite; a împiedicat mecanismele de configurare specifice Windows să încarce inutil codex.exe pe alte platforme; a decuplat operațiunile de configurare de durată mai mare de ciclul de viață al procesului principal și ne-a oferit un singur loc în care să gestionăm diferitele căi de configurare necesare mediului de izolare.

Din cauza modului în care funcționează limitele de autentificare pentru utilizatori și tokenuri în Windows, nu am putut continua să creăm un token restricționat și să lansăm un proces sub acesta așa cum puteam cu mediul de izolare fără drepturi sporite. Pentru a lansa efectiv comenzi ca un alt utilizator Windows, prima noastră idee a fost următorul flux:

• codex.exe rulează ca utilizatorul Windows real. Apoi, într-o secvență, Codex:
  • Apelează LogonUserW(...) pentru utilizatorul de mediu de izolare.
  • Apelează CreateRestrictedToken(...) pe tokenul acelui utilizator de mediu de izolare.
  • Folosind acel token restricționat al utilizatorului sandbox, apelează CreateProcessAsUserW(...) pentru a lansa procesul-copil final.

În practică, acel flux dorit nu a funcționat din cauza unei bariere de privilegii la CreateProcessAsUserW(...). Acest lucru înseamnă că codex.exe putea crea un token restricționat pentru utilizatorul de mediu de izolare, dar nu putea lansa în mod fiabil un proces-copil cu acel token din partea limitei aferente utilizatorului real. Aveam nevoie de un proces care rula deja ca utilizator de mediu de izolare. Acest lucru ar fi permis ca pasul de restricționare și lansarea finală să aibă loc de partea limitei aferente utilizatorului din mediul de izolare, în loc de partea utilizatorului real.

Acea cerință a dus la codex-command-runner.exe, un nou fișier binar al cărui unic scop este să genereze un token restricționat și să lanseze comanda solicitată. În loc să-i solicităm lui codex.exe să realizeze întregul flux pe cont propriu (utilizator real → utilizator de mediu de izolare → token restricționat → proces-copil), am împărțit fluxul în două:

Partea 1

• codex.exe apelează CreateProcessWithLogonW(...) pentru a lansa codex-command-runner.exe ca utilizator de mediu de izolare, fără a folosi încă un token restricționat.

Partea 2

• În interiorul executorului, OpenProcessToken(GetCurrentProcess(), ...) deschide propriul token al executorului, care aparține deja utilizatorului de mediu de izolare.
• Executorul apelează GetTokenInformation(...) pentru a extrage SID-ul de autentificare de mediu de izolare, apoi CreateRestrictedToken(...) pentru a construi tokenul restricționat final.
• Tot în interiorul executorului, apelează CreateProcessAsUserW(...) cu acel token restricționat pentru a lansa procesul-copil real.

Albert Einstein a spus: „Totul ar trebui făcut cât mai simplu posibil, dar nu mai simplu de atât.” În acest spirit, structura noastră a rezolvat adecvat fiecare problemă. Arhitectura finală are cele patru straturi pe care le-am acoperit anterior:

• codex.exe însuși
• codex-windows-sandbox-setup.exe pentru gestionarea întregii munci de configurare cu drepturi sporite
• codex-command-runner.exe pentru rularea comenzilor cu token restricționat
• Procesul-copil

Când am abordat prima dată acest proiect, nu aveam o idee clară despre unde va ajunge. Abordarea mea a fost să încep prin a instrumenta capabilitatea de mediu de izolare la limita dintre Codex și sistemul de operare. Această abordare se potrivește îndeaproape cu modul în care este implementat mediul de izolare Codex pe MacOs și Linux.

Pe măsură ce am învățat mai multe despre instrumentele specifice oferite de Windows și prin zeci de decizii care echilibrau securitatea și ușurința de utilizare, sistemul a crescut până la forma sa actuală: binare multiple, utilizatori personalizați, reguli de paravan de protecție, un pas de configurare cu drepturi sporite, procese asincrone și multe altele.

Nu este un sistem deosebit de simplu, dar fiecare element de complexitate a fost adăugat din necesitate, pentru a construi un mediu de izolare care să fie atât sigur, cât și, pe cât posibil, să nu stea în calea utilizatorului.

Lucrând pentru a oferi o experiență bună utilizatorilor Codex pe Windows, obiectivul nostru a fost să construim ceva sigur care să nu compromită utilitatea, ideea principală a folosirii Codex fiind ca agenții să poată face muncă fără atenția constantă a utilizatorului.

Una dintre cele mai importante lecții din acest proiect a fost că Windows nu ne-a oferit un singur element fundamental care să corespundă ordonat cu „agent autonom de programare sigur”. Am compus mai multe instrumente și concepte pentru a construi ceva coerent. Unele dintre ideile inițiale s-au dovedit a fi fundături. Structura finală a fost un hibrid al prototipurilor anterioare, fiecare rezolvând o parte a problemei.

Cealaltă lecție a fost că securitatea pentru un agent de programare este cu totul altceva decât securitatea aplicațiilor în sensul clasic al termenului. Codex trebuie să funcționeze pentru fluxuri de lucru reale ale dezvoltatorilor. Munca de inginerie a constat în echilibrarea compatibilității cu sarcinile agentice și aplicarea reală a regulilor. Această tensiune a modelat compromisurile din structura finală.

Te împinge curiozitatea să vezi mediul de izolare Codex în acțiune? Încearcă-l⁠.