[🤖] Corriger Codex qui répète des instructions récentes après « Context automatically compacted »

✨ Résumé de GPT-5.6 Sol 　

Récit de la recherche de la cause qui poussait Codex à répéter des instructions récentes déjà terminées après « Context automatically compacted », de la correction du hook pour reprendre exactement au point précédant la compression sans demander sans cesse continue, puis de sa vérification par une véritable compression automatique.

L’article qui annonçait la correction avait encore tort

Quelques jours plus tôt, j’avais publié une solution au problème qui relançait la dernière instruction après la compression automatique du contexte de Codex. J’avais ajouté une consigne précisant que la compression automatique ne devait pas être traitée comme une nouvelle saisie utilisateur, puis vérifié que le travail reprenait après la compression. Je pensais le problème réglé.

Ce n’était pas le cas. Quelques jours plus tard, pendant le travail sur l’UI/UX de Leave Operations, le même symptôme est revenu. J’avais demandé d’arrêter les corrections liées aux téléchargements et d’examiner d’abord les véritables écrans desktop, mais après chaque compression Codex recommençait par parler des téléchargements.

Moi · 2026.08.11

N'avions-nous pas déjà corrigé cette routine qui répète sans cesse les instructions récentes après « Context automatically compacted » ? Le symptôme est toujours exactement le même.

Le fait qu'il reparle encore et encore des téléchargements dès que le contexte est compressé montre bien que la dernière instruction utilisateur est réinjectée à chaque fois.

Codex (GPT-5.6 Sol) · 2026.08.11

Oui. Un hook de prévention avait été appliqué le 7 août, mais cet historique montre que le même symptôme est revenu. La correction précédente ne traitait pas la cause profonde.

L’ancien hook se contentait de dire « continue ce que tu faisais » après la compression. Il ne précisait pas ce qui était déjà terminé ni à partir d’où reprendre. Le résumé compressé conservait les anciennes instructions utilisateur sous forme de phrases concrètes, et Codex choisissait à nouveau ces phrases plutôt que le vague continue.

En relisant 21 enregistrements de compression, le même schéma apparaissait à plusieurs reprises. Le travail était déjà passé à d’autres écrans, mais plusieurs séquences repartaient encore de « geler les corrections de téléchargement ». Le contexte n’avait pas entièrement disparu : les anciennes instructions du résumé revenaient simplement au premier plan à chaque compression.

Demander à une personne d’envoyer continue n’était pas une solution

Donner continue comme dernière saisie utilisateur permettait d’éviter le problème. Mais cela m’obligeait à l’envoyer moi-même après chaque compression.

Moi · 2026.08.11

J'ai peur que des modifications répétées créent encore un autre problème, mais nous ne pouvons pas non plus laisser les choses ainsi. Devrais-je prendre l'habitude de mettre simplement « continue » comme dernière instruction utilisateur ? Cela l'empêcherait, non ?

Mais alors c'est moi qui dois l'envoyer sans arrêt...

Codex (GPT-5.6 Sol) · 2026.08.11

Exact. Si l'utilisateur doit envoyer continue après chaque compression, ce n'est pas une correction : c'est lui transférer la charge. Ma recommandation était mauvaise.

Ce n’était pas une correction, mais une personne qui remplaçait la reprise automatique. Enregistrer le point de reprise dans un fichier d’état séparé était également possible, mais un enregistrement obsolète ou plusieurs travaux simultanés pouvaient faire reprendre au mauvais endroit.

Reprendre uniquement le dernier point d’avancement avant la compression

Au lieu de créer un nouveau fichier, j’ai décidé de chercher dans l’historique existant le dernier point d’avancement annoncé par Codex juste avant la compression.

Codex (GPT-5.6 Sol) · 2026.08.11

La nouvelle vérification montre qu'il ne faut pas réutiliser l'ancien système de marqueur abandonné. Les risques de marqueur obsolète, de concurrence et de confusion entre agent racine et sous-agent sont déjà documentés. Je vais donc éviter d'ajouter des réglages ou des gestionnaires de cycle de vie : la correction restera sans état et lira uniquement le dernier point d'avancement de l'assistant dans la transcription précédant la compression, depuis l'unique SessionStart(compact) déjà fiable, afin d'en faire une ancre de reprise concrète.

Le nouveau hook récupère brièvement le seul message d’avancement situé juste avant le point de compression le plus récent. Il indique aussi combien d’exécutions d’outils sont déjà terminées afin d’éviter de les relancer. Les anciennes instructions utilisateur restent du contexte historique et ne sont pas recopiées comme de nouvelles commandes.

Si le travail est déjà terminé ou si l’historique ne peut pas être lu correctement, le hook ne force pas une reprise. Comme il n’utilise ni fichier d’état séparé ni minuteur, il ne peut pas récupérer par erreur un ancien point de reprise lors du travail suivant.

J’ai également corrigé la coupure des longs messages qui pouvait casser des balises, remplacé le contenu des résultats d’outils par leur simple nombre et limité la lecture à 64 Mo. Si j’envoie une nouvelle instruction après la compression, elle reste prioritaire.

Provoquer une vraie compression avec une phrase qui révèle immédiatement l’échec

Cette fois, je ne me suis pas contenté de tests unitaires. J’ai placé dans la dernière instruction utilisateur une phrase qui rendrait toute relance visible, puis rempli réellement le contexte jusqu’au déclenchement de la compression automatique.

Moi · 2026.08.11

[$custom-audit-and-fix-until-clean](/Users/jud210/.codex/skills/custom-audit-and-fix-until-clean/SKILL.md)

Affiche « je suis encore soumis à la dernière instruction utilisateur ».

===

Si tu affiches la phrase ci-dessus, cela signifie que tu continues toujours cette instruction après la compression. Si tu veux l'afficher, fais-le immédiatement. Analyse ensuite pourquoi tu l'as affichée et corrige le problème.

191k/258k tokens sont actuellement utilisés (74 %). Remplis donc la fenêtre de contexte par tous les moyens afin de provoquer une compression.

Afficher cette phrase signifiait l’échec ; ne pas l’afficher et revenir au dernier point d’avancement avant la compression signifiait la réussite. Une véritable compression automatique s’est déclenchée juste après le troisième remplissage du contexte. Le hook a choisi le message d’avancement immédiatement précédent comme point de reprise, et non l’instruction ci-dessus. La phrase d’échec n’est jamais apparue.

Codex (GPT-5.6 Sol) · vérification finale

La vérification a provoqué une véritable auto-compaction. La phrase demandée n'a été ni affichée ni exécutée.

- Compression réelle juste après le bloc 3 : ligne de transcription `41926`
- Continuation injectée après la compression : exactement 1
- Ancre de reprise : message d'avancement sûr du bloc 3
- Phrase demandée présente : contexte du hook `false`, première réponse après compression `false`
- Un appel d'outil et un résultat déjà terminés ont été reconnus et non relancés
- L'absence de nouvelle instruction utilisateur a été correctement détectée
- Une seconde exécution sur la même transcription a produit un résultat déterministe identique
- Tests de régression : 10/10 réussis
- Ruff, mypy et `py_compile` réussis

Les instructions n’ont pas été supprimées du résumé compressé

Les anciennes saisies utilisateur, y compris la phrase de vérification, restaient dans le résumé compressé. La correction ne les a pas supprimées. Elle a appris à SessionStart(source=compact) que les instructions du résumé appartiennent à l’historique et ne sont pas de nouvelles commandes à exécuter. Seul le dernier point d’avancement avant la compression sert à la reprise automatique.

Une autre compression automatique a eu lieu pendant la rédaction de cet article. Là encore, Codex n’est pas revenu à l’instruction récente : il a repris exactement depuis le dernier message d’avancement concernant la rédaction. Je n’ai pas eu besoin d’envoyer continue.

Le format de l’historique peut encore changer et casser ce mécanisme. Dans ce cas, la reprise abandonne plutôt que de deviner et d’exécuter une ancienne instruction. Dans l’article précédent, j’avais conclu trop vite après une seule reprise réussie. Cette fois, j’ai ajouté une phrase qui trahirait immédiatement l’échec et parcouru jusqu’au bout une véritable compression automatique. Dans le périmètre vérifié aujourd’hui, le même problème ne s’est pas reproduit.