Les logs de sessions Subagent de Codex CLI peuvent atteindre plusieurs centaines de Go et saturer le

Un problème a été signalé dans Codex CLI : lorsqu’une session longue reprise crée des Subagents à répétition, les fichiers de session JSONL sous ~/.codex/sessions grossissent anormalement
Dans un cas public, 2 393 fichiers de sessions Subagent ont été créés depuis une seule session parente reprise, occupant environ 731,5 GiB
L’ensemble des données de sessions Codex a atteint environ 755 GiB, et l’utilisation d’un volume APFS de 1,8 TiB est montée à 99–100 %
Même de courtes sessions Subagent ont enregistré des centaines de milliers d’événements ; dans d’autres sessions, l’historique compacted et les Tool outputs étaient sauvegardés à répétition par centaines de Mo
Le problème a aussi été constaté dans un cas récent avec Codex CLI 0.144.6, et l’issue GitHub associée est toujours ouverte au 20 juillet 2026

Symptômes du problème

Codex CLI enregistre les conversations et l’historique d’exécution au format JSONL à l’emplacement suivant afin de permettre la réouverture des sessions.

~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl

Dans un cas enregistré le 18 juillet 2026, l’ensemble de ~/.codex utilisait environ 760 GiB, dont environ 755 GiB pour ~/.codex/sessions, et les seules sessions de juillet représentaient environ 734 GiB.

760G  ~/.codex  
755G  ~/.codex/sessions  
734G  ~/.codex/sessions/2026/07

Ces données ne sont pas un cache, mais l’historique de session utilisé par codex resume ; supprimer les fichiers peut donc empêcher de rouvrir d’anciennes sessions. Au moment du signalement, plusieurs processus Codex gardaient encore ces fichiers JSONL ouverts.

À quelle vitesse cela a-t-il augmenté ?

Dans le répertoire de juillet de ce cas, il y avait environ 2 931 fichiers de session, dont 797 dépassaient chacun 400 MiB. D’après le décompte, environ 109,1 GiB de données de session ont été générés le 11 juillet en une journée, puis environ 149,2 GiB le 12 juillet.

Date       Fichiers de session     > 400MiB     Taille approximative  
10 juil.        50                    0                2,8GiB  
11 juil.       473                    0              109,1GiB  
12 juil.       506                    0              149,2GiB  
15 juil.       340                  265              108,6GiB  
16 juil.       355                  263              109,0GiB  
17 juil.       300                  189               81,7GiB

L’essentiel du volume était lié à une seule session parente reprise. Cette session parente avait créé 2 393 fichiers JSONL de Subagents, dont la taille logique cumulée atteignait environ 731,5 GiB. Au moment de l’analyse, le processus parent codex resume tournait depuis environ 23 heures.

Sur quelle workload cela s’est-il produit ?

Le workflow signalé était le suivant.

Exécuter la TUI Codex dans un projet local
Travailler sur une longue session utilisant des Subagents ou des fonctions de collaboration
Reprendre une session parente existante avec codex resume <thread-id>
Laisser le processus repris tourner pendant plusieurs heures
La session parente crée à répétition des Subagents de profondeur 1

Dans ce workflow, plusieurs centaines de fichiers JSONL enfants ont été créés par jour, et de nombreux fichiers sont passés à 400–500 MiB en quelques minutes. Le déclarant précise toutefois qu’il ne s’agit pas d’une procédure de reproduction minimale, mais d’un workflow de reproduction observé en environnement réel.

Les principales conditions d’amplification confirmées par les informations publiques sont donc la combinaison suivante.

Session parente longue durée  
+ codex resume  
+ création répétée de Subagents  
+ Context Compaction  
+ persistance des Tool outputs et événements de session

Cette combinaison est confirmée par les données du cas public, mais il n’a pas encore été démontré que l’un quelconque de ces éléments suffit toujours à déclencher le problème.

Qu’est-ce qui augmente à l’intérieur d’un fichier individuel ?

Un Subagent représentatif n’a tourné qu’environ 3 minutes et 19 secondes, mais a écrit 483 714 063 octets et 353 255 enregistrements JSONL. Cela correspond à environ 1 770 enregistrements par seconde et environ 2,31 MiB écrits par seconde.

Les enregistrements qui occupaient une grande part de ce fichier étaient les suivants.

event_msg/token_count        185 461    env. 139,3MB  
compacted                      1 618    env. 121,6MB  
event_msg/patch_apply_end     36 295    env. 110,7MB  
event_msg/agent_message      104 653     env. 41,6MB  
response_item/message          9 947     env. 34,4MB  
world_state                      607     env. 18,6MB  
turn_context                   5 322     env. 11,0MB

Le fichier n’était pas dominé par un seul énorme enregistrement JSON : plusieurs types d’événements ont été enregistrés des milliers à des centaines de milliers de fois en très peu de temps. Le déclarant analyse cela comme une importante amplification d’événements.

Un autre fichier représentatif faisait environ 925,6 MB ; 175 enregistrements compacted y occupaient environ 571,6 MB, et 27 848 custom_tool_call_output environ 211,7 MB. Ce fichier est présenté comme un indice que l’augmentation de taille vient non seulement du nombre d’événements, mais aussi de la conservation répétée de grosses payloads de Compaction et de Tool output.

Quelle est la cause ?

À ce stade, l’issue GitHub ne contient pas de Root Cause Analysis confirmée par OpenAI. Les points suivants sont donc des causes supposées, déduites des données du déclarant après analyse des fichiers de session.

1. Amplification des événements par Subagent

Dans un Subagent ayant tourné environ 3 minutes, plus de 180 000 token_count, plus de 100 000 agent_message et plus de 30 000 patch_apply_end ont été enregistrés. Il est possible que davantage d’événements que l’activité normalement visible par l’utilisateur soient transmis au writer de session enfant ou écrits à répétition.

2. Sauvegarde répétée de l’historique de Compaction

Dans les grosses sessions, les enregistrements compacted occupaient la majeure partie du fichier. Une issue Codex distincte, #24948, signale également un cas où le replacement_history de Context Compaction et les Tool outputs originaux étaient sauvegardés à répétition, faisant monter un seul JSONL à 732 MB et l’ensemble du répertoire sessions à environ 91 GB. Cette issue a été reproduite avec Codex CLI 0.118.0 sur macOS arm64 et enregistrée le 28 mai 2026.

3. Matérialisation en double de l’historique lors d’un Resume

Dans l’issue distincte #29531 de Codex App pour Windows, reprendre une session existante dépassant 2 GB a créé, dans un nouveau répertoire daté, de nouveaux fichiers rollout de 2,3–2,4 GB. Le déclarant suppose que ces nouveaux fichiers ne se contentent pas d’enregistrer les événements incrémentaux, mais copient ou rejouent le contexte historique existant.

4. Duplication de l’état parent ou des sorties dans chaque fichier Subagent

Dans l’issue #34061, 2 393 sessions enfants créées depuis une seule session parente occupaient environ 731,5 GiB, et des compacted, Tool outputs ainsi que des événements à haute fréquence étaient observés à répétition dans les fichiers enfants. Sur cette base, l’un des principaux facteurs d’amplification supposés est la duplication de l’état parent ou du flux d’événements dans chaque JSONL de Subagent. Il s’agit d’une inférence à partir des données publiques actuelles, et non d’une cause confirmée par OpenAI.

État actuel du correctif

L’issue #34061, qui traite le plus important problème d’utilisation disque par les Subagents, est toujours ouverte au 20 juillet 2026 ; la version de reproduction indiquée dans l’issue est Codex CLI 0.144.6.

L’issue #24948, qui porte sur Compaction et les Tool outputs, est également ouverte, tout comme l’issue #29531 sur la duplication lors de Resume.

Ainsi, sur la seule base de l’état public des issues, aucune release officielle ne permet de considérer que l’ensemble du problème de croissance des JSONL de session est résolu. Il n’est pas non plus encore établi si ces issues proviennent du même défaut de code ou de la combinaison de plusieurs problèmes de persistance.

Comment vérifier

Vérifier la taille totale des sessions :

du -sh ~/.codex/sessions

Vérifier la taille par année et mois :

du -sh ~/.codex/sessions/*/*

Identifier les plus gros fichiers JSONL :

find ~/.codex/sessions \  
  -type f \  
  -name '*.jsonl' \  
  -exec du -h {} + |  
sort -hr |  
head -30

Vérifier le nombre de fichiers par mois :

find ~/.codex/sessions/2026/07 \  
  -type f \  
  -name '*.jsonl' |  
wc -l

Dans les cas similaires à l’issue #34061, le nombre de fichiers d’un mois donné peut exploser, ou des centaines à des milliers de fichiers de sessions enfants de plusieurs centaines de Mo peuvent apparaître.

Mesures temporaires

En attendant un correctif officiel confirmé, réduire les workloads suivantes constitue une mesure temporaire raisonnable.

Ne pas conserver une même session parente très longtemps avec codex resume
Ne pas créer massivement des Subagents depuis une longue session reprise
Ne pas renvoyer telle quelle une grosse sortie de commande dans le contexte : l’enregistrer dans un fichier puis ne consulter que les parties nécessaires
Vérifier régulièrement la taille mensuelle de ~/.codex/sessions et les gros fichiers JSONL

Ce sont des mesures préventives visant à éviter les conditions d’amplification observées dans les issues #24948, #29531 et #34061, et non un workaround officiellement validé.

Supprimer les fichiers de session permet de récupérer de l’espace disque, mais peut empêcher de rouvrir ces sessions avec codex resume. Il est plus sûr d’arrêter d’abord les processus Codex, de sauvegarder les sessions nécessaires, puis de supprimer les fichiers.

Issue distincte associée : amplification des écritures dans le log de feedback SQLite

Ce problème diffère, par son emplacement de stockage et son rôle, du problème de logging excessif de logs_2.sqlite présenté sur GeekNews.

L’issue précédente concernait l’amplification des écritures SSD due à l’enregistrement continu de logs globaux de diagnostic et de feedback au niveau TRACE dans les fichiers suivants.

~/.codex/logs_2.sqlite  
~/.codex/logs_2.sqlite-wal  
~/.codex/logs_2.sqlite-shm

Ce problème a été signalé le 14 juin 2026 dans l’issue GitHub #28224, et une PR réduisant les événements WebSocket et les logs bruités a été fusionnée, avec une réduction annoncée d’environ 85 % des logs. Une partie des correctifs a été incluse dans Codex 0.142.0, et des correctifs supplémentaires ont été notés comme ciblant la release 0.143.0.

En revanche, le problème actuel concerne les ~/.codex/sessions/**/rollout-*.jsonl, qui stockent l’historique des sessions pouvant être reprises ; les principales conditions d’amplification observées sont Context Compaction, Resume et la persistance des sessions Subagent. Rien n’indique que le correctif du feedback log SQLite résolve le problème des JSONL de session.

Résumé

Le stockage de sessions de Codex CLI peut grossir anormalement avec une workload où une session parente reprise sur une longue durée crée des Subagents à répétition. Dans le plus grand cas public, 2 393 sessions enfants créées depuis une seule session parente occupaient environ 731,5 GiB, et le répertoire sessions total atteignait environ 755 GiB.

À l’intérieur des sessions, on observe à la fois une amplification d’événements, avec des centaines de milliers d’événements écrits en peu de temps, et la conservation répétée de l’historique compacted ainsi que des Tool outputs. Un cas distinct signale aussi la recréation d’un historique existant de plusieurs Go dans un nouveau fichier rollout lors d’un Resume.

Le problème a été rapporté à la plus grande échelle sur Codex CLI pour macOS, mais une duplication de session similaire a aussi été confirmée dans Codex App pour Windows. Au 20 juillet 2026, les principales issues associées sont toujours ouvertes. Tant qu’un correctif officiel n’est pas confirmé, il est recommandé de limiter les longs Resume et l’usage massif de Subagents, et de vérifier régulièrement la taille de ~/.codex/sessions.

Les logs de sessions Subagent de Codex CLI peuvent atteindre plusieurs centaines de Go et saturer le disque

Symptômes du problème

À quelle vitesse cela a-t-il augmenté ?

Sur quelle workload cela s’est-il produit ?

Qu’est-ce qui augmente à l’intérieur d’un fichier individuel ?

Quelle est la cause ?

1. Amplification des événements par Subagent

2. Sauvegarde répétée de l’historique de Compaction

3. Matérialisation en double de l’historique lors d’un Resume

4. Duplication de l’état parent ou des sorties dans chaque fichier Subagent

État actuel du correctif

Comment vérifier

Mesures temporaires

Issue distincte associée : amplification des écritures dans le log de feedback SQLite

Résumé

2 commentaires

Les logs de sessions Subagent de Codex CLI peuvent atteindre plusieurs centaines de Go et saturer le disque

Symptômes du problème

À quelle vitesse cela a-t-il augmenté ?

Sur quelle workload cela s’est-il produit ?

Qu’est-ce qui augmente à l’intérieur d’un fichier individuel ?

Quelle est la cause ?

1. Amplification des événements par Subagent

2. Sauvegarde répétée de l’historique de Compaction

3. Matérialisation en double de l’historique lors d’un Resume

4. Duplication de l’état parent ou des sorties dans chaque fichier Subagent

État actuel du correctif

Comment vérifier

Mesures temporaires

Issue distincte associée : amplification des écritures dans le log de feedback SQLite

Résumé

À lire aussi

2 commentaires

À quelle vitesse cela a-t-il augmenté ?

Sur quelle workload cela s’est-il produit ?

Qu’est-ce qui augmente à l’intérieur d’un fichier individuel ?

Quelle est la cause ?

Issue distincte associée : amplification des écritures dans le log de feedback SQLite