DEV Community

Cover image for Commande /goal : Automatisation Codex et Claude en Agents Autonomes 24/7
Antoine Laurent
Antoine Laurent

Posted on • Originally published at apidog.com

Commande /goal : Automatisation Codex et Claude en Agents Autonomes 24/7

Chaque grand laboratoire d'IA a livré la même primitive au cours des six dernières semaines. Anthropic a ajouté /goal à Claude Code. OpenAI l'a intégré dans Codex CLI et l'application de bureau Codex. Nous Research l'a câblé dans Hermes. La dénomination est cohérente à dessein : l'industrie converge vers une interface partagée pour une seule chose — un agent qui travaille en boucle fermée jusqu'à atteindre un état final mesurable, sans vous demander une autorisation à chaque étape.

Essayez Apidog aujourd’hui

Si vous avez déjà fait la boucle manuelle « approuver, relancer l'invite, dire à l'agent de continuer, répéter », /goal est la commande slash qui la remplace. Vous donnez une cible à l'agent, il travaille vers cette cible, puis il revient quand la cible est atteinte.

Ce guide s'adresse aux développeurs et aux créateurs d'API. Nous allons voir ce que /goal fait réellement en coulisses, comment le configurer dans Codex et Claude Code, quelle structure d'invite évite les boucles infinies, et comment l'intégrer dans un workflow API avec Apidog.

Téléchargez Apidog gratuitement si vous souhaitez suivre les exemples d'API plus loin dans ce guide.

Ce que /goal fait réellement

En une phrase : /goal permet à un agent IA de boucler sur une tâche jusqu'à ce qu'une condition d'arrêt se déclenche, sans vous demander d'approbation à chaque aller-retour.

Le mécanisme est simple :

  1. Vous définissez un objectif.
  2. L'agent principal planifie et exécute une étape.
  3. Un modèle de validation plus petit vérifie si l'objectif est atteint.
  4. Si non, l'agent continue.
  5. Si oui, la boucle se ferme et l'agent rend compte du résultat.

C'est le même schéma que la « boucle Ralph » popularisée début 2026, mais intégré comme commande de première classe dans les outils officiels.

Différence avec un agent classique :

  • Sans /goal : vous êtes la boucle. Vous lisez la sortie, décidez si elle est correcte, lancez l'étape suivante, approuvez les appels d'outils, puis recommencez.
  • Avec /goal : l'agent gère la boucle. Il planifie, exécute, s'auto-valide, puis revient lorsqu'il a terminé, atteint une contrainte ou épuisé son budget.

Exemple :

/goal create a landing page
Enter fullscreen mode Exit fullscreen mode

Dans Claude Code, cela peut déclencher la recherche, l'échafaudage, le style, le débogage et une prévisualisation finale dans une seule exécution continue.

Pourquoi c'est soudainement partout

Les tâches d'agent à long terme échouaient souvent pour deux raisons :

  1. Dérive : sans validateur vérifiant le résultat par rapport à l'objectif initial, les modèles s'éloignaient et produisaient des résultats incorrects mais confiants.
  2. Surveillance constante : même quand le modèle pouvait faire le travail, l'utilisateur devait superviser chaque itération.

Un second modèle de validation corrige ces deux problèmes. Il est peu coûteux, car plus petit et ciblé, et il donne à la boucle une condition d'arrêt stricte.

Configurer /goal dans Codex

La CLI Codex donne le plus de contrôle.

1. Activer les objectifs

Dans l'application de bureau Codex :

Settings → Configuration → goals = true
Enter fullscreen mode Exit fullscreen mode

La CLI hérite ensuite de ce paramètre.

2. Lancer la CLI en mode automatique 

codex --approval-mode full-auto
Enter fullscreen mode Exit fullscreen mode

Ce mode réduit les interruptions liées aux demandes d'approbation.

3. Définir un objectif 

/goal [votre objectif ici]
Enter fullscreen mode Exit fullscreen mode

Codex confirme que l'objectif est enregistré, puis commence l'exécution.

Capture Codex /goal

Si vous n'êtes pas à l'aise avec la CLI, commencez dans l'application de bureau Codex. La fonctionnalité est la même, mais l'interface permet de mettre en pause, d'effacer un objectif et de surveiller l'utilisation des jetons.

Configurer /goal dans Claude Code

Claude Code fonctionne de manière similaire :

/goal [description de la tâche]
Enter fullscreen mode Exit fullscreen mode

La documentation officielle est disponible sur le site de documentation de Claude Code.

Capture Claude Code /goal

Si vous rencontrez des erreurs de configuration ou d'installation, la solution pour la configuration d'entreprise custom3p invalide couvre le mode de défaillance le plus courant.

Pour piloter Claude Code avec des workflows multi-agents et /goal, consultez aussi notre analyse de Ruflo, une couche multi-agents au-dessus de Claude Code.

Conseil pratique : dans Claude Code, /goal affiche le nombre de jetons en direct et une barre de progression. Surveillez les jetons, pas seulement la sortie. Si l'objectif consomme des jetons sans progression visible, le validateur ne converge probablement pas. Dans ce cas :

/pause
Enter fullscreen mode Exit fullscreen mode

ou :

/goal clear
Enter fullscreen mode Exit fullscreen mode

La structure d'invite qui fonctionne réellement

La syntaxe de /goal est simple. Le vrai problème est d'écrire un objectif que le validateur peut mesurer.

Une bonne invite /goal contient trois éléments :

  1. Le travail : ce que l'agent doit faire.
  2. L'état final mesurable : comment savoir que c'est terminé.
  3. Les contraintes : ce qui ne doit pas être modifié ou violé.

Squelette recommandé :

/goal [faire le travail] until [état final mesurable] without [contraintes à respecter]
Enter fullscreen mode Exit fullscreen mode

Exemple pour une tâche de code :

/goal fix every failing test until npm test exits 0 without modifying any file outside the /auth directory
Enter fullscreen mode Exit fullscreen mode

Pourquoi cet objectif fonctionne :

  • npm test exits 0 est vérifiable.
  • /auth directory définit une limite claire.
  • Le validateur peut exécuter la commande et vérifier les fichiers modifiés.

À l'inverse, un objectif comme :

/goal make this UI look modern
Enter fullscreen mode Exit fullscreen mode

fonctionne mal, car « moderne » n'est pas mesurable.

Réécrivez plutôt :

/goal improve the UI until Lighthouse accessibility score is 90+ without changing the existing route structure
Enter fullscreen mode Exit fullscreen mode

Structure avancée pour les tâches plus longues

Pour des objectifs plus complexes, utilisez un format en blocs :

/goal
Objective: [objectif en une ligne]

Success criteria:
  - [critère mesurable 1]
  - [critère mesurable 2]

Constraints:
  - [limite 1]
  - [limite 2]

Context:
  - [fichiers, dépôts, clés API ou détails utiles]
Enter fullscreen mode Exit fullscreen mode

Exemple :

/goal
Objective: implement password reset for the auth service

Success criteria:
  - npm test exits 0
  - POST /auth/reset-password returns 200 for a valid token
  - expired tokens return 401
  - OpenAPI documentation is updated

Constraints:
  - do not modify files outside /auth and /docs
  - do not change the existing login endpoint contract

Context:
  - API contract is in openapi.yaml
  - tests are in /auth/__tests__
Enter fullscreen mode Exit fullscreen mode

Ce format donne au validateur des éléments concrets à vérifier. Sans critères de succès, il se rabat sur une correspondance sémantique floue, ce qui augmente le risque de dérive.

Exemples à reprendre

/goal n'est pas limité au code. Il fonctionne bien dès qu'un état final peut être vérifié.

Recherche 

/goal collect every public benchmark for Claude Opus 4.7 published since April 2026, save sources, and produce a markdown table sorted by date until the table covers at least 10 distinct benchmarks
Enter fullscreen mode Exit fullscreen mode

Maintenance de dépôt 

/goal find dead code, unused dependencies, and stale files in this repo, then propose a PR description listing safe removals until every item has a justification
Enter fullscreen mode Exit fullscreen mode

Documentation 

/goal rewrite README.md so a new contributor can install, run, test, and understand the project until each of those four steps has a working command and an expected output
Enter fullscreen mode Exit fullscreen mode

Développement de fonctionnalité 

/goal add a dark/light theme toggle, persist the choice in localStorage, update styles for both themes, and verify in the browser until the toggle works without a page reload and survives a refresh
Enter fullscreen mode Exit fullscreen mode

Le point commun : chaque exemple définit un état final vérifiable. C'est ce qui distingue un objectif qui se termine d'un objectif qui tourne en rond.

Associer /goal aux workflows de développement API

Les API sont un cas d'usage naturel pour /goal, car l'état final est souvent testable :

  • la requête retourne 200,
  • le schéma de réponse correspond,
  • les erreurs attendues sont couvertes,
  • le contrat est documenté.

Un workflow concret :

  1. Concevoir le contrat dans Apidog

    Définissez l'endpoint, le schéma de requête, le schéma de réponse et les exemples de payload dans Apidog.

  2. Exporter la spécification

    Exportez la spécification OpenAPI 3.x et fournissez-la à Codex ou Claude Code comme contexte.

  3. Lancer /goal

    Demandez à l'agent d'implémenter l'endpoint jusqu'à ce que les tests passent.

  4. Faire vérifier par le validateur

    À chaque itération, le validateur exécute les tests contre le service en cours d'exécution. L'agent ne s'arrête que lorsque tous les cas sont au vert.

Exemple d'objectif :

/goal implement POST /users according to openapi.yaml until all Apidog test cases pass without changing any existing endpoint contract
Enter fullscreen mode Exit fullscreen mode

Ce workflow est plus robuste que de laisser l'agent inventer ses propres tests. Le contrat API est déjà verrouillé, et l'agent doit converger vers ce contrat.

Si vous découvrez Apidog, la plateforme combine conception d'API, mocking, tests et documentation. C'est utile avec /goal, car le validateur fonctionne mieux lorsqu'il dispose d'une seule commande ou suite de tests pour vérifier l'état final.

Pour aller plus loin :

Si vous travaillez avec des serveurs MCP, le même schéma s'applique. Consultez le test de serveur MCP avec Apidog pour configurer des tests sûrs contre un serveur MCP local.

Conseils de production pour /goal

Quelques pratiques utiles après des essais en conditions réelles :

  • Un objectif à la fois

    Codex et Claude Code limitent l'exécution à un objectif actif. Utilisez /goal clear entre deux exécutions.

  • Commencez par /plan

    Un bon workflow consiste à demander un plan, le relire, puis lancer /goal avec ce plan comme contexte.

  /plan propose the implementation steps for password reset
Enter fullscreen mode Exit fullscreen mode

Puis :

  /goal implement the approved plan until npm test exits 0 without modifying files outside /auth
Enter fullscreen mode Exit fullscreen mode
  • Utilisez un fichier de progression Demandez à l'agent de maintenir un fichier progress.md. 
  /goal migrate the billing module until all tests pass and maintain progress.md with completed steps and blockers
Enter fullscreen mode Exit fullscreen mode

Vous obtenez un journal lisible et l'agent garde un contexte persistant.

  • Demandez au modèle de rédiger l'objectif

    Donnez-lui votre intention en langage naturel, puis demandez-lui de produire une invocation /goal avec critères de succès et contraintes.

  • Surveillez le validateur

    Si la boucle ne se ferme pas, les critères de succès sont probablement trop flous. Resserrez-les au lieu de relancer le même objectif.

  • Réservez /goal aux tâches longues

    Pour une correction d'une ligne, une invite normale est plus rapide. La boucle autonome a un coût.

Quand /goal vous décevra

Gardez ces limites en tête.

Coût

Une boucle qui tourne longtemps consomme plus de jetons qu'une session manuelle courte. Fixez un budget ou utilisez /pause.

Tâches sans signal clair

Le polissage UX, le ton d'un texte ou le goût visuel n'ont pas toujours de validateur fiable. L'agent peut abandonner ou inventer une condition d'arrêt faible.

Effets secondaires externes

Un objectif qui envoie des e-mails, déclenche des paiements ou appelle des API de production doit avoir des contraintes strictes.

Exemple à éviter :

/goal test the payment flow until it works
Enter fullscreen mode Exit fullscreen mode

Exemple plus sûr :

/goal test the payment flow against the sandbox provider until all sandbox test cases pass without calling production endpoints or sending real customer emails
Enter fullscreen mode Exit fullscreen mode

Si vous construisez encore le contrôle d'accès autour d'agents IA appelant vos API, l'article sur l'utilisation et la facturation de l'API GitHub Copilot pour les équipes montre comment les principaux fournisseurs abordent ce sujet.

Contexte obsolète

Les objectifs longs peuvent diverger si la base de code change pendant la boucle. Dans ce cas, mettez en pause, mettez à jour le contexte, puis relancez un objectif propre.

Ce que cela change dans votre façon de construire avec l'IA

/goal marque le passage de « l'IA comme autocomplétion » à « l'IA comme travailleur à briefer et surveiller ».

La commande est simple, mais le rôle du développeur change :

  • écrire des critères de succès mesurables,
  • définir des contraintes précises,
  • fournir des contrats testables,
  • surveiller les sorties et les coûts.

Les équipes qui en tirent le plus de valeur ont déjà :

  • des spécifications OpenAPI,
  • une CI fiable,
  • des tests automatisés,
  • des contrats API clairs.

Si votre API possède une spécification et une suite de tests, vous pouvez confier un endpoint à un agent /goal. Si l'API n'existe que dans la tête d'une personne, l'agent n'a rien de solide à valider.

C'est là que les plateformes API deviennent utiles pour les workflows IA. Apidog est conçu autour du développement API axé sur la conception. L'agent peut lire la spécification, implémenter le comportement attendu, puis vérifier son travail contre les cas de test. Téléchargez Apidog si vous souhaitez mettre en place ce workflow contract-first.

FAQ

Est-ce que /goal fonctionne dans l'application web Codex ?

Oui. Il fonctionne dans Codex CLI, Codex desktop, l'application Codex et Claude Code CLI. Hermes prend également en charge la même commande. La parité entre fournisseurs est l'objectif.

En quoi /goal est-il différent d'une invite normale ?

Une invite normale s'exécute une fois et s'arrête. /goal fonctionne en boucle fermée avec un modèle de validation qui vérifie la condition d'arrêt après chaque étape. L'agent décide quand s'arrêter.

L'agent peut-il contourner les contraintes ?

Le validateur applique les contraintes à chaque itération, mais la précision de vos contraintes compte. Une contrainte comme :

without modifying any file outside /auth
Enter fullscreen mode Exit fullscreen mode

est vérifiable.

Une contrainte comme :

without breaking anything
Enter fullscreen mode Exit fullscreen mode

ne l'est pas.

Est-ce que /goal coûte plus cher qu'une session Claude ou Codex normale ?

Oui. Le validateur utilise un modèle plus petit, mais le modèle principal continue de travailler en autonomie. Attendez-vous à consommer plus de jetons. Utilisez un budget ou /pause.

Et si je veux tester la sortie de l'agent contre une vraie API ?

Utilisez un outil comme Apidog pour verrouiller le contrat API et exécuter des cas de test réels contre l'implémentation. Le validateur peut appeler la suite de tests et disposer d'un état final mesurable.

Consultez aussi le guide de l'API Claude gratuite si vous démarrez un service basé sur Claude avec un budget limité.

Top comments (0)