Un assistant de programmation peut poursuivre ses recherches sur un contrôle en échec, mais le contrôle et le code final demandent toujours votre examen. Ce guide vise un développeur responsable d’un dépôt où une commande de test, de compilation ou de vérification de style échoue déjà. Il utilise un Goal délimité dans Claude Code ou, comme option distincte, la CLI interactive de Codex. Choisissez une seule voie. Le travail est terminé lorsque la commande d’origine réussit sur une modification relue qui conserve le comportement défini à l’avance. Si cela ne peut être démontré, conservez l’échec et le blocage précis. La procédure repose sur la documentation : BIG CHANGE n’a exécuté aucun Goal ni réparé de dépôt pour cet article.

Le grand changement

  • Ce qui a changé : Les commandes documentées /goal maintiennent un objectif actif d’un tour à l’autre : l’assistant peut examiner un échec, effectuer une modification limitée et vérifier à nouveau sans nouvelle instruction après chaque tour.
  • Pourquoi cela compte : Vous pouvez définir la commande en échec, les fichiers autorisés et le comportement à préserver avant le début de la boucle. Les tentatives gardent ainsi le même critère d’acceptation.
  • À surveiller : Un statut Goal ou un verdict du modèle ne prouve pas la réparation. Lisez le résultat réel du contrôle et le diff final, puis décidez vous-même d’accepter la modification.

Avant de commencer : consigner l’échec et les limites

Utilisez un dépôt que vous avez le droit de modifier. Lisez ses consignes locales, notamment AGENTS.md ou CLAUDE.md si ces fichiers existent, et vérifiez la branche, les modifications présentes et les fichiers non suivis. Dans un dépôt Git, ces commandes donnent un inventaire initial :

Terminal
git status --short
git diff --stat
git diff

Conservez cet inventaire pour distinguer les modifications de l’assistant du travail déjà en cours. Exécutez le véritable contrôle en échec une fois, ou conservez une exécution récente fiable avec la commande exacte, l’erreur complète et le code de sortie. Ne le remplacez pas par une commande d’exemple de cet article. Notez avant de commencer toute dépendance à un service, un secret ou une plateforme inaccessible. Une modification unique connue peut être plus simple avec une demande ordinaire ; un Goal est utile quand chaque résultat détermine l’étape de diagnostic suivante.

Rédigez une courte note d’acceptation en dehors du Goal : commande d’origine exacte, résultat actuel, chemins et outils autorisés, comportements ou autres contrôles à conserver, et décisions nécessitant un arrêt pour examen. Protégez explicitement les modifications sans rapport. Ne laissez pas l’assistant supprimer ou affaiblir le contrôle pour obtenir artificiellement un succès. Relisez la note avant d’autoriser les outils. Demander un arrêt après un nombre de tours peut guider le modèle, mais ne garantit pas un plafond de dépenses.

1. Choisir une seule interface Goal

Pour Claude Code, ouvrez la session du dépôt voulu et vérifiez que /goal est disponible. Son manuel Goal, vérifié le 20 octobre 2026, indique que la commande dépend de la confiance accordée à l’espace de travail et des réglages des hooks. Un seul Goal peut être actif par session. Une nouvelle condition remplace l’ancienne et lance le travail immédiatement. Le Goal ne modifie pas le mode de permissions : le mode manuel peut encore demander une autorisation avant les outils ; le mode automatique est un réglage distinct. Conservez vos contrôles habituels sur fichiers, commandes et réseau.

Pour l’ autre option, la CLI interactive de Codex, vérifiez la version installée et la liste des commandes à barre oblique. Le guide pratique des Goals d’OpenAI indique leur arrivée dans Codex 0.128.0. Son guide d’utilisation documente un réglage features.goals si la commande manque. Ces vérifications se font dans votre installation ; elles n’ont pas été exécutées pour cet article :

Terminal
codex --version
codex features enable goals

Activez la fonction uniquement si votre installation le nécessite et si votre organisation l’autorise. Ces instructions Codex concernent la CLI interactive. Ne supposez pas le même support des commandes dans codex exec ou toutes les versions de l’application de bureau. Si la commande reste absente, arrêtez-vous et vérifiez version, réglage de fonction et accès du compte ou de l’espace de travail avant de choisir une autre méthode.

2. Définir la condition délimitée

Utilisez /goal suivi de la condition relue. Indiquez la vraie commande et les chemins permis ; ne collez pas un nom de test inventé. Par exemple : « Faites réussir mon contrôle déjà en échec en utilisant uniquement les chemins et outils de ma note d’acceptation. Après chaque tentative, montrez la commande, le résultat complet et les fichiers modifiés. Préservez les comportements protégés et les modifications sans rapport. Si le contrôle ne peut pas être exécuté ou qu’aucun changement sûr dans le périmètre ne reste possible, arrêtez-vous avec l’erreur exacte, les modifications tentées et les informations attendues de moi. » Remplacez « mon contrôle » par la commande exacte et joignez ou indiquez la note relue avant de commencer.

Les deux commandes documentées /goal acceptent une condition non vide allant jusqu’à 4 000 caractères. Gardez les contraintes détaillées dans la note plutôt que de les comprimer dans cette limite. Dans Claude Code, /goal <condition> lance immédiatement un tour. Dans la CLI interactive de Codex, /goal <objective> attache un objectif persistant à la conversation. Aucune voie n’accorde de nouvelle autorité sur les fichiers, commandes ou comptes. Si la réparation demande des chemins plus larges, un service externe, un secret, une fusion ou un déploiement, suspendez-la pour une décision du responsable.

3. Suivre les preuves pendant le travail

Demandez le résultat exact de la commande après chaque tentative significative et la liste des fichiers modifiés. Exécutez /goal sans argument pour consulter l’état. Claude Code affiche le temps écoulé, les tours évalués, les jetons consommés et le dernier motif de l’évaluateur après évaluation. Cet évaluateur lit ce que Claude a montré dans la conversation ; il n’exécute pas lui-même le contrôle et n’inspecte pas les fichiers. Un verdict « met » invite donc à vérifier, sans prouver la réparation. L’état Goal de Codex doit aussi être étayé par le résultat de la commande et le diff.

Gardez la boucle dans son périmètre initial. Lisez les commandes proposées avant de les autoriser, surtout celles qui suppriment des fichiers, réécrivent l’historique, envoient des données à l’extérieur ou changent les permissions. Arrêtez si le contrôle initial est affaibli, si un fichier sans rapport change sans explication ou si des données privées seraient exposées. Si vous ne pouvez autoriser la suite sans risque, consignez l’état du Goal et demandez un plan plus restreint.

4. Vérifier vous-même le résultat

Quand l’assistant annonce un succès, examinez le diff final complet par rapport à l’inventaire initial. Vérifiez chaque fichier modifié ou créé par rapport aux chemins autorisés. Relancez la même commande de contrôle d’origine si possible et conservez son résultat complet et son code de sortie. Exécutez les autres tests inchangés pertinents de votre note et examinez le comportement à préserver. La réussite d’un contrôle de substitution ne satisfait pas le contrat.

N’acceptez le changement que si les preuves correspondent à la condition relue et si vous approuvez le diff. Traitez commit, fusion et déploiement comme des décisions autorisées séparément. Si la vérification échoue, gardez commande et sortie exactes, fichiers modifiés, état Goal et permission, dépendance ou décision manquante précise. Un Goal suspendu, interrompu, impossible, bloqué ou limité par le budget n’est pas une réparation achevée.

Si le Goal s’arrête ou reste bloqué

Dans Claude Code, /goal montre la condition et le dernier motif ; /goal clear retire le Goal actif. Son manuel indique qu’une condition active peut revenir à la reprise d’une session, tandis que les bases de temps, tours et jetons sont réinitialisées. La restauration par le sélecteur de session a été corrigée en v2.1.239. Un échec d’authentification gérée par Claude Code, le crédit épuisé, un dépassement de contexte irrécupérable ou un modèle indisponible peuvent effacer le Goal. Une authentification gérée par l’hôte peut le laisser actif. D’autres erreurs peuvent le conserver et réessayer ou suspendre ; les messages interactifs correspondants sont documentés à partir de v2.1.269. Lisez avertissement, état, sortie sauvegardée et diff avant de définir ou reprendre quoi que ce soit. Une nouvelle condition remplace l’ancienne.

Dans la CLI interactive de Codex, /goal affiche l’objectif, tandis que /goal edit, /goal pause, /goal resume et /goal clear sont les commandes documentées dans la référence des commandes CLI. Son guide pratique distingue l’achèvement d’une suspension, interruption, limite de budget ou d’un blocage. Examinez l’état actuel et les preuves du dépôt avant de reprendre ou modifier l’objectif. Si une limite de budget ou d’accès a arrêté le travail, la suite utile peut être un blocage précis plutôt qu’une nouvelle tentative.

Les tours du modèle consomment le quota ou les crédits du compte, et l’évaluateur séparé de Claude Code consomme aussi des jetons. Vérifiez les contrôles et limites actuels de votre compte. Une clause en langage naturel sur le temps ou les tours ne garantit pas un plafond en dollars. Utilisez seulement les documents autorisés du dépôt, excluez secrets et fichiers privés sans rapport et examinez les instructions trouvées dans le dépôt avant que l’assistant les suive.

Pour une autre tâche de configuration, notre guide d’environnement Codex Cloud explique la connexion et la préparation d’un dépôt distant. Notre guide des Team Tasks partagées traite du travail récurrent dans ChatGPT. Aucune de ces configurations n’est requise pour la procédure locale ci-dessus.

Sources et lectures complémentaires