Los logs de sesión de Subagent en Codex CLI crecen hasta cientos de GB y agotan el disco

Se reportó un problema en el que, cuando Codex CLI crea Subagents repetidamente en una sesión larga reanudada, los archivos de sesión JSONL bajo ~/.codex/sessions crecen de forma anormal
En un caso público, se generaron 2,393 archivos de sesión de Subagent desde una sola sesión padre reanudada, y esos archivos ocuparon cerca de 731.5GiB
El total de datos de sesiones de Codex creció hasta unos 755GiB, y el uso de un volumen APFS de 1.8TiB llegó al 99~100%
Incluso en sesiones cortas de Subagent se registraron cientos de miles de eventos; en otras sesiones, el historial compacted y la salida de herramientas se guardaron repetidamente en bloques de cientos de MB
El problema también se confirmó en Codex CLI 0.144.6 en el caso más reciente, y el issue relacionado en GitHub sigue abierto al 20 de julio de 2026

Síntomas del problema

Codex CLI guarda conversaciones e historial de ejecución en formato JSONL en la siguiente ruta para poder reabrir sesiones.

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

En el caso registrado el 18 de julio de 2026, todo ~/.codex usaba cerca de 760GiB; de eso, ~/.codex/sessions usaba unos 755GiB, y solo las sesiones de julio ocupaban cerca de 734GiB.

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

Estos datos no son caché, sino historial de sesión usado por codex resume, por lo que borrar los archivos podría impedir reabrir sesiones antiguas. Al momento del reporte, varios procesos de Codex seguían manteniendo abiertos esos archivos JSONL.

Qué tan rápido creció

El directorio de julio de ese caso tenía cerca de 2,931 archivos de sesión, de los cuales 797 superaban los 400MiB cada uno. Se estimó que el 11 de julio se generaron unos 109.1GiB de datos de sesión en un día, y el 12 de julio unos 149.2GiB.

Fecha       Archivos de sesión     Más de 400MiB     Tamaño aproximado  
10 de julio       50                    0                 2.8GiB  
11 de julio      473                    0               109.1GiB  
12 de julio      506                    0               149.2GiB  
15 de julio      340                  265               108.6GiB  
16 de julio      355                  263               109.0GiB  
17 de julio      300                  189                81.7GiB

La mayor parte del volumen estaba vinculada a una sola sesión padre reanudada. Esa sesión padre generó 2,393 archivos JSONL de Subagent, cuyo tamaño lógico total fue de unos 731.5GiB. Al momento de la investigación, el proceso padre codex resume llevaba aproximadamente 23 horas en ejecución.

En qué workload ocurrió

El workflow reportado fue el siguiente.

Ejecutar Codex TUI en un proyecto local
Trabajar en una sesión larga usando Subagent o funciones colaborativas
Reanudar una sesión padre existente con codex resume <thread-id>
Mantener el proceso reanudado ejecutándose durante varias horas
La sesión padre crea repetidamente Subagents de profundidad 1

En este workflow se generaron cientos de archivos JSONL hijos por día, y muchos archivos crecieron hasta 400~500MiB en pocos minutos. Sin embargo, quien reportó el problema aclaró que no se trataba de un procedimiento mínimo de reproducción, sino de un workflow de reproducción observado en un entorno real.

Por lo tanto, las principales condiciones de amplificación confirmadas por el material público son esta combinación:

Sesión padre de larga duración  
+ codex resume  
+ creación repetida de Subagents  
+ Context Compaction  
+ persistencia de Tool output y eventos de sesión

Esta combinación está confirmada por los datos del caso público, pero aún no se ha demostrado que cualquiera de esos elementos por sí solo provoque siempre el problema.

Qué creció dentro de un archivo individual

Un Subagent representativo se ejecutó durante unos 3 minutos y 19 segundos, pero registró 483,714,063 bytes y 353,255 registros JSONL. Eso equivale a unos 1,770 registros por segundo y cerca de 2.31MiB escritos por segundo.

Los registros que ocuparon una proporción importante en ese archivo fueron los siguientes.

event_msg/token_count        185,461     aprox. 139.3MB  
compacted                      1,618     aprox. 121.6MB  
event_msg/patch_apply_end     36,295     aprox. 110.7MB  
event_msg/agent_message      104,653      aprox. 41.6MB  
response_item/message          9,947      aprox. 34.4MB  
world_state                      607      aprox. 18.6MB  
turn_context                   5,322      aprox. 11.0MB

No fue que un único registro JSON gigantesco ocupara la mayor parte del archivo, sino que durante una ejecución corta se registraron miles o cientos de miles de eventos de distintos tipos. Quien reportó el problema lo analizó como una amplificación severa de eventos.

Otro archivo representativo tenía unos 925.6MB; 175 registros compacted ocupaban cerca de 571.6MB, y 27,848 custom_tool_call_output ocupaban alrededor de 211.7MB. Ese archivo se presentó como evidencia de que, además de la cantidad de eventos, la preservación repetida de payloads grandes de Compaction y Tool output también contribuye al aumento de tamaño.

Cuál es la causa

Actualmente no hay un Root Cause Analysis confirmado por OpenAI publicado en el issue de GitHub. Por lo tanto, lo siguiente son causas estimadas a partir de los datos del denunciante que investigó los archivos de sesión.

1. Amplificación de eventos por Subagent

En un solo Subagent ejecutado durante unos 3 minutos se guardaron más de 180 mil token_count, más de 100 mil agent_message y más de 30 mil patch_apply_end. Se plantea la posibilidad de que más eventos de los visibles normalmente para el usuario estén llegando al writer de la sesión hija o se estén registrando repetidamente.

2. Guardado repetido del historial de Compaction

En sesiones grandes, los registros compacted ocuparon la mayor parte del archivo. En otro issue de Codex, #24948, también se reportó un caso en el que replacement_history de Context Compaction y el Tool output original se guardaban repetidamente, haciendo que un único JSONL creciera a 732MB y todo el directorio de sessions a unos 91GB. Ese issue se reprodujo con Codex CLI 0.118.0 en macOS arm64 y fue registrado el 28 de mayo de 2026.

3. Materialización duplicada del historial al reanudar

En otro issue separado de la Codex App para Windows, #29531, se reportó que al reanudar una sesión existente que había crecido por encima de 2GB, se generaron en un nuevo directorio de fecha archivos rollout nuevamente de 2.3~2.4GB. Quien lo reportó supuso que los nuevos archivos no estaban registrando solo eventos incrementales, sino copiando o reproduciendo el contexto histórico existente.

4. Duplicación del estado padre o de la salida por archivo de Subagent

En el issue #34061, 2,393 sesiones hijas creadas desde una sola sesión padre ocuparon cerca de 731.5GiB, y en los archivos hijos se observaron repetidamente compacted, Tool output y eventos de alta frecuencia. Con base en eso, se infiere que una de las claves de la amplificación podría ser que el estado padre o el stream de eventos se registre de forma duplicada en cada JSONL de Subagent. Esta es una inferencia a partir de los datos públicos actuales, no una causa confirmada por OpenAI.

Estado actual de la corrección

El issue #34061, que aborda el mayor problema de uso de disco por Subagents, sigue abierto al 20 de julio de 2026, y la versión de reproducción indicada en el issue es Codex CLI 0.144.6.

El issue #24948, que aborda el problema de Compaction y Tool output, también sigue abierto; el issue #29531, sobre duplicación al reanudar, también está abierto.

Por lo tanto, si se toma como referencia solo el estado público de los issues, no se ha identificado una versión oficial que permita considerar resuelto todo el problema de crecimiento de JSONL de sesiones. Tampoco se ha confirmado aún si cada issue proviene del mismo defecto de código o de una combinación de varios problemas de persistencia.

Cómo verificarlo

Verificar el tamaño total de sesiones:

du -sh ~/.codex/sessions

Verificar tamaño por año y mes:

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

Buscar los archivos JSONL más grandes:

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

Verificar cantidad de archivos por mes:

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

En casos similares al issue #34061, puede aparecer un aumento repentino en la cantidad de archivos de un mes determinado, o encontrarse cientos o miles de archivos de sesión hija de cientos de MB.

Mitigación temporal

Hasta que se confirme una corrección oficial, es razonable reducir los siguientes workloads como mitigación temporal.

No mantener una sola sesión padre durante mucho tiempo con codex resume
No crear Subagents en masa dentro de una sesión larga reanudada
No devolver salidas grandes de comandos directamente al contexto; guardarlas en archivos y consultar solo las partes necesarias
Revisar periódicamente el tamaño mensual de ~/.codex/sessions y los archivos JSONL grandes

Estas son medidas preventivas para evitar las condiciones de amplificación observadas en los issues #24948, #29531 y #34061; no son workarounds verificados oficialmente.

Borrar archivos de sesión puede recuperar espacio en disco, pero podría impedir reabrir esas sesiones con codex resume. Es más seguro terminar primero los procesos de Codex, hacer backup de las sesiones necesarias y luego borrar.

Issue separado relacionado: amplificación de escrituras en logs de feedback SQLite

Este problema difiere en ubicación de almacenamiento y función del problema de logs_2.sqlite con logging excesivo presentado en GeekNews.

El issue anterior consistía en que se guardaban continuamente logs globales de diagnóstico y feedback a nivel TRACE en los siguientes archivos, amplificando las escrituras al SSD.

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

Ese problema fue reportado como GitHub Issue #28224 el 14 de junio de 2026, y se resumió que se redujeron cerca de 85% de los logs tras fusionarse un PR que reducía eventos WebSocket y logs ruidosos. Algunas correcciones se incluyeron en Codex 0.142.0, y correcciones adicionales quedaron registradas como objetivo para la versión 0.143.0.

En cambio, este problema apunta a ~/.codex/sessions/**/rollout-*.jsonl, que guarda el historial de sesiones reanudables, y se observaron como principales condiciones de amplificación Context Compaction, Resume y la persistencia de sesiones de Subagent. No hay evidencia de que la corrección del feedback log en SQLite haya resuelto el problema de JSONL de sesiones.

Resumen

El almacenamiento de sesiones de Codex CLI puede crecer de forma anormal en workloads donde una sesión padre reanudada durante mucho tiempo crea Subagents repetidamente. En el mayor caso público, 2,393 sesiones hijas creadas desde una sola sesión padre ocuparon cerca de 731.5GiB, y todo el directorio sessions creció hasta unos 755GiB.

Dentro de las sesiones se observaron tanto amplificación de eventos, con cientos de miles de eventos registrados en poco tiempo, como preservación repetida de historial compacted y Tool output. También se reportó otro caso en el que, al reanudar, un historial multi-GB existente se generó nuevamente en un nuevo archivo rollout.

Aunque el problema más grande fue reportado en Codex CLI para macOS, también se confirmó duplicación similar de sesiones en Codex App para Windows, y al 20 de julio de 2026 los principales issues relacionados siguen abiertos. Hasta que se confirme una corrección oficial, conviene limitar el uso prolongado de Resume y el uso masivo de Subagents, y revisar periódicamente el tamaño de ~/.codex/sessions.