OpenAI a montré comment elle a construit un sandbox sécurisé pour Codex sous Windows

OpenAI a révélé comment elle a créé une sandbox complète pour Codex sous Windows, permettant à un agent d'exécuter des commandes localement sans accès complet au système. L'objectif était simple : préserver la commodité du codage autonome tout en empêchant le modèle d'écrire librement n'importe où et d'accéder à Internet sans permission explicite de l'utilisateur.

Pourquoi Cela N'a Pas Fonctionné

Initialement, les utilisateurs de Windows avaient deux mauvaises options. Soit confirmer presque chaque commande, y compris les simples lectures de fichiers, soit activer Full Access et essentiellement faire confiance à l'agent avec le même niveau de permissions que le développeur lui-même. Pour Codex, ceci est particulièrement sensible : l'agent fonctionne via CLI, IDE et applications de bureau, peut exécuter des tests, modifier du code, créer des branches Git et invoquer les outils de développement courants.

OpenAI a d'abord vérifié les mécanismes standards d'isolation de Windows, mais aucun n'a fonctionné sans compromis majeurs. AppContainer offre une limite de sécurité forte, mais est conçu pour les applications prédéfinies plutôt que pour un ensemble ouvert de scénarios avec Git, Python, gestionnaires de paquets et binaires tiers. Windows Sandbox s'est avéré être un monde trop "séparé" : Codex a besoin de travailler avec la vraie version du code de l'utilisateur, pas avec une machine virtuelle jetable, de plus ce mode n'est pas disponible sur Windows Home. Le mécanisme des niveaux d'intégrité avait aussi l'air bien sur le papier seulement car il modifiait le modèle de confiance pour le système de fichiers réel de l'hôte.

Premier Schéma de Protection

Le premier prototype fonctionnel d'OpenAI a été construit sans exigences de droits administrateur. Il utilisait un SID synthétique et un token d'écriture restreint—un token spécial permettant d'écrire des données uniquement où les permissions utilisateur normales et une permission sandbox séparée coïncident simultanément. Ceci permettait à Codex de lire presque partout mais d'écrire seulement dans des racines de projet strictement définies.

• un SID séparé `sandbox-write` a été créé
• ce SID s'est vu accorder les permissions d'écriture, d'exécution et de suppression dans le répertoire de travail actuel et dans `writable_roots`
• à l'intérieur de ces répertoires, l'écriture pouvait être séparément interdite dans `.git`, `.codex` et `.agents`
• chaque commande s'exécutait avec un token restreint qui prenait en compte `Everyone`, le SID de la session courante et `sandbox-write`

L'approche a fonctionné assez bien pour les fichiers, mais le réseau restait un point faible. L'équipe a essayé de "casser" les chemins réseau typiques via des variables d'environnement comme `HTTPS_PROXY`, `ALL_PROXY` et `GIT_SSH_COMMAND`, ainsi que par la substitution de binaires stub pour `ssh` et `scp`. Pour les commandes Git ordinaires et les installateurs de paquets, cela suffisait souvent, mais la protection était plutôt une recommandation : n'importe quel processus pouvait ignorer les variables d'environnement, contourner PATH ou ouvrir un socket directement.

Comment Fonctionne la Version Finale

En raison des limitations réseau, OpenAI a abandonné l'idée d'une sandbox complètement sans droits administrateur et est passée au schéma actuel, plus strict. Maintenant lors de la configuration, Codex crée deux utilisateurs locaux : `CodexSandboxOffline` pour les processus sans accès réseau et `CodexSandboxOnline` pour les scénarios nécessitant l'accès. Les commandes s'exécutent toujours avec un token restreint, mais plus sous le nom de l'utilisateur réel—à la place sous un utilisateur sandbox spécial auquel les règles du Pare-feu Windows peuvent être appliquées. Ceci a nécessité un processus d'installation séparé.

Il crée un SID synthétique, configure les comptes sandbox, chiffre leurs identifiants via DPAPI et configure les règles de pare-feu qui bloquent le trafic sortant pour l'utilisateur offline. En parallèle, le système accorde aux utilisateurs sandbox les permissions de lecture dans les répertoires typiques comme `C:\Users\<real-user>`, `C:\Windows`, `C:\Program Files` et `C:\ProgramData`—sinon l'agent ne pourrait même pas lire correctement les fichiers utilisateur et les outils. Une partie de la configuration ACL s'exécute de manière asynchrone pour éviter de retarder l'installation initiale.

Un problème séparé s'est posé à la limite du lancement de processus. Il s'est avéré que `codex.exe` ne peut pas parcourir de manière fiable tout le chemin depuis la connexion en tant qu'utilisateur sandbox jusqu'à `CreateProcessAsUserW(...)` depuis le contexte de l'utilisateur réel. Par conséquent, OpenAI a déplacé l'exécution des commandes vers un binaire séparé, `codex-command-runner.exe` : d'abord `codex.exe` le démarre en tant qu'utilisateur sandbox, et le runner dans sa propre session crée un token restreint et lance le processus enfant final.

Dans l'architecture finale, quatre couches participent : `codex.exe` lui-même, un binaire d'installation élevé, le command runner et le processus cible.

Ce Que Cela Signifie

Pour les développeurs Windows, c'est un changement important : les agents de codage locaux deviennent non seulement plus pratiques mais aussi plus prévisibles du point de vue de la sécurité. OpenAI a essentiellement montré que pour le codage basé sur des agents sous Windows, il n'existe pas une unique "API magique", et le problème doit être résolu par une combinaison d'ACL, de tokens, d'utilisateurs séparés, de règles de pare-feu et de binaires supplémentaires. Ceci augmente la complexité de la mise en œuvre mais rapproche le modèle opérationnel de Codex des exigences réelles des équipes qui souhaitent automatiser le travail routinier sans renoncer complètement au contrôle.