Créer un bac à sable sûr et efficace pour activer Codex sous Windows

Quand je me suis joint à l’équipe d’ingénierie de Codex en septembre 2025, Codex pour Windows n’avait pas d’implémentation de bac à sable, ce qui signifiait que les utilisateurs de Windows devaient choisir entre deux options de qualité inférieure 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. Un grand avantage de l’utilisation de Codex est que vous n’avez pas à effectuer toutes les tâches fastidieuses vous-même.
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 une personne au clavier et un modèle qui s’exécute dans le nuage pour effectuer l’inférence.

Par défaut, Codex s’exécute avec les autorisations 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 demander au harnais 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 tente donc de 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.-à-d. le répertoire où vous exécutez Codex), sans accès à Internet à moins que vous ne précisiez le vouloir. Pour imposer automatiquement ces limites d’écriture de fichiers et d’accès réseau dans des bornes sûres, Codex a besoin d’un environnement de bac à sable qui applique réellement ces contraintes.

Un bac à sable est un environnement d’exécution restreint. Lorsqu’un développeur utilise Codex, le système d’exploitation de son ordinateur lance une commande avec des autorisations réduites, et ces contraintes se propagent dans l’arborescence des processus. Chaque commande Codex est exécutée dans un bac à sable dès le départ, et tous les processus descendants restent à l’intérieur du même périmètre.

Codex a besoin de fonctions d’isolation appliquées par le système d’exploitation de l’ordinateur pour mettre en œuvre un bac à sable efficace. Certains systèmes d’exploitation offrent des utilitaires qui font bien ce travail (p. ex., Seatbelt sur MacOs, seccomp ou bubblewrap sur Linux); toutefois, Windows n’offre pas actuellement ce type de capacité d’emblée.

Pour que Codex soit tout aussi sûr et agréable à utiliser sous Windows qu’il l’est déjà partout ailleurs, nous devions implémenter notre propre bac à sable.

Windows offre certains outils et primitives d’isolation. Même si aucun ne répondait tout à fait à nos exigences, nous avons examiné un certain nombre de solutions potentielles, notamment AppContainer, Windows Sandbox et l’étiquetage Mandatory Integrity Control.

AppContainer

• Quoi : AppContainer est le bac à sable natif de Windows, un modèle d’isolation fondé sur les capacités conçu pour des applications qui savent d’avance exactement à quoi elles doivent accéder.
• Pourquoi : attrayant, car il offre une véritable frontière du système d’exploitation au lieu de restrictions approximatives.
• Pourquoi pas : Codex n’est pas une seule application au périmètre étroitement défini. Il pilote des flux de travail de développement ouverts : interpréteurs de commandes, Git, Python, gestionnaires de paquets, outils de génération et tout autre binaire dont l’agent estime avoir besoin. En pratique, cela faisait d’AppContainer une solution mal adaptée au problème. Il s’agissait d’une isolation forte, mais pour une catégorie de charges de travail beaucoup plus restreinte que « laisser un agent agir comme un développeur ».

Windows Sandbox

• Quoi : Windows Sandbox est la machine virtuelle 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 — beaucoup plus compatible avec les logiciels arbitraires qu’AppContainer, et du point de vue de la sécurité, c’est une boîte beaucoup 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 aussi un problème fondamental sur le plan du produit : la Windows Sandbox n’est même pas offerte 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 bac à sable. 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 les options et constaté qu’elles ne convenaient pas, nous avons commencé à concevoir notre propre solution pour offrir une bonne expérience Codex aux utilisateurs de 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 en sorte que cela fonctionne sans nécessiter d’ élévation de privilèges, ce qui signifie que Codex n’aurait pas besoin d’invite l’utilisateur à accorder des privilèges d’administrateur simplement pour configurer ou exécuter le bac à sable. Cela signifiait qu’il fallait déterminer comment imposer des limites raisonnables à deux choses : 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, le bac à sable nuirait à la productivité de l’utilisateur en exigeant une approbation constante. Pour résoudre ce problème, nous nous sommes appuyés sur deux éléments importants 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 seule session de connexion obtient son propre SID. Par exemple, une session actuellement ouverte pourrait avoir un SID comme S-1-5-5-X-Y. Le SID attribué au groupe des administrateurs locaux pourrait ê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 qui peuvent tout de même apparaître dans les ACL (listes de contrôle d’accès), lesquelles définissent qui peut lire/écrire/exécuter des fichiers ou répertoires précis. Cela fait des SID une primitive utile pour notre bac à sable : nous pouvons créer des SID exclusivement pour le bac à sable 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 restreint en écriture est un type particulier de token de processus qui amène Windows à effectuer une vérification 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 aussi se voir accorder l’accès

En pratique, ces vérifications nous ont permis d’utiliser les ACL pour définir exactement où le bac à sable pouvait modifier le système de fichiers, ce qui offrait la granularité dont nous avions besoin pour les opérations d’écriture.

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

1. La configuration du bac à sable 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 bac à sable refusait explicitement à ce même SID l’accès en écriture à des emplacements « lecture seule dans inscriptible » comme :
   1. <cwd>/.git
   2. <cwd>/.codex
   3. <cwd>/.agents
4. Codex lançait des commandes avec un token à écriture restreinte dont la liste des SID restreints comprend Everyone, le SID de la session ouverte actuelle et le SID synthétique sandbox-write.

Ce flux a effectivement résolu le problème de la limitation des écritures de fichiers et semblait prometteur. Il nous fallait maintenant une solution pour limiter l’accès réseau du bac à sable.

Limiter l’accès réseau est une partie importante du bac à sable; 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 de privilèges, 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 adopte une approche de refus par défaut (« fail-closed ») pour les types d’outils connectés que les développeurs utilisent réellement, afin que les commandes Git, les installateurs de paquets, etc., échouent dans le bac à sable et que l’utilisateur doive approuver toute opération impliquant Internet. L’idée était de piéger les échappatoires évidentes : acheminer le trafic tenant compte des serveurs mandataires 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. De plus, nous avons ajouté un petit répertoire denybin au début de PATH et réordonné PATHEXT afin que les scripts SSH et SCP de substitution soient résolus avant les vrais binaires.

Par exemple, voici quelques-unes des substitutions d’environnement précises 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 purement indicatif. Un processus pouvait ignorer l’environnement, contourner PATH ou simplement ouvrir des sockets directement—trop risqué.

Comme toute implémentation logicielle intéressante, le premier prototype présentait certains avantages et inconvénients. Bien qu’il accomplissait le travail avec seulement quelques capacités Windows standard, permettait des écritures dans le système de fichiers très explicites et granulaires, et s’exécutait sans élévation de privilèges — ce qui réduisait la nécessité pour les utilisateurs d’accepter des invites d’élévation excessives ou d’être administrateurs sur leur machine locale — il présentait de réels inconvénients, dont certains l’ont disqualifié comme conception 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 avons appliqué de véritables ACL au système du développeur, même si l’empreinte n’est pas particulièrement envahissante, puisque toutes les ACL appliquées concernent un SID synthétique créé sur mesure et utilisé uniquement par le bac à sable.
• Sémantique difficile à modifier : Le recours aux listes de contrôle d’accès (ACL) pour les restrictions basées sur les fichiers signifie qu’il est coûteux et complexe de modifier la sémantique du bac à sable. Alors que sur macOS, nous pouvons modifier dynamiquement la façon dont nous générons le .sbpl fichier utilisé pour configurer Seatbelt, le bac à sable Windows pourrait nécessiter une opération lente et intensive pour ajuster les ACL.
• La protection du réseau est faible. Comme mentionné plus haut, elle était « indicative », serait certainement contournée par certains programmes qui implémentaient leur propre pile réseau et n’était pas conçue pour résister à du code malveillant.

Les trois premiers problèmes sont inhérents à une implémentation personnalisée de bac à sable assez souple pour les flux agentiques. L’histoire de la suppression du réseau, elle, était différente.

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

Pour obtenir une meilleure suppression du 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’appliquerait uniquement aux commandes lancées par le harnais Codex pour quelques 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 qui comprend notre SID synthétique dans sa liste de SID restreints ».
• Même si nous pouvions créer une règle de pare-feu qui correspond à un binaire précis, 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 n’avaient pas non plus le bon format. Les règles à portée utilisateur correspondaient encore au véritable utilisateur Windows dans la conception sans élévation de privilèges, et pas seulement à l’enfant restreint. Les règles fondées sur le chemin d’accès du programme manquaient de granularité : elles pouvaient bloquer codex.exe ou python.exe de façon générale, mais pas cette invocation précise de python.exe exécutée dans un bac à sable. Les règles fondées sur les ports ou les adresses constituaient également une politique tout à fait inappropriée. Par exemple, nous ne voulions pas bloquer le port 443; nous voulions plutôt bloquer l’accès sortant arbitraire pour cette arborescence de processus restreinte précise.

Pour appliquer une règle de pare-feu spécifiquement à nos commandes mises en bac à sable, nous devions les exécuter comme une unité distincte, et non comme un « véritable » utilisateur. Cette approche nous a conduits sur une nouvelle voie, dans laquelle nous avons assoupli notre contrainte de « pas d’élévation de privilèges ».

La prochaine itération du bac à sable, qui correspond à notre mise en œuvre actuelle, nécessite des privilèges d’administrateur élevés au moment de la configuration. Je l’appelle donc « le bac à sable avec élévation de privilèges ». À la limite où Codex lance une commande sur le système, le bac à sable avec élévation de privilèges ressemble au bac à sable sans élévation de privilèges. Il exécute toujours les processus enfants sous un token restreint — de façon similaire, un token write_restricted avec la même liste de SID restreints, soit [Everyone, Logon, Synthetic]— toutefois, le principal de ce token n’est plus l’utilisateur Windows réel, mais l’un des deux utilisateurs locaux créés par Codex lui-même :

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

Ce détail apparemment mineur a en fait de grandes conséquences pour le bac à sable, les personnes qui peuvent l’utiliser et la complexité de sa configuration et de son exécution.

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

La conception du bac à sable sans élévation de privilèges comportait une étape de configuration simple, mais relativement limitée :

• Créer un SID synthétique au besoin
• Appliquer des ACL pour le SID synthétique sandbox-write

Le bac à sable avec élévation de privilèges, toutefois, a plus à faire.

• Créer un SID synthétique, s’il n’est pas déjà créé
• Créer les utilisateurs de bac à sable en ligne et hors ligne, s’ils ne sont pas déjà créés
• Stocker localement les informations d’identification des utilisateurs nouvellement créés et les chiffrer au moyen de l’API Windows Data Protection (DPAPI) dans un emplacement que les utilisateurs du bac à sable 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à, valider qu’elles sont correctes

Il y a une complication supplémentaire à l’étape de configuration. Le bac à sable de Codex est censé disposer d’un accès en lecture équivalent à celui de l’utilisateur Windows réel. Dans le bac à sable sans élévation de privilèges, où le SID principal du token restreint était l’utilisateur Windows, cela a été réalisé. Toutefois, ce n’est pas sans coût lorsque le principal devient un nouvel utilisateur de 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 de l’utilisateur. Par défaut, les utilisateurs Windows n’ont pas accès en lecture aux répertoires de profil d’autres utilisateurs Windows; ainsi, même de simples lectures de fichiers échoueraient dans de nombreux scénarios.

Pour corriger cela, nous avons ajouté une autre couche au processus de configuration du bac à sable — une couche visant à accorder des ACL de lecture aux utilisateurs du bac à sable là où ces ACL pourraient ne pas déjà exister. 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 meilleur effort et que l’installation d’ACL sur chacun peut être assez coûteuse, nous exécutons cette logique de façon asynchrone afin que l’étape de configuration du bac à sable, qui bloque l’utilisateur, n’ait pas à attendre leur achèvement.

Nous avons encapsulé la logique d’installation dans son propre exécutable, en partie afin de ne franchir la limite de l’UAC qu’au besoin. Mais la raison plus profonde était d’ordre architectural : la configuration du bac à sable a un rôle fondamentalement différent de celui de codex.exe. En conservant la logique de configuration du bac à sable dans un binaire dédié, codex.exe pouvait demeurer un harnais normal, non privilégié; cela évitait que la machinerie de configuration propre à Windows alourdisse codex.exe sur les autres plateformes; cela découplait le travail de configuration de plus longue durée de la durée de vie du processus principal; et cela nous donnait un endroit unique pour gérer les différents chemins de configuration dont le bac à sable avait besoin.

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

• codex.exe s’exécute en tant qu’utilisateur Windows réel. Puis, 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’un obstacle lié aux 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é de l’utilisateur réel de la limite. Nous avions besoin d’un processus qui s’exécutait déjà en tant qu’utilisateur du bac à sable — cela permettrait à l’étape de restriction et à la création finale du processus de se produire du côté de la limite correspondant à l’utilisateur du bac à sable, plutôt que du côté de l’utilisateur réel.

Cette exigence a mené à codex-command-runner.exe, un nouveau binaire dont le seul rôle est d’émettre un token restreint et de lancer la commande demandée. Au lieu de demander à codex.exe d’effectuer lui-même tout le flux (véritable utilisateur → utilisateur du 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 comme utilisateur du bac à sable, sans encore utiliser de token restreint.

Partie 2

• À l’intérieur du 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 à l’intérieur du runner, il appelle CreateProcessAsUserW(...) avec ce token restreint pour lancer le véritable processus enfant.

Albert Einstein a dit : « Tout devrait être rendu aussi simple que possible, mais pas plus simple. » Dans cet esprit, notre conception a résolu adéquatement chaque problème. L’architecture finale comporte les quatre couches que nous avons couvertes précédemment :

• codex.exe lui-même
• codex-windows-sandbox-setup.exe pour gérer tout le travail de configuration avec élévation de privilèges
• codex-command-runner.exe pour exécuter les commandes à token restreint
• Le processus enfant

Quand 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 consistait à commencer par instrumenter la capacité de mise en bac à sable à la frontière entre Codex et le système d’exploitation. Cette approche correspond étroitement à la façon dont le bac à sable de Codex est implémenté sur MacOs et Linux.

À mesure que j’en ai appris davantage sur les outils précis fournis par Windows, et au fil de dizaines de décisions équilibrant sécurité et facilité d’utilisation, le système a pris sa forme actuelle : plusieurs binaires, des utilisateurs personnalisés, des règles de pare-feu, une étape de configuration privilégié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é, pour bâtir un bac à sable qui soit à la fois sûr et, autant que possible, sans gêner l’utilisateur.

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

L’une des plus grandes leçons de ce projet a été que Windows ne nous a pas fourni une primitive unique correspondant clairement à « 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 des impasses. La conception finale était un hybride de prototypes antérieurs qui résolvaient chacun une partie du problème.

L’autre leçon, c’est que la sécurité pour un agent de codage est différente de la sécurité d’application plus classique. Codex doit fonctionner pour de véritables flux de travail de développeur. Le travail d’ingénierie consistait à équilibrer la compatibilité avec des charges de travail agentiques et une application réelle des règles. Cette tension a façonné les compromis de la conception finale.

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