costruzione di un ambiente sandbox sicuro ed efficace per abilitare Codex su Windows

Quando mi sono unito al team di ingegneria di Codex nel settembre 2025, Codex per Windows non aveva ancora un ambiente sandbox. Questo significava che gli utenti Windows erano costretti a scegliere tra due opzioni poco soddisfacenti quando utilizzavano gli agenti di programmazione di OpenAI:

• Approvare quasi ogni comando (anche solo letture) che un agente di programmazione desidera eseguire, cosa inefficiente e fastidiosa. Uno dei vantaggi principali dell'uso di Codex è che non devi occuparti dei compiti noiosi.
• Attivare la modalità Full Access: permettere a Codex di eseguire tutti i comandi senza approvazioni né restrizioni. Questo elimina i fastidi ma a scapito della supervisione.

Codex, il nostro agente per la programmazione, funziona su laptop dei programmatori. Che si tratti della CLI, dell'estensione dell'IDE o dell’app desktop, Codex gestisce una conversazione tra un essere umano che utilizza la tastiera e un modello eseguito in cloud per gestire l'elaborazione.

Codex funziona con i permessi di un utente reale per default, il che significa che può fare tutto ciò che l’utente può fare. Questo è potente ma potenzialmente pericoloso. Il modello può richiedere all’esecutore di eseguire comandi locali, tra cui l'esecuzione di test, la lettura o la modifica di un file o la creazione di una branca Git. La modalità predefinita di Codex tenta di trovare il giusto equilibrio tra efficacia e sicurezza. Questa modalità predefinita permette a Codex di leggere file quasi ovunque e di modificare file all’interno dello spazio di lavoro, senza accesso a Internet a meno che l’utente non lo richieda esplicitamente. Per ottenere questa riduzione automatica delle restrizioni per la scrittura e l’accesso alla rete all'interno di limiti sicuri, però, Codex ha bisogno di un ambiente sandbox che imponga davvero queste restrizioni.

Che cosa è un ambiente sandbox

Un ambiente sandbox è un ambiente di esecuzione limitato. Quando un programmatore utilizza Codex, il sistema operativo del computer lancia un comando con permessi ridotti, e quelle limitazioni si propagano lungo l'albero di processo. Ogni comando di Codex è sandboxato fin dall’inizio, e ogni processo discendente rimane all’interno di quel limite.

Codex richiede funzionalità di isolamento garantite dal sistema operativo per implementare in modo efficace un ambiente sandbox. Alcuni sistemi operativi offrono utilità che lo fanno bene (per esempio Seatbelt su macOS, seccomp o bubblewrap su Linux); tuttavia, Windows non dispone di questa funzionalità nativa.

Dove i tool esistenti per Windows non erano sufficienti

Windows offre alcuni strumenti e primitive per l’isolamento. Pur non corrispondendo esattamente ai nostri requisiti, abbiamo valutato diverse soluzioni disponibili — tra cui AppContainer, Windows Sandbox, e Mandatory Integrity Control labeling.

AppContainer

• Che cosa è: AppContainer è la sandbox nativa di Windows, un modello di isolamento basato su capacità pensato per applicazioni che conoscono esattamente cosa devono accedere.
• Perché è interessante: Applica un vero limite del sistema operativo anziché restrizioni basate su tentativi.
• Perché non funziona: Codex non è un’applicazione a funzione limitata. Dirige flussi di lavoro aperti in sviluppo: shell, Git, Python, gestori di pacchetti, strumenti di costruzione e qualsiasi altro eseguibile l'agente ritiene necessario. In pratica, questo rende AppContainer inadatto alla problematica. È uno schema isolato, ma solo per un insieme molto ristretto di carichi di lavoro.

Windows Sandbox

• Che cosa è: Windows Sandbox è il VM leggero di Microsoft. Si ottiene un desktop di Windows fresco con un limite di isolamento forte, e tutto ciò che si fa all’interno scompare alla fine della sessione.
• Perché è interessante: Molto più compatibile con software arbitrario rispetto a AppContainer, ed è chiaramente molto più sicuro.
• Perché non funziona: Codex deve agire direttamente sull'check out, sulle strumenti e sull’ambiente dell’utente. Una postazione desktop separata richiederebbe configurazione e comunicazione host/guest e non è disponibile nemmeno in Windows Home.

Etichettatura Mandatory Integrity Control (MIC)

• Che cosa è: Windows ha il concetto di "livelli di integrità", come basso, medio ed alto, che determinano quanto il sistema confida in oggetti e processi. Una regola fondamentale è che un processo a bassa integrità non può scrivere in oggetti a più alta integrità, nemmeno se le ACL normali lo consentirebbero. Ad esempio, un processo a bassa integrità è trattato come meno attendibile, quindi Windows lo blocca dal scrivere su oggetti medi a meno che questi non siano esplicitamente relabelati per permetterlo.
• Perché è interessante: MIC sembra elegante su carta. Si potrebbe eseguire Codex a bassa integrità, rinominare le radici scrivibili a bassa integrità e lasciare che Windows impedisca le scritture ovunque sia altrove. Farebbe sì che il percorso non richiedesse diritti di amministratore, con meccanismi reali di sistema dietro.
• Perché non funziona: Come le ACL, però, le etichette di integrità modificano il filesystem vero del host. Questo cambiamento è molto ampio. Etichettare uno spazio di lavoro a bassa integrità non significa "Codex può scrivere qui." Significa che qualsiasi processo a bassa integrità può scriverci. Su una macchina reale, questo trasforma l'check out dell’utente in un pozzo basso integrità per il host, molto più rischioso di concedere ACL mirate su una sandbox.

Valutati tutti i rimanenti come inadatti, abbiamo iniziato a progettare la nostra soluzione per offrire un’esperienza Codex paragonabile agli utenti Windows.

Il primo prototipo: la "sandbox non elevata"

Il nostro primo prototipo funzionante utilizzava una combinazione di concetti e strumenti Windows al fine di raggiungere l'isolamento desiderato. Fin dall’inizio, uno obiettivo era di farlo funzionare senza richiedere l’elevation, che significa che Codex non richieda autorizzazioni di amministratore semplicemente per configurare o far girare la sandbox. Ciò significa trovare un sistema per porre limiti ragionevoli a due aspetti: scrittura su file e accesso alla rete.

Se non si limitano le scritture, si ha un problema di sicurezza. Se si limitano troppo, però, la sandbox limita troppo la produttività dell'utente, richiedendo costanti approvazioni. Per risolvere questo dilemma, abbiamo utilizzato due blocchi fond