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
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.
Ajout du 1er octobre 2026. Au-delà de l’intégration locale, OpenAI a lancé le 10 septembre l’Agents API en bêta publique : OpenAI y exécute le harness Codex en mode géré, dans un bac à sable hébergé par OpenAI, dans un environnement autohébergé ou chez un partenaire. La compaction automatique, la recherche d’outils qui charge les définitions à la demande et les sous-agents exécutés en parallèle avec des contextes séparés sont pris en charge côté serveur ; le DevDay du 29 septembre y a ajouté le computer use. C’est en pratique un quatrième niveau d’intégration : l’application confie à OpenAI l’exploitation du harness et une partie de l’état de session, tandis que la maîtrise de l’environnement d’exécution dépend du choix entre bac à sable hébergé et environnement autohébergé.
Côté local, le SDK Python est disponible en version stable. Il pilote l’App Server local via JSON-RPC et dépend d’une version fixée du runtime Codex CLI. L’App Server peut, outre stdio par défaut, écouter en WebSocket ou sur un socket Unix pour qu’une interface terminal distante s’y connecte ; la commande app-server et le transport WebSocket restent toutefois expérimentaux et ne sont pas pris en charge pour la production.
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.