OpenAI détaille la construction du bac à sable sécurisé de Codex sous Windows

OpenAI explique comment elle a doté Codex sous Windows d'un véritable bac à sable, afin que l'agent puisse exécuter des commandes en local sans accès complet au système. L'objectif était simple : préserver le confort du codage autonome, sans laisser le modèle écrire n'importe où ni accéder à Internet sans autorisation explicite de l'utilisateur.

Pourquoi ça n'a pas fonctionné

Au départ, les utilisateurs Windows n'avaient que deux mauvaises options. Soit valider presque chaque commande, y compris une simple lecture de fichier, soit activer Full Access et accorder de fait à l'agent le même niveau de droits que le développeur lui-même. Pour Codex, l'enjeu est particulièrement sensible : l'agent fonctionne via la CLI, l'IDE et l'application desktop, et peut lancer des tests, modifier du code, créer des branches Git et appeler les outils de développement habituels.

OpenAI a d'abord testé les mécanismes d'isolation standard de Windows, mais aucun ne convenait sans compromis sérieux. AppContainer offre une frontière de sécurité solide, mais il est conçu pour une application décrite à l'avance, pas pour un ensemble ouvert de scénarios mêlant Git, Python, gestionnaires de paquets et binaires tiers. Windows Sandbox s'est révélé trop cloisonné : Codex doit travailler sur le véritable checkout de l'utilisateur, pas sur une machine virtuelle jetable, et ce mode n'est de surcroît pas disponible sur Windows Home. Le mécanisme des niveaux d'intégrité ne tenait lui aussi que sur le papier, car il modifiait le modèle de confiance appliqué au système de fichiers réel de l'hôte.

Le premier schéma de protection

OpenAI a construit le premier prototype fonctionnel sans exiger de droits administrateur. Il reposait sur un SID synthétique et un write-restricted token, un jeton spécial qui n'autorise l'écriture que là où les droits ordinaires de l'utilisateur et une autorisation sandbox dédiée coïncident. Codex pouvait ainsi lire presque partout, mais n'écrire que dans des racines de projet clairement définies.

• un SID `sandbox-write` distinct était créé
• ce SID recevait les droits d'écriture, d'exécution et de suppression dans le répertoire de travail courant et dans les `writable_roots`
• au sein de ces répertoires, l'écriture pouvait être interdite séparément dans `.git`, `.codex` et `.agents`
• chaque commande était lancée avec un jeton restreint prenant en compte `Everyone`, le SID de la session courante et `sandbox-write`

Sur les fichiers, l'approche a plutôt bien fonctionné, mais le réseau restait le point faible. L'équipe tentait de neutraliser les chemins réseau courants via des variables d'environnement comme `HTTPS_PROXY`, `ALL_PROXY` et `GIT_SSH_COMMAND`, ainsi qu'en substituant des binaires stub à `ssh` et `scp`. Pour les commandes Git classiques et les installateurs de paquets, cela suffisait souvent, mais la protection restait essentiellement indicative : n'importe quel processus pouvait ignorer les variables d'environnement, contourner le PATH ou ouvrir directement un socket.

Comment fonctionne la version publiée

En raison de ces limites réseau, OpenAI a renoncé à un bac à sable entièrement sans droits administrateur pour adopter le schéma actuel, plus strict. Lors de la configuration, Codex crée désormais deux utilisateurs locaux : `CodexSandboxOffline` pour les processus sans réseau et `CodexSandboxOnline` pour les scénarios qui nécessitent un accès. Les commandes sont toujours lancées avec un jeton restreint, mais non plus au nom de l'utilisateur réel : elles s'exécutent sous un utilisateur sandbox dédié, auquel on peut appliquer des règles du pare-feu Windows.

Cela a nécessité un processus de setup distinct. Celui-ci crée le SID synthétique, ouvre les comptes sandbox, chiffre leurs credentials via DPAPI et définit les règles de pare-feu qui bloquent le trafic sortant de l'utilisateur offline. En parallèle, le système accorde aux utilisateurs sandbox des droits de lecture sur des répertoires types comme `C:\Users\<real-user>`, `C:\Windows`, `C:\Program Files` et `C:\ProgramData` ; sans cela, l'agent ne pourrait même pas lire correctement les fichiers et outils de l'utilisateur. Une partie de la configuration des ACL s'exécute de manière asynchrone pour ne pas ralentir l'installation initiale.

Un autre problème est apparu au moment du lancement des processus. Il s'est avéré que `codex.exe` ne peut pas parcourir de façon fiable tout le chemin, de l'ouverture de session sous l'utilisateur sandbox jusqu'à `CreateProcessAsUserW(...)`, depuis le contexte de l'utilisateur réel. OpenAI a donc confié le lancement des commandes à un binaire distinct, `codex-command-runner.exe` : `codex.exe` le démarre d'abord en tant qu'utilisateur sandbox, puis le runner crée, dans sa propre session, le jeton restreint et lance le processus enfant final. L'architecture finale compte quatre couches : `codex.exe` lui-même, le binaire de setup élevé, le command runner et le processus cible.

Ce que cela change

Pour les développeurs Windows, c'est une évolution importante : les agents de codage locaux deviennent non seulement plus pratiques, mais aussi plus prévisibles sur le plan de la sécurité. OpenAI montre de fait qu'aucune API « magique » ne suffit pour le codage agentique sous Windows, et qu'il faut combiner ACL, jetons, utilisateurs dédiés, règles de pare-feu et binaires supplémentaires. La mise en œuvre s'en trouve plus complexe, mais le fonctionnement de Codex se rapproche des exigences réelles des équipes qui veulent automatiser les tâches répétitives sans renoncer totalement au contrôle.