Windows et Codex : comment OpenAI a dompté la machine pour coder en sécurité ?

UNE MACHINE À CODER QUI DÉFIE LES RÈGLES

En septembre 2025, quand un nouveau développeur a rejoint l’équipe de Codex, il a découvert une situation absurde : les utilisateurs de Windows devaient choisir entre deux mauvaises options pour faire tourner les agents de codage d’OpenAI. Soit ils laissaient Codex accéder à leur machine comme un utilisateur normal, avec tous les droits… et tous les dangers. Soit ils renonçaient à une partie des fonctionnalités.

Codex, c’est un assistant de codage qui tourne sur ton ordinateur, que ce soit via un terminal, une extension pour ton éditeur de code ou une application desktop. Il dialogue avec un modèle d’intelligence artificielle dans le nuage pour exécuter des tâches complexes : écrire du code, lancer des tests, modifier des fichiers, créer des branches Git… Par défaut, Codex hérite des droits de l’utilisateur qui l’utilise. Résultat ? Il peut faire tout ce que tu peux faire, y compris des choses dangereuses sans que tu t’en rendes compte.

Imagine : tu demandes à Codex de corriger un bug dans ton projet. L’IA te propose une solution, mais en réalité, elle exécute des commandes locales, lit ou modifie des fichiers, et peut même accéder à internet si tu ne fais pas attention. Pas idéal pour la sécurité.

LE SANDBOX : UNE PRISON POUR CODEX

Pour résoudre ce problème, OpenAI a eu une idée simple : enfermer Codex dans une sandbox. Un sandbox, c’est un environnement d’exécution limité où les actions sont restreintes. Quand tu utilises Codex, ton système d’exploitation lance une commande avec des permissions réduites, et ces restrictions s’appliquent à tous les processus qui en découlent. Chaque commande de Codex est isolée dès le départ, et tous ses descendants restent dans la même zone de sécurité.

Le problème ? Windows ne propose pas de solution native pour créer un sandbox aussi efficace que ceux disponibles sur macOS (avec Seatbelt) ou Linux (avec seccomp ou bubblewrap). OpenAI a donc dû inventer son propre système pour offrir aux utilisateurs Windows la même sécurité que sur les autres plateformes.

LES Outils DE WINDOWS : UNE BOÎTE À OUTILS INCOMPLÈTE

Windows offre quelques mécanismes d’isolation, mais aucun ne répondait parfaitement aux besoins de Codex. OpenAI a étudié plusieurs solutions : AppContainer, Windows Sandbox, et le Mandatory Integrity Control (MIC), un système de classification des processus selon leur niveau de confiance. Aucun de ces outils ne permettait de limiter précisément les accès aux fichiers et au réseau sans demander des droits d’administrateur à l’utilisateur.

L’équipe a donc décidé de concevoir son propre sandbox, en combinant plusieurs concepts et outils de Windows. L’objectif était clair : créer un environnement sécurisé pour Codex, sans demander de droits élevés à l’utilisateur. Autrement dit, Codex devait fonctionner sans que tu aies besoin d’accepter des fenêtres de confirmation d’administrateur à chaque utilisation.

LES SID : DES IDENTITÉS VIRTUELLES POUR ISOLER CODEX

Pour limiter les accès aux fichiers, OpenAI a utilisé deux piliers de Windows : les SID (Security Identifiers) et les tokens restreints en écriture. Un SID, c’est une sorte de carte d’identité numérique que Windows attribue à chaque utilisateur, groupe ou session. Par exemple, ton SID personnel pourrait ressembler à S-1-5-5-X-Y, tandis que le groupe des administrateurs locaux a un SID comme S-1-5-32-544.

Windows permet aussi de créer des SID synthétiques, qui n’existent pas dans la réalité mais peuvent être utilisés dans les listes de contrôle d’accès (ACL). Ces ACL définissent qui peut lire, écrire ou exécuter des fichiers ou dossiers. OpenAI a exploité cette fonctionnalité pour créer un SID dédié uniquement au sandbox de Codex, sans interférer avec le reste de la machine.

Un token restreint en écriture est un type de token de processus qui ajoute une vérification supplémentaire pour les opérations d’écriture. Pour qu’un fichier puisse être modifié, deux conditions doivent être remplies :

• L’utilisateur doit avoir le droit d’écrire dans le fichier (vérification standard).
• Le SID du token doit figurer dans la liste des SID autorisés à écrire (vérification supplémentaire).

En pratique, cela permet de définir exactement où Codex peut modifier le système de fichiers, avec une granularité fine sur les opérations d’écriture.

LE FONCTIONNEMENT DU SANDBOX SANS DROITS ÉLEVÉS

Avec les SID et les tokens restreints en écriture, le sandbox sans droits élevés fonctionnait comme suit :

1. Création d’un token restreint : Codex génère un token avec un SID synthétique et des restrictions en écriture.

2. Lancement d’un processus enfant : Le token restreint est appliqué au processus enfant, limitant ses accès aux fichiers.

3. Exécution des commandes : Toutes les commandes lancées par Codex s’exécutent dans ce token restreint, avec des limites strictes sur les modifications de fichiers.

Cette approche permettait de limiter les accès aux fichiers tout en gardant Codex fonctionnel. Mais il restait un problème majeur : le réseau.

BLOQUER L’INTERNET : UN CASSE-TÊTE TECHNIQUE

Sans contrôle du réseau, un code malveillant pourrait envoyer tes données vers l’extérieur. OpenAI voulait éviter de demander des droits d’administrateur, mais Windows ne propose pas de solution simple pour bloquer le trafic réseau d’un processus spécifique. Le pare-feu Windows, par exemple, nécessite des droits élevés pour être configuré.

L’équipe a donc tenté de rendre l’environnement du sandbox fail-closed pour les outils de développement courants. L’idée : faire échouer les commandes réseau que Codex pourrait utiliser, comme Git ou les installateurs de paquets. Pour cela, ils ont redirigé le trafic vers des points morts, bloqué les connexions HTTP(S) de Git, et forcé l’échec des commandes Git via SSH. Ils ont aussi ajouté un répertoire denybin en début de variable PATH, et modifié PATHEXT pour que des scripts fictifs bloquent les commandes SSH et SCP avant qu’elles n’atteignent les vrais exécutables.

Voici quelques exemples de variables d’environnement modifiées pour limiter l’accès au réseau :

HTTPS_PROXY=http://127.0.0.1:9
ALL_PROXY=http://127.0.0.1:9
GITHTTPSPROXY=http://127.0.0.1:9
NO_PROXY=localhost,127.0.0.1,::1
GITSSHCOMMAND=cmd /c exit 1

Ces modifications attrapaient beaucoup de trafic normal, mais elles restaient advisory : un processus pouvait ignorer ces variables, contourner le PATH, ou ouvrir des sockets directement. Trop risqué.

LE PREMIER PROTOTYPE : DES SUCCÈS… ET DES ÉCHECS

Le premier prototype du sandbox sans droits élevés avait des avantages :

• Il utilisait uniquement des outils standards de Windows.
• Il permettait un contrôle très précis des accès aux fichiers.
• Il fonctionnait sans demander de droits d’administrateur.

Mais il avait aussi des défauts rédhibitoires :

• Il ne permettait pas de contrôler finement les accès réseau.
• Les restrictions réseau étaient faciles à contourner.
• Il était trop flexible pour les flux de travail automatisés (agentic flows).
• Il nécessitait une configuration complexe pour chaque utilisateur.

Face à ces limites, OpenAI a décidé d’investir dans une version améliorée du sandbox, même si cela signifiait demander des droits d’administrateur au moment de l’installation.

LE SANDBOX ÉLEVÉ : UNE SOLUTION PLUS SÛRE (MAIS PLUS COMPLIQUÉE)

La nouvelle version du sandbox, appelée sandbox élevé, nécessite des droits d’administrateur uniquement au moment de l’installation. Une fois configuré, Codex peut fonctionner normalement, sans demander de droits supplémentaires à l’utilisateur. Voici comment ça marche :

Au lieu de faire tourner les commandes sous le token de l’utilisateur réel, le sandbox élevé utilise un utilisateur dédié créé par Codex lui-même. Ce nouvel utilisateur a un token restreint, mais il est indépendant du compte Windows de l’utilisateur. Cela change tout :

1. Création d’un utilisateur dédié : Codex crée un utilisateur local, comme CodexSandbox.

2. Configuration des règles de pare-feu : Des règles sont ajoutées pour bloquer tout le trafic réseau sortant pour cet utilisateur.

3. Lancement des commandes : Les commandes sont exécutées sous cet utilisateur dédié, avec un token restreint.

Le résultat ? Un contrôle bien plus strict du réseau et des fichiers, au prix d’une installation plus complexe.

LA CONFIGURATION : UNE ÉTAPE DÉLICATE

Le sandbox élevé ajoute une étape de configuration supplémentaire par rapport à la version sans droits élevés :

1. Installation en tant qu’administrateur : L’utilisateur doit accepter une fenêtre de confirmation UAC pour installer le sandbox.

2. Création de l’utilisateur dédié : Codex crée un utilisateur local avec des permissions limitées.

3. Configuration des ACL : Des listes de contrôle d’accès (ACL) sont ajoutées pour autoriser la lecture des fichiers nécessaires, comme le dossier de profil de l’utilisateur.

4. Configuration des règles de pare-feu : Des règles sont ajoutées pour bloquer tout le trafic réseau sortant pour l’utilisateur dédié.

Cette configuration est asynchrone : certaines étapes peuvent prendre du temps, mais elles ne bloquent pas l’utilisateur pendant l’installation.

POURQUOI UN UTILISATEUR DÉDIÉ ?

Utiliser un utilisateur dédié permet de contourner une limitation majeure de Windows : la frontière entre les tokens de processus. Avec la version sans droits élevés, Codex ne pouvait pas créer un processus enfant sous un token restreint à partir du token de l’utilisateur réel. La solution ? Faire tourner le processus enfant sous un utilisateur déjà connecté, ce qui permet d’appliquer les restrictions côté utilisateur dédié plutôt que côté utilisateur réel.

Cela a conduit à la création d’un nouveau binaire : codex-command-runner.exe. Son rôle ? Créer un token restreint et lancer la commande demandée sous l’utilisateur dédié. Le flux complet ressemble à ceci :

1. Codex.exe (utilisateur réel) : Lance le processus codex-command-runner.exe sous l’utilisateur dédié.

2. codex-command-runner.exe (utilisateur dédié) : Crée un token restreint et lance la commande demandée avec les restrictions appropriées.

Cette séparation permet de gérer les restrictions côté utilisateur dédié, où les permissions sont plus faciles à appliquer.

LA LECTURE DES FICHIERS : UN DÉFI INSOUPÇONNÉ

Dans la version sans droits élevés, le token restreint utilisait le SID de l’utilisateur réel, ce qui permettait à Codex de lire les fichiers comme s’il s’agissait de l’utilisateur. Mais avec un utilisateur dédié, les permissions par défaut de Windows interdisent à un utilisateur de lire les fichiers d’un autre utilisateur. Par exemple, le dossier de profil d’un utilisateur n’est pas accessible par défaut à un autre utilisateur.

Pour résoudre ce problème, OpenAI a ajouté une étape supplémentaire : la configuration des ACL pour autoriser la lecture des fichiers nécessaires. Par exemple :

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

Ces configurations sont faites de manière asynchrone pour ne pas bloquer l’utilisateur pendant l’installation. La liste des répertoires à configurer est déterminée de manière empirique, en fonction des besoins courants des développeurs.

UNE ARCHITECTURE EN QUATRE COUCHES

Le sandbox final d’OpenAI repose sur quatre couches principales :

1. Codex.exe : Le binaire principal qui gère l’interaction avec l’utilisateur et l’IA dans le nuage.

2. codex-windows-sandbox-setup.exe : Le binaire responsable de la configuration du sandbox, y compris la création de l’utilisateur dédié et la configuration des ACL.

3. codex-command-runner.exe : Le binaire qui lance les commandes sous l’utilisateur dédié avec un token restreint.

4. Les règles de pare-feu : Les règles qui bloquent le trafic réseau sortant pour l’utilisateur dédié.

Chaque couche a un rôle précis, ce qui permet de séparer les responsabilités et de simplifier la maintenance du code.

UNE SOLUTION NÉCESSAIREMENT COMPLEXE

Quand l’ingénieur d’OpenAI a commencé ce projet, il ne savait pas où il allait aboutir. Son approche initiale était d’instrumenter la capacité de sandboxing au niveau de la frontière entre Codex et le système d’exploitation, comme c’est déjà fait sur macOS et Linux. Mais en étudiant les outils spécifiques à Windows, et après des dizaines de décisions pour équilibrer sécurité et facilité d’utilisation, le système a évolué vers sa forme actuelle : plusieurs binaires, des utilisateurs dédiés, des règles de pare-feu, une étape d’installation élevée, des processus asynchrones…

Ce n’est pas un système simple, mais chaque élément de complexité a été ajouté par nécessité, pour créer un sandbox à la fois sûr et peu intrusif pour l’utilisateur.

SÉCURITÉ VS UTILITÉ : LE GRAND ÉQUILIBRE

Le but d’OpenAI était de créer un sandbox qui soit à la fois sûr et utile. Après tout, l’intérêt de Codex, c’est de pouvoir automatiser des tâches sans avoir à surveiller en permanence ce qu’il fait. Mais comment concilier sécurité et automatisation ?

L’équipe a rapidement compris que Windows ne proposait pas de solution clé en main pour un agent de codage autonome et sécurisé. Ils ont dû combiner plusieurs outils et concepts pour créer quelque chose de cohérent. Certaines idées initiales ont été abandonnées, et la solution finale est un hybride de plusieurs prototypes, chacun résolvant une partie du problème.

Une autre leçon importante : la sécurité pour un agent de codage est très différente de la sécurité classique pour une application. Codex doit s’intégrer dans les flux de travail réels des développeurs, ce qui complique encore les choses. L’ingénierie derrière ce projet consistait à équilibrer la compatibilité avec les charges de travail automatisées et l’application stricte des restrictions.

EN PRATIQUE : COMMENT ÇA MARCHE AUJOURD’HUI ?

Le sandbox actuel d’OpenAI pour Codex sur Windows repose sur plusieurs mécanismes :

1. Création d’un utilisateur dédié : CreateProcessAsUserW est utilisé pour lancer des processus sous cet utilisateur.

2. Tokens restreints : CreateRestrictedToken crée un token avec des restrictions en écriture et en réseau.

3. Règles de pare-feu : Des règles bloquent tout le trafic réseau sortant pour l’utilisateur dédié.

4. ACL personnalisées : Des permissions sont configurées pour permettre la lecture des fichiers nécessaires.

Voici un exemple simplifié du flux d’exécution :

OpenProcessToken(GetCurrentProcess(), .)
GetTokenInformation(.)
CreateRestrictedToken(.)
CreateProcessAsUserW(.)
CreateProcessWithLogonW(.)

Ce flux garantit que chaque commande exécutée par Codex est isolée, sécurisée et limitée dans ses actions.

LES LEÇONS APPRISES : UN PROJET QUI A CHANGÉ LA DONNE

Ce projet a révélé plusieurs enseignements clés :

1. Windows n’offre pas de solution native pour un sandboxing efficace : Contrairement à macOS et Linux, Windows ne propose pas de mécanisme simple pour isoler un processus avec des restrictions fines. OpenAI a dû inventer sa propre solution.

2. La sécurité pour un agent de codage est un cas particulier : Les agents comme Codex doivent fonctionner dans des environnements réels, avec des outils de développement complexes. La sécurité ne peut pas être trop restrictive, sous peine de rendre l’outil inutilisable.

3. L’équilibre entre sécurité et utilité est délicat : Chaque restriction ajoutée doit être justifiée par un gain de sécurité, sans nuire à la productivité de l’utilisateur. C’est un exercice d’équilibriste.

4. La modularité est essentielle : En séparant les responsabilités entre plusieurs binaires (setup, runner, etc.), OpenAI a pu simplifier la maintenance et améliorer la sécurité.

ET DEMAIN ?

OpenAI continue d’améliorer son sandbox pour Codex sur Windows. L’objectif est de rendre l’outil encore plus sûr, tout en simplifiant son installation et son utilisation. Avec cette solution, les utilisateurs Windows peuvent enfin profiter de Codex sans compromis : une sécurité renforcée, une productivité préservée, et une expérience utilisateur fluide.

Si tu veux voir le sandbox de Codex en action, tu peux essayer l’outil directement.