Codex est une boucle : il édite des fichiers, exécute des commandes, lit la sortie et décide de la prochaine étape. Alors pourquoi vos tests d'API ne sont-ils pas dans cette boucle ? Ils sont dans Apidog, derrière une interface graphique, et ne s'exécutent que lorsque quelqu'un se souvient de cliquer. Votre agent ne les touche jamais.
La solution tient en un bloc de configuration. L'interface de ligne de commande (CLI) d'Apidog est un package npm, apidog-cli, qui exécute les scénarios de test que vous avez créés dans Apidog directement depuis un terminal. Une fois la CLI installée et Codex informé de son existence, votre agent exécute un scénario Apidog de la même manière qu'il exécute vos tests unitaires : lancez la commande, lisez le code de sortie, corrigez le code s'il est en rouge.
Ce guide couvre la partie spécifique à Codex que le guide d'installation générique ignore : la ligne exacte pour votre AGENTS.md, l'invite à donner à Codex, comment il exécute apidog run au sein de sa propre boucle, et comment lire le résultat.
Si vous n'avez pas encore installé la CLI, faites-le d'abord. Comment installer la CLI Apidog avec un agent de codage IA explique l'installation npm, le jeton d'accès et la première exécution, avec Codex qui tape. Cet article suppose que apidog --version affiche un numéro et que votre compte Apidog est authentifié.
De quel Codex s'agit-il ?
Il s'agit à la fois de l'interface de ligne de commande (CLI) OpenAI Codex et de l'application Codex. Il s'exécute localement, lit votre dépôt, modifie des fichiers et exécute des commandes shell dans un environnement sandbox, demandant approbation en fonction de votre mode de permission. Il ne s'agit pas de l'ancienne API de complétion de code Codex. Si vous exécutez codex et obtenez une interface plein écran affichant les différences et la sortie des commandes, vous êtes au bon endroit. Le guide de l'interface de ligne de commande OpenAI Codex couvre les bases.
La distinction est importante car Codex a sa propre façon d'apprendre les règles du projet, et ce mécanisme transforme un « exécuter mes tests » ponctuel en quelque chose que Codex utilise de lui-même. Ce mécanisme est AGENTS.md.
Le mécanisme : AGENTS.md, pas un simple rappel de chat
Codex lit les fichiers AGENTS.md avant de commencer à travailler. Pensez-y comme à CLAUDE.md pour Claude Code : un simple fichier Markdown d'instructions de projet que Codex charge en contexte au début de chaque session. Il construit l'ensemble d'instructions en parcourant votre racine Git jusqu'à votre répertoire actuel, en concaténant chaque AGENTS.md en commençant par la racine, de sorte que les fichiers les plus proches l'emportent en cas de conflits. Il existe également un fichier global ~/.codex/AGENTS.md. Pour notre objectif, un seul fichier à la racine du dépôt est suffisant.
C'est pourquoi vous écrivez la CLI dans AGENTS.md au lieu de la mentionner dans le chat. Un ID de scénario tapé dans le chat disparaît à la fin de la session. Un ID dans AGENTS.md est là pour chaque coéquipier et chaque exécution de Codex à partir de maintenant.
Étape 1 : Donnez l'invite à Codex et observez son exécution
Une fois le bloc en place, démarrez Codex dans votre dépôt :
Codex charge AGENTS.md au démarrage, il connaît donc déjà l'existence de la CLI. Apportez une modification qui affecte votre API, ou demandez-lui d'exécuter la vérification :
Codex émet la commande apidog run à partir de votre AGENTS.md. Dans son mode Auto par défaut, il peut lire des fichiers, les modifier et exécuter des commandes à l'intérieur du répertoire de travail de manière autonome, de sorte qu'un simple apidog run s'exécute généralement sans invite. Le rapporteur -r cli affiche un résultat étape par étape et un résumé directement dans le terminal, où vous observez chaque requête et assertion au fur et à mesure de leur déroulement.
Vous voulez voir l'exécution se dérouler et Codex rapporter à la fois le résumé et le code de sortie. Si votre mode de permission est Lecture seule, Codex s'interrompt et demande avant d'exécuter ; approuvez-le, ou changez le mode avec /permissions dans la session. Le mode Auto est le défaut sensé, car un scénario de test en lecture seule contre l'environnement de staging est exactement le genre de commande sûre et dans l'espace de travail pour lequel ce mode est conçu.
Étape 2 : Les tests de Codex au sein de sa propre boucle
L'essentiel est ce qui se passe lorsque vous arrêtez de demander et que Codex exécute le scénario de lui-même parce que AGENTS.md lui a dit de le faire.
Imaginez Codex modifiant un gestionnaire qui construit une réponse de paiement. Sa boucle change : il édite le code, puis, au lieu de crier victoire, il exécute votre scénario Apidog contre l'environnement de staging, lit le code de sortie et agit en conséquence. Vert, il passe à autre chose. Rouge, il ouvre le rapport, lit quelle assertion a échoué (le code de statut, le champ manquant, la mauvaise valeur), tente une correction et réexécute. Le test d'API devient partie intégrante de la même boucle d'édition-test-correction que Codex utilise déjà pour vos tests unitaires. Vous avez écrit une seule instruction et Codex a intégré la commande à son fonctionnement existant.
C'est le modèle déléguer-puis-vérifier qui sécurise tout flux de travail d'agent. Codex exécute la commande et lit le résultat ; vous continuez à créer des scénarios visuellement dans Apidog et à vérifier que l'agent lit les codes de sortie honnêtement. Pour le modèle plus large, consultez comment utiliser les agents IA pour les tests d'API et le harnais de test IA Apidog.
Vérifiez que Codex exécute réellement la CLI
Les agents signalent des succès qu'ils n'ont pas mérités, et Codex ne fait pas exception. Trois vérifications, par ordre de fréquence à laquelle elles détectent des problèmes.
Premièrement, confirmez que la commande a bien été exécutée. L'interface Codex affiche les commandes qu'il a exécutées et leur sortie en ligne. Recherchez la ligne littérale apidog run ... et un résultat en dessous. Si Codex dit qu'il a exécuté les tests mais que vous ne voyez pas la commande, il a résumé quelque chose qu'il n'a jamais fait. Demandez-lui de l'exécuter à nouveau et d'afficher la sortie brute.
Deuxièmement, confirmez le code de sortie, celui qui compte :
Quel était le code de sortie de cette commande apidog run ?
apidog run renvoie 0 lorsque toutes les assertions passent et un nombre non nul lorsque quelque chose échoue. Ce comportement unique permet à Codex, ou à un pipeline, de traiter l'exécution comme un portail propre. Lorsque le texte de Codex dit « tests réussis » mais que le code de sortie est non nul, le code de sortie a raison.
Troisièmement, confirmez qu'il a utilisé le scénario réel. Si une exécution échoue avec « scénario introuvable », Codex a peut-être inventé ou mal mémorisé un ID. Vérifiez à nouveau les valeurs -t et -e par rapport à AGENTS.md et à la commande générée par Apidog dans l'onglet CI/CD. Les ID dans AGENTS.md sont la vérité.
Lecture du rapport de test
Lorsqu'une exécution devient rouge, le rapport contient la réponse. Avec -r cli, Codex obtient une ventilation lisible dans le terminal : chaque requête, chaque assertion, et celle qui a échoué avec la valeur attendue par rapport à la valeur réelle. L'assertion échouée nomme le champ exact ou le code de statut, ce qui est généralement suffisant pour que Codex trouve la correction.
Pour un rapport que vous pouvez ouvrir dans un navigateur ou remettre à un coéquipier, ajoutez le rapporteur HTML
Le rapporteur html écrit un fichier autonome dans ./apidog-reports. Gardez cli dans la liste afin que Codex reçoive toujours la sortie en ligne qu'il lit pour décider de sa prochaine étape. Pour chaque drapeau et rapporteur, y compris le format JUnit analysé par les tableaux de bord CI, consultez le guide complet de la CLI Apidog et la référence de la commande apidog run.
Deux façons d'aller plus loin que les commandes shell
L'exécution de apidog run à partir de AGENTS.md couvre la plupart de vos besoins. Deux voies vont plus loin.
La première est MCP. Codex prend en charge le protocole de contexte de modèle (Model Context Protocol), et vous ajoutez des serveurs avec codex mcp add ou en éditant ~/.codex/config.toml avec un bloc [mcp_servers.NAME]. Le serveur MCP Apidog expose vos spécifications API via MCP, afin que Codex puisse lire votre schéma pendant qu'il écrit du code, et non pas seulement après coup. La CLI exécute les tests ; MCP fournit la spécification à l'agent.
La seconde est codex exec. Là où un simple codex ouvre l'interface interactive, codex exec "..." exécute Codex de manière non interactive et redirige le résultat vers la sortie standard, ce que vous utilisez dans les scripts et les CI. Pour exécuter apidog run dans un pipeline sans que Codex soit présent, Apidog CLI dans GitHub Actions couvre les secrets, les rapporteurs et le contrôle du code de sortie.
Quand Codex se trompe
Quelques échecs apparaissent souvent lors de la configuration.
Il ignore le bloc AGENTS.md. Si Codex exécute une commande générique ou aucune du tout, le bloc peut ne pas se charger. Confirmez que le fichier est nommé exactement AGENTS.md et qu'il se trouve à la racine de votre dépôt Git ou dans un répertoire parent de votre répertoire actuel. Une faute de frappe dans le nom du fichier signifie que Codex ne le lira jamais ; redémarrer la session force une nouvelle lecture.
Il transmet quand même un jeton d'accès. Si Codex essaie d'ajouter --access-token, c'est qu'il se base sur des exemples publics. Le bloc lui dit déjà de ne pas le faire, puisque la machine est authentifiée via apidog login. Renforcez la ligne, et ne mettez jamais un vrai jeton dans AGENTS.md.
Il invente un drapeau. Une erreur « option inconnue » signifie que Codex a deviné un drapeau que votre version n'a pas. Dites-lui d'exécuter apidog run --help et de copier le drapeau exact à partir de là, ce qui est toujours correct pour votre version installée.
Il signale un succès pour une exécution échouée. C'est le plus coûteux, et la raison pour laquelle la règle du code de sortie est dans votre AGENTS.md et votre étape de vérification. Lorsque le résumé et le code de sortie ne sont pas d'accord, le code de sortie l'emporte.
D'un agent quotidien à une boucle testée
Voilà la configuration. Installez apidog-cli une fois en suivant le guide d'installation, ajoutez un court bloc Apidog au AGENTS.md de votre dépôt, et Codex saura comment exécuter vos tests d'API et lire le résultat au sein de la même boucle qu'il utilise déjà pour éditer du code. Un point de terminaison cassé est détecté pendant que Codex travaille encore sur la modification, et non après son déploiement.
Un test derrière une interface graphique s'exécute quand un humain clique ; une commande d'une seule ligne s'exécute chaque fois que Codex le décide. Vous continuez à construire des scénarios visuellement dans Apidog, et votre agent les exécute là où vous ne regardez pas. Téléchargez Apidog, construisez un scénario, insérez sa commande apidog run dans AGENTS.md, et regardez Codex la prendre en compte à la prochaine modification.