La plupart des utilisateurs connaissent Codex à travers l’App, l’interface en ligne de commande ou l’extension pour IDE. Ces interfaces jouent un rôle important, mais le système sur lequel elles reposent se prête à bien d’autres usages.
Le harnais open source de Codex fait fonctionner toutes ces interfaces. Il aide les modèles à recueillir des éléments de contexte, à raisonner pour mener à bien une tâche, à utiliser des outils, à respecter les limites configurées, à demander une approbation et à poursuivre le travail engagé.
Cela ouvre de nouvelles possibilités aux développeurs. Au lieu de demander à chaque équipe de transférer son travail dans un assistant de programmation généraliste, vous pouvez intégrer l’agent à un logiciel conçu pour le travail à accomplir : un workflow d’ingénierie, un tableau de bord opérationnel, une enquête de sécurité, une console d’assistance client ou une application interne destinée à une équipe spécialisée.
La boucle de l’agent est réutilisable
Un prompt et une réponse du modèle ne suffisent pas à faire un agent efficace. L’agent doit pouvoir comprendre une tâche, conserver le contexte dans la durée, examiner les informations pertinentes, appeler des outils, rendre compte de sa progression, gérer les échecs, demander une approbation humaine si nécessaire et fournir un résultat utile.
Le harnais est le système d’exécution qui permet tout cela.
La conception du harnais peut influer sensiblement sur les résultats. Sur ARC-AGI-3, la conservation du raisonnement et le compactage du contexte ont fait passer le score de GPT-5.6 Sol de 13,3 % à 38,3 %, tout en divisant par six le nombre de tokens de sortie.
Nous avons conçu le harnais de Codex pour gérer l’état des conversations, diffuser le déroulement de l’exécution en continu, utiliser des outils, appliquer les règles configurées pour le bac à sable et les approbations, et poursuivre le travail d’un tour de conversation à l’autre. Avec Codex app-server, nous rendons ces fonctionnalités accessibles via un protocole client documenté. Les applications peuvent créer des fils de discussion, lancer des tours de conversation, recevoir des événements et traiter les demandes d’approbation.
Si vous développez un logiciel qui a besoin d’un agent, vous pouvez partir de Codex au lieu de créer un nouvel environnement d’exécution, puis décider de ce que l’application prendra en charge.
Un harnais ouvert que les développeurs peuvent examiner et adapter
Le harnais étant open source, vous pouvez examiner la couche qui relie votre application au modèle, comprendre son fonctionnement et adapter l’intégration à votre produit.
Vous gardez ainsi la main sur les éléments qui permettent d’adapter l’agent à votre produit :
-
L’interface. Une équipe peut conserver ses tableaux de bord, ses éditeurs, ses files d’attente, ses cartes, ses enregistrements et ses circuits d’approbation, sans imposer une fenêtre de discussion générique pour chaque interaction.
-
Le contexte et les outils. Une application peut donner à l’agent accès aux systèmes, aux documents, aux données et aux actions utiles à un workflow précis, y compris à ses propres services MCP.
-
Les limites d’intervention. L’application hôte peut déterminer où s’exécute l’agent, à quels fichiers et outils il a accès, quelles actions nécessitent une approbation, comment suivre le travail et comment transmettre les résultats au système de référence.
Nous publions Codex CLI, app-server et le SDK officiel de Codex en open source. Notre guide des composants open source recense les composants disponibles et indique où les trouver.
La couche open source comprend le harnais et les interfaces d’intégration. L’accès aux modèles et les services gérés sont distincts de cette couche.
Choisissez la couche d’intégration adaptée
Le choix de l’intégration Codex dépend de votre cas d’usage.
-
Pour un script, une tâche de CI ou une tâche ponctuelle en arrière-plan, codex exec peut exécuter un workflow d’agent au périmètre défini et renvoyer une sortie structurée.
-
Si votre code doit lancer ou reprendre des tâches Codex, ou en suivre l’exécution en continu, le SDK officiel de Codex fournit une interface de programmation directe.
Vous trouverez un exemple exécutable dans la documentation du SDK de Codex.
Utilisez Codex app-server lorsque l’agent fait partie intégrante du produit. Votre application peut alors se connecter à un processus Codex local, garder des conversations ouvertes, diffuser des événements en continu, interrompre le travail, mettre des outils à disposition et répondre aux demandes d’approbation. Le SDK simplifie les workflows courants pilotés par le code. Avec app-server, les équipes produit contrôlent directement le cycle de vie de l’agent et l’expérience utilisateur.
Concevez le logiciel autour du workflow
Plutôt que de reproduire Codex App avec un autre logo, il est plus intéressant de concevoir un logiciel qui reflète la façon dont une personne ou une équipe travaille déjà.
Un analyste en sécurité peut avoir besoin d’une file d’enquêtes à traiter, des alertes récentes, de la liste des services touchés et d’une étape d’approbation avant d’ouvrir un ticket pour corriger le problème. Un ingénieur du support peut avoir besoin de l’historique du compte, des journaux du produit, de la documentation interne et d’un brouillon de réponse. Une équipe produit peut souhaiter utiliser un tableau de tâches où le passage d’un ticket à l’état « prêt » déclenche un workflow de mise en œuvre au périmètre défini.
Dans chaque exemple, l’interface joue un rôle important. Elle indique à l’agent ce que l’utilisateur consulte, lui donne accès aux outils adaptés et permet à l’utilisateur d’examiner les étapes suivantes.

Figure 1. Votre application gère le contexte du produit, les règles métier et les outils. Codex app-server assure la boucle de l’agent et l’exécution en bac à sable.
Exemple : Relay
Nous avons créé Relay pour illustrer le fonctionnement d’une application de gestion des opérations fondée sur Codex app-server. Relay intègre un agent à côté d’un tableau de bord de suivi d’expéditions fictives, lui donne accès à ses propres outils MCP et exige une approbation humaine avant toute nouvelle réservation de transport.
L’utilisateur commence par sélectionner une expédition et cliquer sur une action comme Comparer les solutions de rattrapage, sans avoir à rédiger un prompt de toutes pièces. L’application fournit le contexte pertinent, Codex récupère les dernières données opérationnelles de démonstration et l’agent explique les options disponibles. Toute opération d’écriture ayant des conséquences importantes nécessite une approbation.
Codex peut ainsi utiliser les outils MCP de l’application pour récupérer des données à jour avant de recommander une action ou, une fois l’approbation obtenue, de l’exécuter. Lorsqu’un outil modifie un enregistrement, l’application actualise la vue métier correspondante. Le harnais gère la boucle de l’agent, l’état de la conversation, la diffusion de l’activité en continu et les interactions avec les outils. Le produit garde la maîtrise de son tableau de bord, de ses enregistrements et de ses commandes.
Relay utilise un jeu de données fictives préchargé, mais ce mode d’intégration se prête à d’autres usages. Il pourrait servir à gérer des incidents, à effectuer des opérations sur des comptes, à mener des travaux de recherche ou à développer d’autres applications dans lesquelles un agent doit intervenir au sein d’un produit existant.

Figure 2. Relay intègre Codex à un tableau de bord de suivi des expéditions. L’application fournit ses propres outils MCP et exige une approbation humaine pour les actions ayant des conséquences importantes.
Ce que développent les équipes
Plusieurs réalisations publiques illustrent déjà ce mode d’intégration :
-
GitHub et JetBrains intègrent Codex aux workflows existants dans les IDE.
-
Cisco utilise le SDK de Codex dans App Builder, au sein de Cisco Cloud Control.
-
Thrive Holdings et Crete utilisent Codex dans un workflow de préparation des déclarations fiscales qui tient compte des retours des fiscalistes. Leur projet pilote a permis de traiter 7 000 déclarations et de réduire d’environ un tiers le temps de préparation.
Ce mode d’intégration s’étend au-delà de l’ingénierie. Il convient aussi aux équipes d’assistance qui analysent les problèmes de leurs clients, aux équipes opérationnelles qui coordonnent des workflows, aux équipes de sécurité qui évaluent la priorité des incidents, aux équipes commerciales qui se renseignent sur leurs comptes clients et aux équipes marketing qui élaborent des campagnes. Dans chaque cas, l’application fournit le contexte et les outils et gère les approbations, tandis que Codex assure la boucle de l’agent.
Explorez d’autres usages
Dans de nombreux métiers, le contexte indispensable au travail se trouve dans un tableau de bord, une chronologie, une carte, un document ou un enregistrement du système. Ces vues ont une fonction qui va bien au-delà de la présentation : les utilisateurs s’y appuient pour comprendre ce qui se passe, prendre des décisions et garder la main.
Plutôt que de remplacer ces interfaces par une fenêtre de discussion universelle, on peut enrichir leurs fonctionnalités en y intégrant un agent capable de comprendre le travail à accomplir, d’examiner les éléments de contexte pertinents, de proposer la prochaine étape et d’exécuter une action approuvée.
Codex App, la CLI et l’extension pour IDE montrent ce que permet le harnais. En publiant son code source, nous donnons aux développeurs les moyens d’examiner le fonctionnement de ces capacités, de les intégrer à leurs produits et de les adapter à leurs workflows.
Pour développer avec le harnais de Codex, commencez par le dépôt open source de Codex, puis choisissez l’intégration adaptée à votre produit : codex exec pour les tâches non interactives, le SDK de Codex pour piloter des workflows d’agent par le code, ou Codex app-server pour les applications qui doivent maintenir des conversations ouvertes, diffuser des événements en continu et gérer les approbations.