Architecture du Codex Harness : état, compaction, interfaces et limites de sécurité
OpenAI présente le harness dans Codex as a platform comme le système d’exécution ouvert qui alimente plusieurs expériences Codex. Le modèle propose l’action suivante ; le harness rassemble le contexte, exécute les outils, conserve l’état, puis continue dans les limites configurées ou demande une approbation.
Cela ajoute plusieurs responsabilités de production à la boucle « appeler des outils jusqu’à la fin de la tâche ». Le travail doit se poursuivre à travers plusieurs requêtes au modèle, l’historique doit pouvoir rétrécir sans perdre l’objectif, les clients ont besoin d’événements structurés et les actions à effet de bord doivent respecter à la fois les permissions et la politique d’approbation.
État du runtime et boucle d’exécution
Codex App Server représente l’état sous la forme Thread → Turn → Item. Un Thread est une conversation durable, un Turn correspond à une tâche utilisateur et les Items enregistrent messages, raisonnement, commandes, modifications de fichiers et résultats d’outils. Les Items servent de contexte aux Turns suivants : le harness conserve une trace d’exécution, pas seulement du texte de dialogue.
L’implémentation actuelle d’un Turn capture son contexte et peut le compacter avant le prochain appel au modèle lorsque la fenêtre approche de sa limite. La session du modèle est aussi réutilisée pendant les reprises du même Turn afin de conserver l’état de connexion et de routage.
La compaction est une transition d’état
Le code de compaction ne supprime pas simplement les anciens messages. Il produit d’abord un résumé avec le modèle, puis remplace l’historique par ce résumé, les messages utilisateur nécessaires et le contexte initial réinjecté. Le point d’insertion de ce contexte dépend du moment où la compaction se produit, avant un Turn ou pendant son exécution.
Cette différence affecte la fiabilité des tâches longues. L’intention, le répertoire de travail, les permissions et le travail inachevé doivent survivre à la compaction. Sinon, l’historique raccourcit mais l’agent oublie où il se trouve, ce qu’il peut faire ou quelles étapes sont terminées. Il faut donc tester la compaction comme une transition d’état avec des invariants, pas comme un simple nettoyage de tokens.
Trois niveaux d’intégration
| Interface | Usage adapté | Responsabilités de l’application |
|---|---|---|
codex exec | CI, scripts et tâches non interactives bornées | préparer l’entrée et consommer le résultat final |
| Codex SDK | démarrer, reprendre ou suivre un agent depuis du code | cycle de vie du processus CLI, identifiants de Thread, événements et versions |
| App Server | éditeurs, applications de bureau et ateliers internes | conversations persistantes, flux d’événements, UI d’approbation et compatibilité du protocole |
Le SDK TypeScript lance actuellement le CLI codex et échange des événements JSONL sur stdin/stdout. App Server expose les protocoles Thread, Turn, Item, d’approbation et de compaction ; il peut aussi générer des types TypeScript et un JSON Schema correspondant à la version de Codex en cours d’exécution. Ils reposent sur les mêmes principes, sans constituer la même abstraction cliente. Le choix dépend du cycle de vie et du niveau d’interaction que le produit doit maîtriser.
Sandbox et approbation forment deux limites distinctes
La documentation de sécurité de Codex sépare la sandbox de la politique d’approbation. La première détermine les fichiers et ressources réseau qu’une commande peut techniquement atteindre ; la seconde décide quand Codex doit s’arrêter et demander. Par défaut, le réseau est désactivé et les écritures sont limitées à l’espace de travail ; l’accès réseau et les écritures externes demandent une approbation.
Désactiver les approbations ne supprime pas automatiquement la sandbox, tandis que des fenêtres de confirmation sans isolation par le système d’exploitation ne créent pas une limite fiable. danger-full-access supprime les restrictions de la sandbox sur le système de fichiers et le réseau, mais la politique d’approbation reste configurable séparément ; --dangerously-bypass-approvals-and-sandbox contourne les deux contrôles. Même dans un conteneur, ces configurations très permissives peuvent permettre à un projet malveillant de lire les identifiants et les données disponibles.
La liste des composants open source de Codex comprend notamment le CLI, le SDK et App Server, mais l’extension IDE et Codex Cloud ne sont pas open source. Un harness ouvert rend le comportement du runtime et ses protocoles inspectables et adaptables ; il n’ouvre ni le modèle, ni les services hébergés, ni l’ensemble du produit.
Codex montre que la difficulté d’un harness de production ne réside pas dans la boucle elle-même, mais dans la continuité de l’état, la compatibilité des protocoles, les limites de sécurité et la reprise autour de cette boucle. Voir Harness de code IA, Boucles d’agent, Ingénierie du contexte et Contrats d’outils pour le modèle général.