Créer une sandbox sûre et efficace pour activer Codex sur Windows

Quand j’ai rejoint l’équipe d’ingénierie Codex en septembre 2025, Codex pour Windows n’avait pas d’implémentation de la sandbox, ce qui signifiait que les utilisateurs Windows étaient forcés de choisir entre deux options peu satisfaisantes lorsqu’ils utilisaient les agents de codage d’OpenAI :

1. Approuver presque chaque commande (même les simples lectures) qu’un agent de code souhaite exécuter, ce qui est inefficace et fastidieux. L’un des principaux avantages de l’utilisation de Codex est que vous n’avez pas à faire vous-même tout le travail fastidieux.
2. Activer le mode Accès complet : laisser Codex exécuter toutes les commandes sans approbation ni restrictions, ce qui réduit les frictions au détriment de la supervision.

Codex⁠, notre agent de codage, s’exécute sur les ordinateurs portables des développeurs, que ce soit via le CLI, l’extension IDE ou l’application de bureau. Il gère une conversation entre un humain au clavier et un modèle exécuté dans le cloud pour effectuer l’inférence.

Par défaut, Codex s’exécute avec les permissions d’un véritable utilisateur, ce qui signifie qu’il peut faire tout ce que l’utilisateur peut faire. C’est puissant et potentiellement dangereux. Le modèle de codage peut dire au harness d’exécuter des commandes localement, qu’il s’agisse de lancer des tests, de lire ou modifier un fichier ou de créer une branche Git ; le mode par défaut de Codex cherche donc à trouver le bon équilibre entre efficacité et sécurité. Ce mode par défaut permet à Codex de lire des fichiers presque partout et d’écrire des fichiers dans votre espace de travail (c’est-à-dire le répertoire où vous exécutez Codex), sans accès à Internet sauf si vous précisez que vous le souhaitez. Pour assurer automatiquement cette limitation de l’écriture de fichiers et de l’accès réseau dans des limites sûres, Codex a besoin d’un environnement de la sandbox qui applique réellement ces contraintes.

Une sandbox est un environnement d’exécution contraint. Lorsqu’un développeur utilise Codex, le système d’exploitation de son ordinateur lance une commande avec des permissions réduites, et ces contraintes se propagent dans l’arborescence des processus. Chaque commande Codex est isolée dans une sandbox dès le départ, et chaque processus descendant reste à l’intérieur de ce même périmètre.

Codex a besoin de fonctionnalités d’isolation imposées par le système d’exploitation de l’ordinateur pour mettre en œuvre une sandbox efficace. Certains systèmes d’exploitation fournissent des utilitaires qui le font bien (par ex. Seatbelt sur MacOs, seccomp ou bubblewrap sur Linux) ; toutefois, Windows ne fournit actuellement pas ce type de capacité prêt à l’emploi.

Pour rendre Codex aussi sûr et agréable à utiliser sur Windows qu’il l’est déjà partout ailleurs, nous devions implémenter notre propre sandbox.

Windows propose certains outils et primitives d’isolation. Bien qu’aucun ne réponde vraiment à nos exigences, nous avons étudié plusieurs solutions potentielles, notamment AppContainer, Windows Sandbox et l’étiquetage Mandatory Integrity Control.

AppContainer

• Quoi : AppContainer est la sandbox native de Windows, un modèle d’isolation fondé sur les capacités, conçu pour des applications qui savent à l’avance exactement à quoi elles doivent accéder.
• Pourquoi : Intéressant, car il offre une véritable frontière au niveau du système d’exploitation au lieu de restrictions appliquées au mieux.
• Pourquoi pas : Codex n’est pas une application unique au périmètre strictement défini. Il prend en charge des flux de travail de développement ouverts : shells, Git, Python, gestionnaires de paquets, outils de build et tous les autres binaires dont l’agent décide avoir besoin. En pratique, cela faisait d’AppContainer une solution mal adaptée au problème. C’était une isolation forte, mais pour une catégorie de charges de travail beaucoup plus restreinte que « laisser un agent fonctionner comme un développeur ».

Windows Sandbox

• Quoi : La sandbox Windows est une VM légère et jetable de Microsoft. Vous disposez d’un nouvel environnement Windows avec une forte isolation, et tout ce que vous y faites disparaît à la fin de la session.
• Pourquoi : Intéressant pour des raisons évidentes—bien plus compatible avec des logiciels arbitraires qu’AppContainer, et du point de vue de la sécurité, c’est un environnement bien plus solide.
• Pourquoi pas : Codex doit agir directement sur le vrai environnement de l’utilisateur, son tunnel d’achat, ses outils et son système et non dans un bureau temporaire isolé qui nécessiterait une configuration ainsi qu’une passerelle entre l’hôte et l’environnement invité. Il présentait également un problème fondamental lié au produit : la sandbox Windows n’est même pas disponible sur les éditions Windows Famille.

Étiquetage d’intégrité Mandatory Integrity Control (MIC)

• Quoi : Windows dispose d’un concept appelé « niveaux d’intégrité », tels que faible, moyen et élevé, qui déterminent le degré de confiance que le système accorde aux objets et aux processus. La règle de base est qu’un processus de niveau d’intégrité inférieur ne peut pas écrire dans un objet ayant un niveau d’intégrité supérieur, même si la liste de contrôle d’accès (ACL) normale l’autoriserait par ailleurs. Par exemple, un processus à faible intégrité est considéré comme moins fiable ; Windows l’empêche donc d’écrire dans des objets normaux à intégrité moyenne, sauf si ces objets ont été explicitement réétiquetés pour l’autoriser.
• Pourquoi : Sur le papier, MIC paraissait élégant—exécuter Codex avec une faible intégrité, réétiqueter les racines inscriptibles en faible intégrité, puis laisser Windows imposer l’interdiction d’écriture partout ailleurs. Cela nous aurait donné une voie sans droits d’administrateur, adossée à un véritable mécanisme du système d’exploitation.
• Pourquoi pas : comme les ACL, les étiquettes d’intégrité modifient le système de fichiers réel de l’hôte, et dans ce cas, le changement sémantique est particulièrement étendu. Marquer un espace de travail comme étant de faible intégrité ne signifie pas simplement « Codex peut écrire ici ». Cela signifie que les processus à faible niveau d’intégrité de manière générale peuvent y écrire. Sur une vraie machine de développement, cela transforme la copie de travail réelle de l’utilisateur en puits à faible intégrité pour l’hôte, ce qui est bien plus risqué que d’accorder des listes de contrôle d’accès (ACL) soigneusement ciblées à une seule conception de sandbox. Même si les outils de développement à intégrité moyenne continuent de fonctionner, le modèle de confiance sous-jacent de l’espace de travail a changé d’une manière difficile à maîtriser et encore plus difficile à justifier.

Après avoir évalué toutes ces options comme des impasses, nous avons commencé à concevoir notre propre solution pour offrir une bonne expérience Codex aux utilisateurs Windows.

Notre premier prototype fonctionnel utilisait une combinaison de concepts et d’outils Windows pour mettre en œuvre l’isolation dont nous avions besoin. Dès le départ, l’un des objectifs était de faire fonctionner cela sans nécessiter d’élévation, ce qui signifie que Codex n’aurait pas besoin d’afficher un prompt de demande de droits administrateur à l’utilisateur simplement pour configurer ou exécuter la sandbox. Cela impliquait de déterminer comment imposer des limites raisonnables à deux éléments : les opérations d’écriture de fichiers et l’accès au réseau.

Si nous ne limitions pas du tout les écritures de fichiers, nous aurions un problème de sécurité. Si nous les limitions trop, la sandbox nuirait à la productivité des utilisateurs en demandant des approbations constantes. Pour résoudre ce problème, nous nous sommes appuyés sur deux briques importantes de Windows : les SID et les tokens à écriture restreinte.

Un SID, ou identificateur de sécurité, est l’identité que Windows associe aux autorisations. Chaque utilisateur possède un SID, les groupes ont des SID, et même une simple session de connexion se voit attribuer son propre SID. Par exemple, une session actuellement ouverte peut avoir un SID tel que S-1-5-5-X-Y. Le SID attribué au groupe des administrateurs locaux peut être S-1-5-32-544.

Windows permet aussi de créer des SID synthétiques qui ne correspondent pas à un utilisateur réel mais peuvent quand même apparaître dans les ACL (listes de contrôle d’accès), qui définissent qui peut lire/écrire/exécuter des fichiers ou répertoires spécifiques. Les SID constituent donc une primitive utile pour notre sandbox : nous pouvons créer des SID exclusivement destinés à la sandbox de Codex, sans interférer avec quoi que ce soit d’autre sur la machine.

Les tokens de processus sont des objets de sécurité dans Windows qui définissent l’identité et les privilèges d’un processus en cours d’exécution. Ils déterminent les actions qu’un processus peut effectuer. Un token à écriture restreinte est un type particulier de token de processus qui amène Windows à effectuer un contrôle d’accès supplémentaire lors des opérations d’écriture.

Pour qu’une écriture soit autorisée, deux vérifications doivent être validées :

1. L’identité utilisateur normale (le « propriétaire » du token) doit être autorisée à le faire
2. Au moins un SID de la liste des SID restreints du token doit également avoir reçu l’accès

En pratique, ces vérifications nous ont permis d’utiliser les ACL pour définir exactement les endroits du système de fichiers que la sandbox pouvait modifier, ce qui nous donnait la granularité nécessaire pour les opérations d’écriture.

Avec les SID et les tokens à écriture restreinte, notre sandbox sans élévation de privilèges fonctionnait ainsi :

1. La configuration de la sandbox créait un SID synthétique appelé sandbox-write.
2. Le SID sandbox-write s’est vu accorder des droits d’écriture, d’exécution et de suppression sur
   1. Le répertoire de travail actuel
   2. Tous les writable_roots supplémentaires configurés dans config.toml.
3. La configuration du sandbox a explicitement refusé à ce même SID les droits d’écriture sur des emplacements « en lecture seule dans une zone accessible en écriture », comme :
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex lançait les commandes avec un token à écriture restreinte dont la liste des SID restreints inclut Everyone, le SID de la session actuellement connectée et le SID synthétique sandbox-write.

Ce flux résolvait efficacement la limitation des écritures de fichiers et semblait prometteur. Nous avions maintenant besoin d’une solution pour limiter l’accès réseau de la sandbox.

Limiter l’accès réseau est une partie importante de la sandbox ; sans cette limite, un code malveillant pourrait exfiltrer des données de la machine vers Internet. Comme nous voulions éviter une exigence d’élévation, nous avions peu d’options pour bloquer fortement le trafic réseau. Les outils que nous voulions utiliser, comme le Pare-feu Windows, ne pouvaient généralement pas être installés sans permissions administrateur.

Le Pare-feu Windows n’étant pas une option, nous avons limité ce que nous pouvions contrôler. Nous avons essayé de faire en sorte que l’environnement enfant fonctionne en mode d’échec fermé (« fail-closed ») pour les types d’outils réseau que les développeurs utilisent réellement, afin que les commandes Git, les installateurs de paquets, etc., échouent dans la sandbox et que l’utilisateur doive approuver toute opération tournée vers Internet. L’idée était de neutraliser les issues de secours évidentes : envoyer le trafic tenant compte du proxy vers un terminal inactif, faire en sorte que le transport HTTP(S) de Git fasse de même, et faire échouer immédiatement Git via SSH. En plus de cela, nous avons ajouté en tête de PATH un petit répertoire denybin et réorganisé PATHEXT afin que les scripts bouchons SSH et SCP soient résolus avant les véritables binaires.

Par exemple, voici quelques-unes des surcharges d’environnement spécifiques que nous avons utilisées pour limiter l’accès réseau :

• HTTPS_PROXY=http://127.0.0.1:9
• ALL_PROXY=http://127.0.0.1:9
• GIT_HTTPS_PROXY=http://127.0.0.1:9
• NO_PROXY=localhost,127.0.0.1,::1
• GIT_SSH_COMMAND=cmd /c exit 1

Cela interceptait une grande partie du trafic normal généré par les outils, mais cela restait seulement indicatif. Un processus pouvait ignorer l’environnement, contourner PATH ou simplement ouvrir directement des sockets—trop risqué.

Comme toute implémentation logicielle intéressante, le premier prototype présentait des avantages et des inconvénients. Même si cette approche remplissait son rôle avec seulement quelques capacités Windows standard, permettait un contrôle très explicite et granulaire des écritures sur le système de fichiers, et fonctionnait sans élévation de privilèges—évitant ainsi aux utilisateurs d’avoir à accepter des demandes d’élévation excessives ou d’être administrateurs sur leur machine locale—elle présentait de réelles limites, dont certaines nous ont empêchés d’en faire notre architecture finale :

• Vitesse de configuration : l’application d’ACL à l’espace de travail peut être coûteuse selon la topologie du répertoire de l’espace de travail.
• Empreinte : nous appliquions de vraies ACL au système du développeur, même si cette empreinte n’est pas particulièrement invasive, car toutes les ACL appliquées concernent un SID synthétique créé sur mesure qui n’est utilisé que par la sandbox.
• Sémantique difficile à modifier : le recours aux listes de contrôle d’accès (ACL) pour les restrictions basées sur les fichiers rend la modification de la sémantique de la sandbox coûteuse et complexe. Alors que sur macOS, nous pouvons modifier dynamiquement la manière dont nous générons le fichier .sbpl utilisé pour configurer Seatbelt, la sandbox Windows pourrait nécessiter une opération lente et intensive pour ajuster les ACL.
• La protection du réseau est faible. Comme mentionné précédemment, elle était « indicative », serait certainement contournée par certains programmes qui implémentent leur propre pile réseau et n’était pas conçue pour résister à du code adverse.

Les trois premiers problèmes sont inhérents à une implémentation personnalisée de la sandbox suffisamment flexible pour des flux agentiques. En revanche, la question de la suppression réseau était différente.

En plus du fait qu’un agent malveillant puisse facilement contourner la suppression réseau basée sur l’environnement, de nombreux codes/binaires bien intentionnés la contourneraient aussi simplement s’ils ne respectaient pas les variables d’environnement proxy ou s’ils implémentaient leur propre code réseau basé sur des sockets. Nous avons estimé que cet aspect suffisait à justifier un investissement dans un meilleur mode de la sandbox.

Pour obtenir une meilleure suppression réseau, nous voulions utiliser le Pare-feu Windows, qui nous permet de bloquer le trafic réseau sortant pour des utilisateurs ou des programmes. Malheureusement, nous ne pouvions pas créer efficacement une règle de pare-feu fonctionnelle qui s’applique uniquement aux commandes engendrées par le harness Codex pour plusieurs raisons :

• Windows ne permet pas de faire correspondre une règle de pare-feu à l’identité non principale d’un token restreint. Cela signifie que nous ne pouvions pas appliquer une règle de pare-feu à « tout token incluant notre SID synthétique dans sa liste de SID restreints ».
• Bien que nous puissions créer une règle de pare-feu correspondant à un binaire spécifique, cela nous permet seulement de limiter le réseau pour codex.exe lui-même. Cela ne s’appliquerait pas aux processus que l’agent lance pour le compte de l’utilisateur, comme les processus Git ou Python.
• D’autres dimensions de correspondance du pare-feu avaient également un format incorrect. Les règles à portée utilisateur correspondaient toujours à l’utilisateur Windows réel dans la conception sans élévation de privilèges, et pas seulement à l’enfant restreint. Les règles basées sur le chemin du programme étaient trop grossières : elles pouvaient bloquer codex.exe ou python.exe de manière générale, mais pas cette invocation en sandbox spécifique de python.exe. Les règles basées sur les ports ou les adresses constituaient également une politique totalement inadaptée. Par exemple, nous ne voulions pas bloquer le port 443 ; nous voulions bloquer l’accès sortant arbitraire pour cette arborescence de processus restreinte spécifique.

Pour appliquer une règle de pare-feu spécifiquement à nos commandes isolées dans la sandbox, nous devions les exécuter sous un principal distinct, et non sous l’identité du « vrai » utilisateur. Cette approche nous a amenés à explorer une nouvelle direction, dans laquelle nous avons assoupli notre contrainte de « sans élévation ».

La prochaine itération de la sandbox, qui correspond à notre implémentation actuelle, nécessite des droits d’administrateur élevés lors de la configuration. Je l’appelle donc « la sandbox avec élévation de privilèges ». À la limite où Codex lance une commande sur le système, la sandbox avec élévation ressemble à la sandbox sans élévation. Il continue d’exécuter les processus enfants sous un token restreint—là encore un token write_restricted avec la même liste de SID restreints [Everyone, Logon, Synthetic]—mais le principal associé à ce token n’est plus l’utilisateur Windows réel : il s’agit désormais de l’un des deux utilisateurs locaux créés par Codex lui-même :

• CodexSandboxOffline (celui ciblé par les règles de pare-feu)
• CodexSandboxOnline (celui qui n’est pas ciblé par les règles de pare-feu)

Ce détail apparemment mineur a en réalité de grandes implications pour la sandbox, pour les personnes qui peuvent l’utiliser, ainsi que pour la complexité de sa configuration et de son exécution.

Visuellement, il ressemble au prototype sans élévation de privilèges, avec l’introduction de règles de pare-feu et d’un utilisateur Windows dédié, qui exécute réellement les commandes. (Cependant, l’introduction de ces nouveaux concepts signifie qu’il y a plus de travail de configuration à effectuer avant que la sandbox puisse commencer à exécuter et protéger des commandes.)

La conception de la sandbox sans élévation de privilèges comportait une étape de configuration simple, mais relativement réduite :

• Créer un SID synthétique si nécessaire
• Appliquer des ACL pour le SID synthétique sandbox-write

La sandbox avec élévation de privilèges, en revanche, a davantage à faire.

• Créer un SID synthétique, s’il n’existe pas déjà
• Créer les utilisateurs de la sandbox en ligne et hors ligne, s’ils n’existent pas déjà
• Stocker localement les identifiants des utilisateurs nouvellement créés et les chiffrer à l’aide de l’API Windows Data Protection API (DPAPI) dans un emplacement que les utilisateurs de la sandbox ne peuvent pas réellement lire
• Créer des règles de pare-feu qui bloquent tout accès réseau sortant pour l’utilisateur CodexSandboxOffline ou, si elles existent déjà, vérifier qu’elles sont correctes

Il y a une complication supplémentaire lors de l’étape de configuration. La sandbox de Codex est censé disposer d’un accès en lecture équivalent à celui de l’utilisateur Windows réel. Dans la sandbox sans élévation de privilèges, où le SID principal du token restreint était celui de l’utilisateur Windows, cela a été réalisé. Cependant, cela n’est pas sans contrepartie lorsque le principal devient un nouvel utilisateur CodexSandbox. De nombreux répertoires pertinents sous Windows accordent des autorisations de lecture/exécution aux « Utilisateurs authentifiés ». Un exemple notable est le répertoire du profil utilisateur. Par défaut, les utilisateurs Windows ne peuvent pas lire les répertoires de profil des autres utilisateurs Windows ; ainsi, même de simples lectures de fichiers échoueraient dans de nombreux scénarios.

Pour résoudre ce problème, nous avons ajouté une autre couche au processus de configuration de la sandbox, destinée à accorder des ACL de lecture aux utilisateurs de la sandbox là où de telles ACL n’existent pas déjà. Par exemple, vers certains répertoires Windows couramment utilisés :

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

Comme cette liste de répertoires relève du mieux possible et que l’installation d’ACL sur chacun d’eux peut être assez coûteuse, nous exécutons cette logique de manière asynchrone afin que l’étape de configuration du bac à sable, qui bloque les utilisateurs, n’ait pas à attendre leur achèvement.

Nous avons encapsulé la logique de configuration dans son propre binaire, en partie pour ne franchir la limite de l’UAC que lorsque c’est nécessaire. Mais la raison plus profonde était d’ordre architectural : la configuration du bac à sable a une mission fondamentalement différente de celle de codex.exe. Le fait de conserver la logique de configuration du bac à sable dans un binaire dédié a permis à codex.exe de rester un harness classique sans élévation de privilèges ; d’éviter que la logique de configuration spécifique à Windows n’alourdisse pas codex.exe sur les autres plateformes ; de dissocier les tâches de configuration plus longues de la durée de vie du processus principal ; et de centraliser la gestion des différents parcours de configuration nécessaires au bac à sable.

En raison du fonctionnement des frontières de connexion entre utilisateurs et tokens sous Windows, nous ne pouvions plus continuer à créer un token restreint puis lancer un processus sous celui-ci comme nous le faisions avec le bac à sable sans élévation de privilèges. Pour réellement exécuter des commandes sous un autre utilisateur Windows, notre première idée reposait sur le flux suivant :

• codex.exe s’exécute en tant que l’utilisateur Windows réel. Ensuite, dans une séquence, Codex :
  • Appelle LogonUserW(...) pour l’utilisateur du bac à sable.
  • Appelle CreateRestrictedToken(...) sur ce token d’utilisateur de bac à sable.
  • À l’aide de ce token d’utilisateur de bac à sable restreint, appelle CreateProcessAsUserW(...) pour lancer le processus enfant final.

En pratique, ce flux souhaité n’a pas fonctionné en raison d’une barrière de privilèges au niveau de CreateProcessAsUserW(...). Cela signifie que codex.exe pouvait créer un token restreint pour l’utilisateur du bac à sable, mais qu’il ne pouvait pas lancer de manière fiable un processus enfant avec ce token depuis le côté « utilisateur réel » de la frontière. Nous avions besoin d’un processus qui s’exécutait déjà en tant qu’utilisateur de bac à sable : cela permettrait à l’étape de restriction et au lancement final de se produire du côté de l’utilisateur sandbox de la frontière, plutôt que du côté de l’utilisateur réel.

Cette exigence a donné naissance à codex-command-runner.exe, un nouveau binaire dont la seule tâche consiste à créer un token restreint et à lancer la commande demandée. Au lieu de demander à codex.exe de gérer lui-même l’ensemble du flux (utilisateur réel → utilisateur de bac à sable → token restreint → processus enfant), nous avons scindé le flux en deux :

Partie 1

• codex.exe appelle CreateProcessWithLogonW(...) pour lancer codex-command-runner.exe en tant qu’utilisateur du bac à sable, sans encore utiliser de token restreint.

Partie 2

• Dans le runner, OpenProcessToken(GetCurrentProcess(), ...) ouvre le propre token du runner, qui appartient déjà à l’utilisateur du bac à sable.
• Le runner appelle GetTokenInformation(...) pour extraire le SID de connexion du bac à sable, puis CreateRestrictedToken(...) pour construire le token restreint final.
• Toujours dans le runner, il appelle CreateProcessAsUserW(...) avec ce token restreint pour lancer le véritable processus enfant.

Albert Einstein a dit : « Il faut rendre les choses aussi simples que possible, mais pas plus simples. » Dans cet esprit, notre conception a résolu de manière adéquate chaque problème. L’architecture finale comporte les quatre couches que nous avons déjà couvertes :

• codex.exe lui-même
• codex-windows-sandbox-setup.exe pour gérer tout le travail de configuration élevée
• codex-command-runner.exe pour exécuter les commandes sous token restreint
• Le processus enfant

Lorsque j’ai abordé ce projet pour la première fois, je n’avais pas une idée très précise de l’endroit où il aboutirait. Mon approche a consisté à commencer par instrumenter la capacité d’isolation dans le bac à sable à la frontière entre Codex et le système d’exploitation. Cette approche correspond étroitement à la manière dont le bac à sable de Codex est implémenté sur MacOs et Linux.

À mesure que j’en apprenais davantage sur les outils spécifiques fournis par Windows, et au fil de dizaines de décisions arbitrant entre sécurité et facilité d’utilisation, le système a évolué jusqu’à sa forme actuelle : plusieurs binaires, des utilisateurs personnalisés, des règles de pare-feu, une étape de configuration élevée, des processus asynchrones, et plus encore.

Ce n’est pas un système particulièrement simple, mais chaque élément de complexité a été ajouté par nécessité, afin de construire un bac à sable qui soit à la fois sûr et, autant que possible, ne gêne pas l’utilisateur.

En travaillant à offrir une bonne expérience utilisateur aux utilisateurs de Codex sur Windows, notre objectif était de créer quelque chose de sûr sans faire de compromis sur l’utilité—tout l’intérêt d’utiliser Codex est de permettre à des agents d’effectuer du travail sans nécessiter votre attention constante.

L’un des plus grands enseignements de ce projet a été que Windows ne nous a pas fourni une primitive unique correspondant proprement à « agent de codage autonome sûr ». Nous avons combiné plusieurs outils et concepts pour construire quelque chose de cohérent. Certaines premières idées se sont révélées être des impasses. La conception finale était un hybride de prototypes antérieurs, chacun résolvant une partie du problème.

L’autre enseignement, c’est que la sécurité d’un agent de code est très différente de celle d’une application classique. Codex doit fonctionner dans de vrais workflows de développement. Le travail d’ingénierie consistait à trouver le bon équilibre entre la compatibilité avec des charges de travail agentiques et une application réelle des mécanismes de sécurité. Cette tension a façonné les compromis retenus dans l’architecture finale.

Envie de voir le bac à sable Codex en action ? Essayez-le⁠.