Erreur de fenêtre de contexte Codex : comment je l’ai gérée

Il m’est arrivé de tomber sur l’erreur de fenêtre de contexte de Codex en menant une longue session dans Codex CLI. Ce n’est pas le même problème que les limites d’usage sur 5 heures et à la semaine. Ces limites sont une contrainte de temps fixée par l’abonnement ; cette erreur survient quand les tokens accumulés dans une session dépassent ce que le modèle peut traiter.

Lancer /compact ne réglait pas toujours le problème. Voici ce que j’ai fait concrètement, et selon quels critères je répartis aujourd’hui les quatre commandes resume, fork, new et clear.

Quand l’erreur de fenêtre de contexte est apparue, et sur quelle tâche

Cette erreur ne surgit pas d’un coup au milieu d’un échange court. Elle s’accumule vers la fin des longues sessions de refactorisation qui passent d’un module à l’autre.

Dans mon cas, il s’agissait de remettre de l’ordre dans de la logique existante, sur un dépôt Java/Spring multimodule. J’ai commencé par une modification de deux ou trois fichiers, mais le périmètre à examiner n’a cessé de s’élargir, et les fichiers lus et les diffs se sont accumulés. J’ai répété plusieurs fois la boucle : lancer les tests → identifier la cause de l’échec → corriger le code → relancer.

Ça n’a pas cassé d’un coup dès le début. Plus la session avançait, plus je devais revérifier ce qui avait été décidé plus tôt ou remettre de l’ordre dans le contexte. Ces signes avant-coureurs se sont répétés quelques fois avant d’aboutir à l’erreur.

Sur un script d’un seul fichier, le contexte ne se serait sans doute pas rempli aussi vite. C’est le fait de consulter en même temps plusieurs modules et fichiers de test qui accélère la consommation du contexte.

Ne pas confondre avec les limites d’usage sur 5 heures et à la semaine

Cette erreur est indépendante de l’épuisement de vos limites d’usage. Les limites se réinitialisent avec le temps, alors que la fenêtre de contexte dépend de la quantité de tokens accumulés dans la session : l’erreur peut donc survenir même s’il vous reste de l’usage.

`/compact` : ce qui reste et ce qui disparaît vraiment

/compact n’est pas un point de sauvegarde qui garde la conversation précédente telle quelle. C’est un moyen de condenser le contexte pour que la session puisse continuer.

Après le compact, l’objectif général, les fichiers principaux et les décisions déjà prises étaient toujours là. En revanche, j’ai souvent dû réexpliquer le raisonnement derrière les décisions de détail.

/compact n’a pas non plus tout résolu. Quand la session était déjà trop longue ou que la direction du travail avait changé plusieurs fois, j’ai dû rajouter des explications même après le compact. Aujourd’hui, plutôt que d’enchaîner les /compact pour tenir jusqu’au bout, je passe à une nouvelle session dès que je sens que le coût d’explication du contexte remonte.

Et /compact ne se déclenche pas toujours automatiquement. Le message d’erreur signalé dans une issue GitHub est le suivant : Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying. (issue GitHub #19269, 24 avril 2026). Des cas reproduisant le même message ont aussi été publiés sur le forum des développeurs d’OpenAI. Le compte OpenAI_Support s’est contenté de demander la version, le modèle et les logs, et aucune solution de fond n’a encore été apportée.

Les 5 points que je reprécise moi-même après un compact

Après un compact, je réécris ces cinq points, une phrase pour chacun :

L’objectif final de la tâche en cours
Le périmètre des modifications de cette session
Les tests qui échouent encore
Les approches essayées puis abandonnées
Les zones auxquelles il ne faut pas toucher

resume, fork, new, clear : quelles différences et quand les utiliser

La commande resume poursuit le même raisonnement, fork permet de tester une autre décision à partir du même contexte, et new repart de zéro avec les seuls faits déjà confirmés.

Utiliser ces commandes sans distinction, à n’importe quel moment, finit par embrouiller encore plus le contexte. Voici comment je les répartis selon la situation :

Commande	Rôle	Quand l’utiliser	Ce qui reste et ce qui disparaît
`/compact`	Condense le contexte dans la même session	La session tient encore, mais le coût pour réexpliquer le contexte commence à grimper	L’objectif général, les fichiers principaux et les décisions restent ; les détails du contexte peuvent devoir être réexpliqués
`codex resume --last`	Reprend la même session telle quelle	La direction des décisions reste la bonne et il ne reste qu’à avancer sur les détails	L’historique précédent reste. Mais si le contexte est déjà plein, l’erreur peut revenir
`codex fork --last`	Ouvre une nouvelle branche à partir du même contexte	Vous voulez garder le contexte accumulé tout en testant une autre approche	Le contexte existant reste, et la suite se sépare selon la branche
`/new`	Démarre une nouvelle session	Les hypothèses et les approches ratées se sont empilées et le contexte lui-même est pollué	Les détails du contexte précédent disparaissent ; vous devez remettre à la main les faits confirmés

/clear n’est pas une commande que j’utilise souvent. Je n’ai pas de cas concret à présenter ici, je me contente donc de signaler que je m’en sers peu.

Le critère en une ligne

Le signal pour passer à une nouvelle session, c’est le moment où réexpliquer le contexte coûte plus cher que de le condenser et de le conserver. Un contexte long n’est pas un problème en soi.

Je ne pense pas que garder beaucoup de contexte soit toujours un avantage. Surtout dans des tâches comme la refactorisation, où les décisions intermédiaires changent sans cesse, il s’est révélé plus stable, à un certain point, de ne garder que les faits confirmés et de les transférer dans une nouvelle session plutôt que de continuer à traîner un vieux contexte compressé.

Le critère pour repérer ce moment est simple.

Si, même après un compact, vous rajoutez des explications de plus en plus souvent, le coût du maintien a déjà dépassé celui d’un nouveau départ.

Pourquoi je ne me fie pas à 100 % à la compaction automatique dans les versions actuelles

La fiabilité de la compaction automatique a varié selon les versions. Mieux vaut d’abord vérifier dans les issues GitHub si le symptôme que vous observez est une régression connue.

Les issues GitHub signalent aussi, séparément, des régressions où la compaction automatique ne se déclenche pas du tout dans certaines versions.

Le seuil de compaction automatique n’est pas une valeur tirée de la documentation officielle, mais un comportement interne que l’on constate dans les issues GitHub. D’après l’issue GitHub #11805, depuis la v0.100.0, le seuil de compaction défini par l’utilisateur est plafonné de force à 90 % de la fenêtre de contexte (issue ouverte le 14 février 2026, aujourd’hui fermée avec le statut « not planned »). Une régression où la compaction automatique ne s’exécute pas du tout a aussi été signalée : une issue indiquant qu’en v0.42.0, le compact ne se lance pas automatiquement en présence d’un grand ensemble de modifications.

Cette partie reflète la situation au moment de la rédaction (septembre 2026). Il faudra vérifier à nouveau si le comportement s’est stabilisé depuis.

Questions fréquentes

L’erreur de fenêtre de contexte persiste même après `/compact`. Que faire ?

Il peut s’agir d’une régression où la compaction automatique ne se déclenche pas. Dans ce cas, plutôt que de répéter le compact, il est plus stable de résumer l’objectif, le périmètre des modifications et les tests en échec en une phrase chacun, puis de passer à une nouvelle session.

Avec `codex resume --last` ou `fork --last`, le travail précédent est-il conservé tel quel ?

resume poursuit l’historique tel quel, mais l’erreur peut revenir si le contexte est déjà plein. fork crée une nouvelle branche en conservant le contexte existant, sans toutefois en préserver tous les détails.

Il existe une compaction automatique (auto-compact) : pourquoi intervenir manuellement ?

Des versions où la compaction automatique ne se déclenche pas ont été signalées. Mieux vaut d’abord vérifier si votre symptôme est une régression connue et, plutôt que de vous y fier, faire de l’intervention manuelle la règle.

Références

Issue GitHub #19269 : cas de reproduction de référence (source primaire) du message d’erreur « Codex ran out of room… » (2026-04-24, Codex CLI v0.124.0)
Fil du forum des développeurs d’OpenAI : cas de reproduction de la même erreur et réponse officielle d’OpenAI_Support (sans solution de fond)
Issue GitHub #11805 : source du plafonnement forcé du seuil de compaction automatique à 90 % de la fenêtre de contexte depuis la v0.100.0 (2026-02-14, fermée en not planned)
Issue GitHub #4363 : signalement d’une régression où le compact ne se lance pas automatiquement en v0.42.0 en présence d’un grand ensemble de modifications

Cet article a été localisé à partir de l’original en coréen : https://jjeongil.tistory.com/3568.