Creació d’un entorn aïllat segur i eficaç per permetre l’ús de Codex a Windows

Quan em vaig incorporar a l’equip d’enginyeria de Codex el setembre del 2025, Codex per a Windows no tenia cap implementació d’entorn aïllat, cosa que feia que els usuaris de Windows es veiessin obligats a triar entre dues opcions poc satisfactòries quan utilitzaven els agents de programació d’OpenAI:

1. Calia aprovar gairebé totes les ordres (fins i tot les de lectura) que volia executar un agent de programació, la qual cosa resulta ineficient i molesta. Un dels grans avantatges d'utilitzar Codex és que no has de fer tota la feina pesada tu.
2. Activació del mode d'accés complet: permetre que Codex executi totes les ordres sense aprovació ni restriccions, cosa que elimina la fricció a costa de la supervisió.

Codex⁠, el nostre agent de programació, s’executa als ordinadors portàtils dels desenvolupadors, ja sigui a través de la CLI, de l’extensió de l’IDE o de l’aplicació d’escriptori. Gestiona una conversa entre una persona davant d’un teclat i un model que s’executa al núvol per gestionar la inferència.

Codex s'executa amb els permisos d'un usuari real per defecte, cosa que vol dir que pot fer tot allò que l'usuari pot fer. Això és potent i potencialment perillós. El model de codificació pot indicar al sistema d’execució que executi ordres localment, des d’executar proves fins a llegir o editar un fitxer o crear una branca de Git, de manera que el mode predeterminat de Codex intenta trobar l’equilibri idoni entre eficàcia i seguretat. Aquest mode predeterminat permet a Codex llegir fitxers de gairebé qualsevol lloc i escriure fitxers dins del teu espai de treball (és a dir, el directori on estàs executant Codex), sense accés a Internet, tret que especifiquis que en vols tenir. Per aconseguir aquesta restricció automàtica de l’escriptura de fitxers i l’accés a la xarxa dins d’uns límits segurs, Codex necessita un entorn segur que faci complir realment aquestes restriccions.

Un entorn aïllat (sandbox) és un entorn d'execució restringit. Quan un desenvolupador fa servir Codex, el sistema operatiu del seu ordinador inicia una ordre amb permisos reduïts, i aquestes restriccions es propaguen cap avall per l’arbre de processos. Cada ordre de Codex s’executa en un entorn aïllat des del principi, i cada procés descendent es manté dins del mateix límit.

Codex necessita funcions d’aïllament aplicades pel sistema operatiu de l’ordinador per implementar un entorn segur eficaç. Alguns sistemes operatius proporcionen utilitats que fan bé aquesta funció (p. ex., Seatbelt a macOS, seccomp o bubblewrap a Linux); tanmateix, Windows actualment no proporciona aquest tipus de funcionalitat de sèrie.

Perquè Codex fos tan segur i agradable d’utilitzar a Windows com ja ho és a la resta de plataformes, ens calia implementar el nostre propi entorn segur.

Windows ofereix algunes eines i funcions bàsiques per a l’aïllament. Tot i que cap d'elles complia del tot els nostres requisits, vam analitzar diverses solucions potencials, com ara AppContainer, Windows Sandbox i l'etiquetatge Mandatory Integrity Control.

AppContainer

• Què: AppContainer és l’entorn aïllat natiu de Windows, un model d’aïllament basat en capacitats dissenyat per a aplicacions que saben per endavant exactament a quins recursos necessiten accedir.
• Per què: És atractiu perquè ofereix un límit real del sistema operatiu en lloc de restriccions basades en el millor esforç.
• Per què no: Codex no és un àmbit d'aplicació ben delimitat. Impulsa fluxos de treball de desenvolupament flexibles: intèrprets d’ordres, Git, Python, gestors de paquets, eines de compilació i qualsevol altre binari que l’agent consideri necessari. A la pràctica, això feia que AppContainer no fos la solució adequada pel problema. Era un aïllament robust, però per a una classe de càrregues de treball molt més restringida que “deixar que un agent actuï com un desenvolupador”.

Windows Sandbox

• Què: Windows Sandbox és la màquina virtual lleugera d’un sol ús de Microsoft. Disposes d’un escriptori de Windows nou i net, amb un límit d’aïllament robust, i tot el que hi facis desapareix quan acaba la sessió.
• Per què: És interessant per motius obvis: és molt més compatible amb programari arbitrari que AppContainer i, des d’una perspectiva de seguretat, és un entorn d’aïllament molt més robust.
• Per què no: Codex ha d’actuar directament sobre el procés de compra, les eines i l’entorn reals de l’usuari, i no dins d’un escriptori d’un sol independent que requeriria configuració i un pont entre l'amfitrió i el convidat. També tenia un problema bàsica amb el producte: Windows Sandbox ni tan sols està disponible a les SKU de Windows Home.

Etiquetatge d’integritat de Mandatory Integrity Control (MIC)

• Què: Windows té un concepte anomenat “nivells d’integritat”, com ara baix, mitjà i alt, que determinen fins a quin punt el sistema confia en els objectes i els processos. La regla bàsica és que un procés amb un nivell d’integritat més baix no pot escriure en un objecte amb un nivell d’integritat més elevat, encara que l’ACL normal ho permetés en altres circumstàncies. Per exemple, un procés de baixa integritat es considera menys fiable, de manera que Windows li impedeix escriure en objectes normals d’integritat mitjana, tret que aquests objectes es tornin a etiquetar explícitament per permetre-ho.
• Per què: el MIC semblava una bona solució sobre el paper: executar Codex amb integritat baixa, tornar a etiquetar les arrels amb permís d’escriptura com a integritat baixa i deixar que Windows imposés la prohibició d’escriptura a tota la resta. Això ens hauria proporcionat una ruta sense privilegis d’administrador amb el suport d'un mecanisme real del sistema operatiu.
• Per què no: Igual que les ACL, les etiquetes d'integritat modifiquen el sistema de fitxers real de l'amfitrió i, en aquest cas, el canvi semàntic és especialment ampli. Marcar un espai de treball com de baixa integritat no vol significa només que “Codex pot escriure aquí.” Això vol dir que els processos de baixa integritat en general hi poden escriure. En una màquina de desenvolupament real, això converteix la còpia de treball real de l’usuari en un receptor de baixa integritat per al sistema amfitrió, la qual cosa és molt més arriscada que concedir llistes de controls d'accés (ACL) acuradament seleccionades a un únic disseny d’entorn aïllat. Encara que les eines per a desenvolupadors d’integritat mitjana continuïn funcionant, el model de confiança subjacent de l’espai de treball ha canviat d’una manera difícil de contenir i encara més difícil de justificar.

Després d’avaluar totes les opcions i considerar que no eren viables, vam començar a dissenyar la nostra pròpia solució per oferir als usuaris de Windows una bona experiència amb Codex.

El nostre primer prototip funcional feia servir una combinació de conceptes i eines de Windows per implementar l'aïllament que necessitàvem. Des del principi, un dels objectius era fer que això funcionés sense requerir elavar, és a dir, que Codex no hagués de fer una indicació a l’usuari per obtenir privilegis d’administrador només per configurar o executar l’entorn aïllat. Això implicava esbrinar com establir límits raonables a dues coses: les operacions d'escriptura de fitxers i l'accés a la xarxa.

Si no limitéssim en absolut les operacions d'escriptura de fitxers, tindríem un problema de seguretat. I si les limitéssim massa, l’entorn aïllat reduiria la productivitat de l'usuari, ja que caldria demanar la seva aprovació constantment. Per resoldre aquest problema, ens vam basar en dos elements fonamentals de Windows: els SID i els segments amb restricció d’escriptura.

Un SID, o identificador de seguretat, és la identitat a la qual Windows associa els permisos. Cada usuari té un SID, els grups tenen SID i fins i tot una única sessió d’inici de sessió rep el seu propi SID. Per exemple, una sessió d’inici de sessió actual podria tenir un SID com ara S-1-5-5-X-Y. El SID assignat al grup d'administradors locals podria ser S-1-5-32-544.

Windows també et permet crear SID sintètics que no corresponen a cap usuari real, però que encara poden aparèixer a les ACL (llistes de control d’accés), que defineixen qui pot llegir/escriure/executar fitxers o directoris específics. Això fa que els SID siguin una element bàsic molt útil per al nostre entorn aïllat: podem crear SID per a ús exclusiu de l’entorn aïllat de Codex, sense interferir amb cap altre element de l'equip.

Els segments de procés són objectes de seguretat a Windows que defineixen la identitat i els privilegis d’un procés en execució. Determinen quines accions pot dur a terme un procés. Un segment amb restricció d’escriptura és un tipus concret de segment de procés que fa que Windows dugui a terme una comprovació d’accés addicional en les operacions d’escriptura.

Per completa una operació d’escriptura, s’han de superar dues comprovacions:

1. La identitat d’usuari normal (el segment “owner”) ha de tenir permís per fer-ho
2. També s’ha de concedir accés com a mínim a un SID de la llista de SID restringits del segment

A la pràctica, aquestes comprovacions et permetien fer servir les ACL per definir exactament on l’entorn aïllat podia modificar el sistema de fitxers, cosa que t’oferia la granularitat que necessitaves pel que fa a les operacions d’escriptura.

Amb els SID i els segments amb escriptura restringida, el nostre entorn aïllat sense elevació funcionava així:

1. La configuració del sandbox ha creat un SID sintètic anomenat sandbox-write.
2. S'ha concedit al SID sandbox-write accés d'escriptura, execució i supressió a
   1. El directori de treball actual
   2. Qualsevol writable_roots addicional configurat a config.toml.
3. La configuració de l’entorn aïllat va denegar explícitament a aquell mateix SID l’accés d’escriptura a ubicacions “només de lectura dins d’ubicacions amb permís d’escriptura”, com ara:
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex ha iniciat ordres amb un segment amb restricció d’escriptura la llista de SID restringits del qual inclou Everyone, el SID de la sessió iniciada actual i el SID sintètic sandbox-write.

Aquest flux va resoldre de manera efectiva la limitació d'escriptura a fitxers i semblava prometedor. Necessitàvem una solució per limitar l'accés a la xarxa de l'entorn aïllat.

Limitar l’accés a la xarxa és una part important de l’entorn d’aïllament; sense aquesta limitació, el codi maliciós podria filtrar dades de la màquina a internet. Com que volíem evitar un requisit d’elevació, teníem opcions limitades per bloquejar de manera estricta el trànsit de xarxa. Les eines que volíem utilitzar, com el tallafocs de Windows, en general no es podien instal·lar sense permisos d’administrador.

Sense el tallafocs del Windows com a opció, quedava limitat el que podíem controlar. Vam intentar fer que l’entorn secundari es bloquegés en cas d'errors per a les eines amb accés a la xarxa que els desenvolupadors fan servir realment, de manera que les ordres de Git, els instal·ladors de paquets, etc., fallessin a l’entorn aïllat i l’usuari hagués d’aprovar qualsevol operació amb accés a Internet. La idea era enverinar les vies d’escapament evidents: enviar el trànsit que tingui en compte el proxy a un punt final mort, fer que el transport HTTP(S) de Git fes el mateix i fer que Git sobre SSH fallés immediatament. A més, vam afegir un petit directori denybin al principi del PATH i vam reordenar PATHEXT perquè els scripts stub d’SSH i SCP tinguessin prioritat abans que els binaris reals.

Per exemple, aquestes són algunes de les sobreescriptures d’entorn específiques que vam fer servir per limitar l’accés a la xarxa:

• 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

Això va atreure molt trànsit normal generat per eines, però seguia sent només orientatiu. Un procés podria ignorar l’entorn, eludir PATH o simplement obrir sòcols directament; era massa arriscat.

Com passa amb qualsevol implementació de programari interessant, el primer prototip tenia pros i contres. Tot i que complia la funció amb només unes quantes capacitats estàndard de Windows, permetia escriptures al sistema de fitxers molt explícites i granulars, i s'executava sense privilegis elevats —cosa que reduïa la necessitat que els usuaris acceptessin indicacions de privilegis massa elevats o fossin administradors de la màquina local—, tenia alguns inconvenients reals, alguns dels quals el van descartar com a disseny final:

• Velocitat de configuració: aplicar les ACL de l’espai de treball pot ser costós en funció de la topologia del directori de l’espai de treball.
• Petjada: Hem aplicat ACL reals al sistema del desenvolupador, tot i que la petjada no és especialment invasiva perquè totes les ACL aplicades corresponen a un SID sintètic creat a mida que només utilitza l'entorn aïllat.
• Semàntica difícil de canviar: la dependència de les ACL per a les restriccions basades en fitxers fa que sigui costós i complex canviar la semàntica de l’entorn aïllat. Mentre que a macOS pots canviar dinàmicament la manera com generem el fitxer .sbpl utilitzat per configurar Seatbelt, l’entorn aïllat de Windows podria requerir una operació lenta i intensiva per ajustar les ACL per a tu.
• La protecció de xarxa és feble. Com ja s’ha esmentat, era «orientatiu», sens dubte seria eludit per alguns programes que implementessin la seva pròpia pila de xarxa, i no estava dissenyat per resistir codi maliciós.

Els tres primers problemes són inherents a una implementació personalitzada d’un entorn aïllat prou flexible per a fluxos d’agents. Però el cas de la supressió de xarxa era diferent.

A més que un agent maliciós pugui eludir fàcilment la supressió de xarxa basada en l’entorn, també hi hauria molts codis o binaris benintencionats que l’eludirien simplement si no respectaven les variables de proxy de l’entorn, o si implementaven el seu propi codi de xarxa basat en sockets. Vam considerar que aquest aspecte era prou important per plantejar-nos invertir en millorar el mode d’entorn aïllat.

Per aconseguir una millor restricció de xarxa, volíem fer servir el tallafoc del Windows, que ens permet bloquejar el trànsit de xarxa sortint per a usuaris o programes. Malauradament, no hem pogut crear de manera eficaç una regla de tallafoc funcional que s’apliqués només a les ordres generades pel harness del Codex per diversos motius:

• Windows no permet fer coincidir una regla del tallafoc amb la identitat no principal d'un segment restringit. Això vol dir que no hem pogut aplicar una regla de tallafoc a «qualsevol segment que inclogui el nostre SID sintètic a la llista de SID restringits».
• Tot i que podríem crear una regla de tallafoc que coincideixi amb un binari específic, això només ens permet limitar l’accés a la xarxa per al mateix codex.exe. No s’aplicaria als processos que l’agent inicia en nom de l’usuari, com ara els processos de Git o Python.
• Altres dimensions de coincidència del tallafoc no tenien la forma correcta. Les regles amb àmbit d’usuari seguien coincidint amb l’usuari real de Windows en el disseny sense elevació, i no només amb el secundari restringit. Les regles basades en el camí del programa eren massa poc precises: podien bloquejar codex.exe o python.exe de manera general, però no aquesta invocació concreta de python.exe en un entorn aïllat. Les regles basades en ports o adreces també eren una política completament equivocada. Per exemple, no volíem bloquejar el port 443; volíem bloquejar l’accés de sortida arbitrari per a aquest arbre de processos restringit concret.

Per aplicar una regla de tallafoc específicament a les nostres ordres executades en un entorn aïllat, calia executar-les amb una identitat de seguretat independent, no com l’usuari “real”. Aquest enfocament ens va portar per un camí nou, en què vam relaxar la nostra restricció de «sense elevació».

La propera iteració de l’entorn segur, que és la nostra implementació actual, necessita que tinguis permisos d’administrador elevats en el moment de la configuració. Per tant, m’hi refereixo com a "l’entorn segur elevat". En el punt límit en què Codex inicia una ordre al sistema, l’entorn aïllat amb privilegis elevats sembla igual que l’entorn aïllat sense privilegis elevats. Encara executa processos secundaris sota un segment restringit —de manera similar, un segment write_restricted amb la mateixa llista de SID restringits de [Everyone, Logon, Synthetic]—; tanmateix, el principal d’aquest segment ja no és l’usuari real de Windows, sinó un dels dos usuaris locals creats pel mateix Codex:

• CodexSandboxOffline (el destinat a les regles del tallafoc)
• CodexSandboxOnline (el que no està afectat per les regles del tallafoc)

Aquest detall aparentment petit en realitat té implicacions importants per a l’entorn aïllat, per a qui el pots fer servir i per a la complexitat de la seva configuració i execució.

És visualment similar al prototip sense privilegis elevats, amb la introducció de regles del tallafoc i d’un usuari de Windows dedicat, que realment executa les ordres. (Tanmateix, la introducció d’aquests nous conceptes implica que hauràs de fer més tasques de configuració abans que l’entorn aïllat pugui començar a executar ordres i protegir-les.)

El disseny de l’entorn aïllat sense privilegis elevats tenia un pas de configuració senzill, però era relativament petit, tal com ho veuries tu:

• Crea un SID sintètic si cal
• Aplica les ACL per al SID sintètic sandbox-write

L’entorn aïllat amb privilegis elevats, però, comporta més feina.

• Crea un SID sintètic, si encara no s’ha creat
• Crea els usuaris de l'entorn segur en línia i fora de línia, si encara no s'han creat
• Emmagatzema localment les credencials dels usuaris acabats de crear i xifra-les mitjançant l’API de protecció de dades de Windows (DPAPI), en una ubicació on els usuaris de l’entorn aïllat no tinguin accés de lectura.
• Crea regles de tallafoc que bloquegin tot l’accés sortint a la xarxa per a l’usuari CodexSandboxOffline o, si ja existeixen, valida que siguin correctes

Hi ha una complicació addicional en l’etapa de configuració. S’espera que l’entorn aïllat de Codex tingui accés de lectura equivalent al de l’usuari real de Windows. Això es va aconseguir a l’entorn aïllat sense privilegis elevats, on el SID principal del segment restringit era l’usuari de Windows. Tanmateix, això no surt de franc quan l’entitat principal passa a ser un usuari nou de CodexSandbox. Molts directoris rellevants a Windows concedeixen permisos de lectura/execució a “Usuaris autenticats”. Un exemple destacat és el directori del perfil de l’usuari. Per defecte, els usuaris de Windows no poden llegir els directoris de perfil d'altres usuaris de Windows, de manera que fins i tot les operacions de lectura de fitxers senzilles fallarien en molts casos.

Per solucionar-ho, hem afegit una altra capa al procés de configuració de l’entorn aïllat: concedir ACL de lectura als usuaris de l’entorn aïllat quan aquestes ACL potser encara no hi són. Per exemple, en alguns directoris de Windows d’ús habitual:

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

Com que aquesta llista de directoris es gestiona de la millora manera possible i instal·lar les ACL en cadascun pot ser força costós, executem aquesta lògica de manera asíncrona perquè el pas de configuració de l’entorn aïllat, que bloqueja els usuaris, no hagi d’esperar que es completin.

Vam encapsular la lògica de configuració en el seu propi binari, en part per travessar el límit de l’UAC només quan fos necessari. Però el motiu més profund era d’arquitectura: la configuració de l’entorn aïllat té una funció fonamentalment diferent de la de codex.exe. Mantenir la lògica de configuració de l'entorn aïllat en un binari dedicat va permetre que codex.exe continués sent un harness normal, sense privilegis elevats; va evitar que la maquinària de configuració exclusiva de Windows inflés codex.exe en altres plataformes; va desacoblar les tasques de configuració de més llarga durada del cicle de vida del procés principal; i ens va donar un únic lloc per gestionar les diferents vies de configuració que necessitava l'entorn aïllat.

A causa de com funcionen els límits d'usuari i d'inici de sessió de segments del Windows, no podíem continuar creant un segment restringit i iniciar-hi un procés de la mateixa manera que podíem fer-ho amb l'entorn aïllat sense privilegis elevats. Això no obstant, podríem haver-ho fet amb l'entorn aïllat sense privilegis elevats. Per executar realment ordres com un usuari de Windows diferent, la nostra primera idea va ser el flux següent:

• codex.exe s’executa com el teu usuari real de Windows. Després, en una seqüència, Codex:
  • Crida LogonUserW(...) per a l’usuari de l’entorn aïllat.
  • Crida CreateRestrictedToken(...) sobre aquest segment de l’usuari de l’entorn aïllat.
  • Amb aquest segment d’usuari restringit de l’entorn aïllat, crida CreateProcessAsUserW(...) per iniciar el procés secundari final.

A la pràctica, aquell flux desitjat no va funcionar a causa d’una barrera de privilegis a la crida CreateProcessAsUserW(...). Això vol dir que codex.exe podia crear un segment restringit per a l’usuari de l’entorn aïllat, però no podia iniciar de manera fiable un procés secundari amb aquest segment des del costat del límit corresponent a l’usuari real. Necessitàvem un procés que ja s’estigués executant com a usuari de l’entorn aïllat: això permetria que el pas de restricció i la creació final del procés tinguessin lloc a la banda de la frontera corresponent a l’usuari de l’entorn aïllat, en lloc de la banda de l’usuari real.

Aquest requisit va donar lloc a codex-command-runner.exe, un binari nou que només té la funció de generar un segment restringit i iniciar l’ordre sol·licitada. En lloc de demanar a codex.exe que faci tot el flux per si mateix (usuari real → usuari del sandbox → segment restringit → procés fill), dividim el flux en dos:

Part 1

• codex.exe crida CreateProcessWithLogonW(...) per iniciar codex-command-runner.exe com a usuari de l’entorn aïllat, sense fer servir encara un segment restringit.

Part 2

• Dins del procés, OpenProcessToken(GetCurrentProcess(), ...) obre el propi segment del procés, que ja pertany a l’usuari de l'entorn aïllat.
• L’executor crida GetTokenInformation(...) per extreure el SID d’inici de sessió de l’entorn aïllat i, a continuació, CreateRestrictedToken(...) per crear el segment restringit final.
• Encara dins de l’executor, crida a CreateProcessAsUserW(...) amb aquest segment restringit per iniciar el procés secundari real.

Albert Einstein va dir: «Tot s’hauria de fer manera tan senzilla com sigui possible, però no més simple.» Amb aquest esperit, el nostre disseny va resoldre adequadament cadascun dels problemes. L'arquitectura final té les quatre capes que hem tractat anteriorment:

• codex.exe en si mateix
• codex-windows-sandbox-setup.exe per gestionar totes les tasques relacionades amb la configuració que requereixen privilegis elevats
• codex-command-runner.exe per executar ordres de segment restringit
• El procés secundari

Quan vaig abordar aquest projecte per primera vegada, no tenia massa clar on m'acabaria portant El meu enfocament va ser començar instrumentant la capacitat d’aïllament al límit entre Codex i el sistema operatiu. Aquest enfocament s’assembla molt a la manera com s’implementa l'entorn aïllat de Codex a macOS i Linux.

Quan vaig anar coneixent més a fons les eines específiques que proporciona Windows, i arran de desenes de decisions per equilibrar la seguretat i la facilitat d’ús, el sistema va evolucionar fins a la seva forma actual, amb diversos binaris, usuaris personalitzats, regles de tallafoc, un pas de configuració amb privilegis elevats, processos asíncrons i més.

No és un sistema especialment senzill, però cada element de complexitat s’ha afegit per necessitat a fi de crear un entorn aïllat que sigui segur i que, en la mesura en què sigui possible, no suposi un obstacle per a l’usuari.

Vam treballar per oferir una bona experiència d’usuari als usuaris del Codex a Windows, amb l'objectiu de crear una solució segura que no comprometés la utilitat: al cap i a la fi, l’objectiu principal d’utilitzar Codex és que els agents puguin fer feina sense requerir la teva atenció constant.

Una de les lliçons més importants d’aquest projecte va ser que Windows no ens va proporcionar cap primitiva que es correspongués clarament amb «agent de codificació autònom segur». Hem combinat diverses eines i conceptes per crear alguna cosa coherent. Algunes idees inicials van resultar ser atzucacs. El disseny final va ser un híbrid de prototips anteriors, cadascun dels quals resolia una part del problema.

L’altra lliçó va ser que la seguretat d’un agent de programació és una qüestió ben diferent de la seguretat d’aplicacions més clàssica. Codex ha de funcionar per a fluxos de treball reals dels desenvolupadors. La feina d’enginyeria consistia a equilibrar la compatibilitat amb les càrregues de treball basades en agents amb una aplicació efectiva. Aquesta tensió va donar forma a les preses per al disseny final.

Tens curiositat per veure l’entorn segur del Codex en acció? Prova-ho⁠.