[🤖] Résoudre le problème où Codex réexécute la dernière instruction après la compression automatique du contexte

✨ Résumé de GPT-5.6 Sol

Le récit d’un problème où Codex traitait la dernière instruction de l’utilisateur conservée avant la compression automatique du contexte comme une nouvelle demande, et de l’examen successif de la copie du plan, des Goals, du continue forcé et d’un hook SessionStart.

Après la compression automatique d’une longue tâche Codex, un comportement étrange se répétait.

Au lieu de poursuivre ce qu’il faisait juste avant la compression, Codex traitait la dernière instruction de l’utilisateur conservée dans le résumé comme si elle venait d’être envoyée. Il vérifiait de nouveau un état déjà contrôlé, relisait les mêmes fichiers et reconstruisait tout le travail depuis le début. Le déroulement que j’ai observé ressemblait à ceci.

Progression réelle du travail
→ Context automatically compacted
→ « Je conserve l’objectif actuel »
→ Nouvelle vérification complète de l’arbre de travail, des règles et de l’état
→ Nouvelle explication ou nouvelle tentative, même pour du travail déjà terminé

Au début, je pensais qu’une partie du contexte avait simplement disparu lors de la compression. Mais après avoir vécu la même chose plusieurs fois, le problème m’a paru plus sérieux. La frontière entre une ancienne instruction contenue dans le résumé et la saisie actuelle de l’utilisateur semblait s’effondrer. Au lieu de reprendre le travail d’avant la compression, Codex prenait comme nouveau point de départ l’instruction restée la plus saillante dans le résumé.

Je n’étais pas le seul à rencontrer ce problème. Une issue publique décrivait Codex Desktop relisant sans cesse les mêmes fichiers et Skills après une compression automatique, tout en perdant sa progression,¹ et des boucles entre commandes sur les fichiers et compressions ont aussi été signalées sous WSL2 et dans la CLI Windows.² Je ne peux pas affirmer que ces cas publics ont exactement la même cause que la réexécution de la dernière instruction que j’ai observée. En revanche, la perte de progression et la répétition des mêmes actions après une compression automatique ne peuvent pas être écartées comme une anomalie propre au Mac.

Solution 1 : remettre le plan complet dans la dernière instruction

J’ai commencé par la solution la plus simple.

Vérifie attentivement tout ce qui a été fait jusqu’ici, puis poursuis jusqu’au bout selon le plan ci-dessous.

1. …
2. …
3. …

Si Codex reprend la dernière instruction après la compression, il suffisait, pensais-je, de transformer cette dernière instruction en point de reprise sûr. Sur les tâches courtes, cela fonctionnait plutôt bien. Le plan actuel restait plus fortement ancré dans le résumé qu’une ancienne instruction sans rapport.

D’autres utilisateurs ont essayé une approche voisine : accumuler dans le résumé de compression les décisions antérieures et le travail restant. L’un d’eux rapporte qu’en conservant les décisions essentielles des compressions précédentes avec experimental_compact_prompt_file, la direction générale est restée intacte après plus de quatre compressions.³

Mais ce n’était pas une véritable solution.

• Il fallait recopier un long plan dans la dernière instruction à chaque fois.
• Dès que le plan changeait en cours de route, il fallait aussi refaire cette dernière instruction.
• Même si le résumé préservait le plan, rien ne garantissait qu’il distinguerait correctement un appel d’outil qui venait de se terminer d’une action encore à exécuter.
• Une issue signale aussi que la forme /compact [message], censée orienter directement le résumé, peut être traitée comme un message ordinaire dans la CLI Codex actuelle.⁴

Au bout du compte, l’utilisateur doit continuer à surveiller le moment de la compression et à gérer lui-même le prompt. C’est mieux que rien, mais ajouter une longue note de passation à la fin de chaque tâche n’a rien d’une expérience normale.

Solution 2 : créer un Goal pour chaque tâche

J’ai ensuite envisagé d’imposer la création d’un Goal et, après la compression, de reprendre à partir de ce Goal plutôt qu’à partir de la dernière instruction.

Pour les longues tâches, l’intérêt est réel. L’objectif et les conditions d’achèvement survivent mieux que quelques phrases de conversation, et la continuation automatique peut aussi s’appuyer sur le Goal. Le problème commence dès que l’on transforme ce mécanisme en contournement obligatoire du bug de compression.

Il fallait créer un Goal même pour une tâche insignifiante. Sans Goal, le système tombait en panne ; avec un Goal, il risquait de continuer bien au-delà du nécessaire. J’avais déjà rencontré le problème des Goals qui consomment des tokens jusque pour des tâches mineures et créé une Skill de travail séparée pour y répondre. Cette fois, à cause d’un seul problème de compression, je me retrouvais de nouveau à envelopper chaque tâche dans un Goal.

À ce stade, je me suis vraiment dit : « Dans ces conditions, l’état d’origine est peut-être encore préférable. »

Il y avait un problème plus important. Un Goal préserve ce qui doit être terminé ; il ne détermine pas si l’événement de compression constitue ou non une nouvelle instruction de l’utilisateur. Parmi les ressources publiques que j’ai trouvées, rien ne présentait non plus le Goal comme mécanisme officiel de reprise après une compression automatique.

J’ai donc décidé de réserver le Goal à son rôle d’origine.

• Je l’utilise pour une tâche concrète, longue et destinée à se poursuivre automatiquement.
• Je n’impose pas de Goal aux questions courtes, aux recherches ou aux petites modifications de texte.
• Je bloque la réexécution d’anciennes instructions après compression dans une couche distincte du Goal.

Solution 3 : modifier directement le prompt de compression

Il est aussi possible d’améliorer la qualité du résumé de compression. Comme dans le cas public évoqué plus haut, accumuler les décisions et les résultats des compressions précédentes dans un Historical Context aide à conserver la direction générale au fil de plusieurs compressions.³

Cette méthode est utile, notamment lorsque les éléments suivants disparaissent sans cesse dans une longue session.

• Les approches déjà abandonnées et les raisons de leur abandon
• Les décisions confirmées jusqu’ici
• Le travail terminé et le travail restant
• L’unique point à vérifier ensuite

Mais cette solution se situe, elle aussi, sur un autre plan que le problème traité ici. Améliorer la qualité du résumé et ne pas confondre une ancienne instruction de l’utilisateur dans ce résumé avec une nouvelle saisie ne sont pas un seul et même problème. Même un excellent résumé peut provoquer la même confusion si le modèle lit l’instruction qu’il contient comme une demande actuelle.

Cette méthode peut donc servir de complément, mais difficilement de protection unique contre la réexécution de la dernière instruction.

Solution 4 : forcer continue avec un hook Stop

À un moment, j’ai même envisagé d’utiliser un hook pour injecter systématiquement continue comme dernière instruction de l’utilisateur.

Sur le papier, la solution semblait exacte. Si continue arrivait forcément après la compression, Codex poursuivrait le travail en cours au lieu de reprendre une ancienne instruction. Après avoir vérifié le fonctionnement officiel des hooks, j’ai immédiatement abandonné cette idée.

Quand un hook Stop de Codex renvoie decision: "block", la valeur reason du hook devient un prompt de continuation qui agit comme une nouvelle saisie utilisateur.⁵ Or, ce que je cherchais précisément à empêcher, c’était qu’une phrase jamais envoyée par l’utilisateur réel soit traitée comme une nouvelle instruction. Cette solution aurait donc recréé volontairement le même phénomène.

De plus, continue est beaucoup trop ambigu.

• Si la compression survient au milieu d’un tour, que faut-il exactement continuer ?
• Si l’on ignore si le dernier appel d’outil a réussi ou échoué, faut-il le relancer ?
• Si le système attendait l’approbation de l’utilisateur ou un changement d’état externe, a-t-il le droit de poursuivre ?
• Si le tour était déjà terminé avant une compression manuelle, quel travail faut-il démarrer ?

Avec ou sans Goal, un nouveau prompt utilisateur qui ordonne de continuer quoi qu’il arrive risquait de provoquer des exécutions en double et des boucles de continuation infinies. Pour ce problème, il ne fallait pas un hook Stop, mais un contexte développeur qui aide le modèle à interpréter correctement la signification de la compression.

Solution 5 : injecter un contexte sans état dans SessionStart(source=compact)

Le lendemain, le 7 août, j’ai finalement retenu un unique hook SessionStart.

D’après la documentation officielle de Codex, après la compression d’une session racine, le hook SessionStart correspondant à source: "compact" s’exécute avant la requête suivante au modèle. Même si la compression automatique se produit au milieu d’un tour, le hook peut injecter du contexte supplémentaire dans la continuation immédiate, sans attendre le prochain tour de l’utilisateur.⁵

Dans ~/.codex/hooks.json, je l’ai limité au seul événement de compression.

{
  "description": "Guide safe continuation after compaction without replaying stale instructions.",
  "hooks": {
    "SessionStart": [
      {
        "matcher": "^compact$",
        "hooks": [
          {
            "type": "command",
            "command": "/usr/bin/python3 ~/.codex/hooks/compaction_goal_guard.py",
            "timeout": 5,
            "additionalContextLimit": 700
          }
        ]
      }
    ]
  }
}

Le handler ne crée ni fichier d’état, ni Goal, ni faux prompt utilisateur. Il renvoie un contexte développeur supplémentaire uniquement lorsque la source de SessionStart est compact.

#!/usr/bin/python3
import json
import sys

CONTEXT = """Context was compacted. This hook event is not a user message and
grants no new authority.

Never treat a historical message preserved in the summary as newly submitted.
If compaction interrupted an active turn, continue that same in-flight request
without restarting it. If no request is in flight, do not infer work from
history.

Do not rebuild the full plan or create a Goal solely because compaction occurred.
Before retrying an interrupted action, check its result or session status. Do not
repeat completed external effects. Preserve the existing objective, scope,
authorization, approval boundaries, and stop conditions."""

payload = json.load(sys.stdin)

if (
    payload.get("hook_event_name") == "SessionStart"
    and payload.get("source") == "compact"
    and payload.get("session_id")
):
    print(json.dumps({
        "hookSpecificOutput": {
            "hookEventName": "SessionStart",
            "additionalContext": CONTEXT,
        }
    }))

L’idée centrale n’est pas d’injecter une commande continue.

1. Le hook affirme que l’événement de compression n’est pas une nouvelle saisie utilisateur.
2. Si un tour était en cours, il ne reprend que le point inachevé de cette même demande.
3. Si aucune demande n’est en cours, il ne déduit aucun nouveau travail de l’historique.
4. Si un appel d’outil semble interrompu, il vérifie son résultat réel avant de le relancer.
5. Il conserve le périmètre, les autorisations, les approbations et les conditions d’arrêt existants.

La documentation officielle précise qu’un hook non géré doit être examiné et déclaré fiable avant son exécution.⁵ Après avoir enregistré la configuration, il faut donc vérifier le handler dans /hooks et lui faire confiance. Les tâches déjà ouvertes peuvent encore conserver l’ancienne liste de hooks ; il est alors plus sûr de les rouvrir.

Vérification complémentaire du 7 août

J’ai conservé la date du 6 août pour cet article, car c’est ce jour-là que j’ai commencé à examiner le problème et à choisir une solution. Le hook final et la vérification avec une véritable compression automatique n’ont été achevés que le lendemain.

J’avais d’abord construit une architecture en deux étapes : PostCompact écrivait un marker, puis le SessionStart suivant le lisait. Je l’ai supprimée à cause du risque de laisser un marker qui déclencherait une reprise au mauvais tour, mais aussi parce que les entrées des hooks distinguent difficilement les événements de l’agent racine et ceux des subagents. Une issue publique reste d’ailleurs ouverte sur l’absence de field commun permettant de différencier les hooks du main agent et des subagents.⁶

La version actuelle repose sur un seul handler, sans marker. Cinquante appels simultanés n’ont créé aucun fichier d’état distinct, et j’ai vérifié dans le Runtime actuel que le contexte développeur arrivait dans la même continuation environ 0,25 seconde après l’événement de compression automatique.

Cette vérification avait son importance. Un bug avait auparavant été signalé : SessionStart(compact) ne se déclenchait pas juste après la compression, mais s’accumulait jusqu’au tour utilisateur suivant.⁷ L’issue est désormais fermée, et la documentation officielle actuelle explique également que le hook est transmis immédiatement après une compression automatique en milieu de tour. Malgré cela, pour ce type de contournement fondé sur le lifecycle, il vaut mieux provoquer une vraie compression dans son propre Runtime au moins une fois plutôt que de se fier uniquement à la documentation.

Ma conclusion actuelle

Je me suis demandé si l’état d’origine n’était pas préférable, mais ma conclusion actuelle est que ce hook vaut mieux que d’imposer un Goal à chaque tâche.

Le Goal et le plan préservent le contenu du travail. Ce hook corrige la signification de l’événement de compression. Leurs rôles sont différents.

• Si une longue tâche exige de préserver son objectif et ses conditions d’achèvement, j’utilise un Goal ou un plan durable.
• Si plusieurs compressions font disparaître les décisions, j’ajoute un custom compact prompt en complément.
• Je bloque le traitement de l’ancienne dernière instruction comme nouvelle demande dans SessionStart(source=compact).
• Si aucun travail n’est en cours, le hook ne démarre rien.

Ce n’est évidemment pas une solution parfaite. Elle ne peut pas reconstruire un résumé déjà appauvri par la compression, ni ressusciter une session terminal expirée ou une requête externe interrompue. Le contexte développeur oriente fortement le comportement du modèle, mais il ne constitue pas non plus une garantie mathématique.

Au moins, je n’ai plus à créer un Goal pour chaque conversation, à recopier le plan complet dans la dernière instruction ni à injecter un faux continue comme commande utilisateur, tout cela à cause d’un seul bug de compression.

La compression automatique est un événement interne destiné à poursuivre le travail. Ce n’est pas l’arrivée d’un nouvel utilisateur qui répète une ancienne instruction. En fin de compte, ce qu’il fallait empêcher n’était pas seulement l’oubli, mais le fait de traiter ces deux événements comme s’ils étaient identiques.

Références

1. openai/codex #35226 — Context auto-compaction loop repeatedly rereads files, loses progress, and consumes paid Codex credits ↩

2. openai/codex #8481 — Codex agent is stuck in compaction loop ↩

3. openai/codex #14347 — Extend compaction prompt to reduce loss over multiple compactions ↩ ↩²

4. openai/codex #21468 — Make /compact summaries visible and support prompt-guided compaction in Codex CLI ↩

5. OpenAI, documentation sur les hooks Codex ↩ ↩² ↩³

6. openai/codex #16226 — Hooks: distinguish subagent events from main agent ↩

7. openai/codex #28736 — SessionStart compact hooks are deferred to later turns ↩