Come OpenAI ha costruito una sandbox per Codex su Windows senza un primitivo nativo del sistema operativo

Il vuoto nato da una funzionalità mancante del sistema operativo

Quando David Wiesen si è unito al team di engineering di Codex a settembre 2025, l'agente di coding non aveva alcuna sandbox su Windows. Questo lasciava agli utenti Windows due opzioni entrambe pessime: approvare quasi ogni comando che l'agente voleva eseguire, incluse le letture, oppure attivare la modalità Full Access e lasciare che Codex eseguisse qualsiasi cosa senza supervisione.

Il motivo era banale ma decisivo. La modalità predefinita di Codex — leggere quasi ovunque, scrivere solo dentro il workspace, nessun accesso a internet se non richiesto — dipende dal fatto che il sistema operativo faccia rispettare questi limiti. macOS ha Seatbelt; Linux ha seccomp e bubblewrap. Windows di serie non offre nulla di equivalente.

Il compito del team, quindi, non era configurare una sandbox già esistente ma costruirne una a partire da componenti Windows scollegati tra loro. Questa premessa spiega perché il sistema finale sia così elaborato.

Tre opzioni Windows pronte all'uso, tre vicoli ciechi

Il team ha valutato AppContainer, Windows Sandbox e l'etichettatura Mandatory Integrity Control, scartando tutte e tre per motivi concreti e diversi tra loro.

AppContainer offre un vero confine a livello di sistema operativo, ma è pensato per app che dichiarano in anticipo le proprie capacità — la forma sbagliata per un agente che pilota shell, Git, Python, gestori di pacchetti e qualsiasi binario decida di usare. Windows Sandbox è un contenitore più solido, una VM usa e getta, ma Codex deve operare sul checkout e sugli strumenti reali dell'utente, non su un desktop temporaneo; inoltre non è disponibile sulle edizioni Windows Home, un limite che lo esclude a livello di prodotto.

L'etichettatura di integrità MIC sembrava elegante — eseguire Codex a bassa integrità, rietichettare le root scrivibili — ma marcare un workspace come a bassa integrità significa che qualsiasi processo a bassa integrità sull'host può scriverci dentro, trasformando il checkout reale dello sviluppatore in un contenitore accessibile a livello di intero sistema. Il cambiamento semantico era troppo ampio per essere giustificabile.

Il prototipo senza privilegi elevati e l'unica cosa che non riusciva a fare

Il primo design funzionante evitava di chiedere agli utenti privilegi da amministratore. Si basava su due primitivi di Windows: identificatori di sicurezza sintetici e token con restrizioni di scrittura. Un SID sintetico chiamato sandbox-write riceveva i permessi di scrittura, esecuzione ed eliminazione sulla directory di lavoro e su qualsiasi writable_roots configurata, e i permessi di scrittura venivano esplicitamente negati su percorsi sensibili come .git, .codex e .agents. I comandi venivano eseguiti sotto un token con restrizioni di scrittura la cui lista di SID limitati includeva Everyone, il SID di sessione e sandbox-write.

La scrittura dei file era stata risolta in modo netto. L'accesso alla rete no. Senza privilegi da amministratore, Windows Firewall era fuori discussione, quindi il team poteva solo impostare override d'ambiente — puntando i proxy verso un endpoint morto (HTTPS_PROXY=http://127.0.0.1:9), forzando GIT_SSH_COMMAND a uscire con codice 1 e anteponendo una directory denybin al PATH.

L'autore è schietto riguardo al limite di questo approccio.

Questo bloccava buona parte del traffico normale generato dagli strumenti, ma restava comunque solo un accorgimento indicativo. Un processo poteva ignorare le variabili d'ambiente, bypassare il PATH, oppure aprire direttamente dei socket — un rischio troppo alto.Montana Labs

Fondamentale: anche binari ben comportati che implementano il proprio stack di rete sarebbero riusciti a sfuggire a questo controllo. È proprio questa debolezza — non il costo di configurazione delle ACL né la difficoltà di modificare la semantica — che ha spinto il team ad abbandonare il vincolo di non richiedere privilegi elevati.

Perché un vero controllo della rete ha richiesto quattro binari e due utenti fittizi

Windows Firewall poteva bloccare il traffico in uscita, ma solo se i processi in sandbox venivano eseguiti come un principal distinto. Le regole del firewall non possono intercettare il SID sintetico di un token limitato, non possono distinguere un'invocazione sandboxed di python.exe da un'altra qualsiasi, e bloccare una porta come la 443 sarebbe stata comunque la politica sbagliata — l'obiettivo era bloccare l'accesso in uscita arbitrario per un albero di processi specifico.

La soluzione è stata creare due utenti locali, CodexSandboxOffline (destinatario delle regole firewall) e CodexSandboxOnline (non destinatario), con credenziali memorizzate e cifrate tramite DPAPI in modo che gli utenti sandbox non possano leggerle. Poiché questi utenti non sono l'utente Windows reale, perdevano l'accesso in lettura alle directory normalmente condivise con Authenticated Users, quindi il passaggio di configurazione concede anche ACL di lettura su percorsi come il profilo utente, C:\Windows e Program Files — eseguito in modo asincrono perché è lento.

Avviare comandi come un altro utente si è scontrato con un muro di privilegi a livello di CreateProcessAsUserW, che non riusciva ad avviare in modo affidabile un processo figlio con token limitato dal lato dell'utente reale del confine. La soluzione alternativa ha introdotto codex-command-runner.exe: codex.exe avvia il runner come utente sandbox tramite CreateProcessWithLogonW, e il runner — già dal lato dell'utente sandbox — genera il token limitato e avvia il vero processo figlio. Insieme a un binario di configurazione dedicato con privilegi elevati, questo produce quattro livelli: codex.exe, il binario di configurazione, il command runner e il processo figlio.

L'implicazione: la parità multipiattaforma per Codex è arrivata al costo di un passaggio di configurazione con privilegi da amministratore

Il risultato principale è ristretto e specifico: per far comportare Codex su Windows come su macOS e Linux, OpenAI ha dovuto richiedere permessi elevati da amministratore in fase di configurazione — esattamente il vincolo che il team aveva cercato di evitare con il primo prototipo. La soppressione del traffico di rete, capace di resistere a codice ostile, si è rivelata non negoziabile, e su Windows questo significava regole firewall, che significavano un principal separato, che significava privilegi elevati.

Per i team che costruiscono agenti in grado di eseguire comandi locali, la lezione concreta è che il confine di enforcement guida l'architettura, non il contrario. Un design comodo e senza privilegi elevati era tecnicamente valido per la scrittura dei file, ma è crollato di fronte all'unico requisito — bloccare l'esfiltrazione dei dati — che non poteva restare solo indicativo. Tutto ciò che segue, dalle credenziali memorizzate con DPAPI al binario command-runner, esiste per soddisfare quell'unico requisito imprescindibile.

Come lo descrive Wiesen, Windows non offriva loro alcun primitivo corrispondente a un 'agente di coding autonomo sicuro', quindi il team ne ha composto uno. Il risultato non è certo semplice, ma ogni elemento — il SID sintetico, i due utenti, le concessioni asincrone delle ACL di lettura, il flusso di avvio diviso — nasce da un fallimento specifico di un approccio più semplice.