Log de sessão de Subagent no Codex CLI cresce para centenas de GB e esgota o disco

Foi relatado um problema em que, quando o Codex CLI cria repetidamente Subagents em sessões longas retomadas, os arquivos de sessão JSONL em ~/.codex/sessions crescem de forma anormal
Em um caso público, uma única sessão pai retomada gerou 2.393 arquivos de sessão de Subagent, que ocuparam cerca de 731,5GiB
O total de dados de sessão do Codex chegou a cerca de 755GiB, e o uso de um volume APFS de 1,8TiB atingiu 99~100%
Mesmo em sessões curtas de Subagent, foram registrados centenas de milhares de eventos; em outras sessões, o histórico de compacted e a saída de ferramentas foram armazenados repetidamente em blocos de centenas de MB
O problema também foi confirmado no caso mais recente com o Codex CLI 0.144.6, e a issue correspondente no GitHub continua aberta em 20 de julho de 2026

Sintomas do problema

O Codex CLI salva conversas e histórico de execução em formato JSONL no caminho abaixo para permitir reabrir sessões.

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

Em um caso registrado em 18 de julho de 2026, ~/.codex como um todo usava cerca de 760GiB, dos quais ~/.codex/sessions consumia cerca de 755GiB, e somente as sessões de julho ocupavam cerca de 734GiB.

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

Esses dados não são cache, mas sim histórico de sessão usado por codex resume, então apagar os arquivos pode impedir a reabertura de sessões anteriores. No momento da denúncia, vários processos do Codex ainda mantinham esses arquivos JSONL abertos.

Quão rápido cresceu

No diretório de julho desse caso havia cerca de 2.931 arquivos de sessão, dos quais 797 ultrapassavam 400MiB cada. Foi calculado que cerca de 109,1GiB de dados de sessão foram gerados em 11 de julho e cerca de 149,2GiB em 12 de julho.

Data          Arquivos de sessão   Acima de 400MiB   Tamanho aproximado  
10 de julho              50                0              2,8GiB  
11 de julho             473                0            109,1GiB  
12 de julho             506                0            149,2GiB  
15 de julho             340              265            108,6GiB  
16 de julho             355              263            109,0GiB  
17 de julho             300              189             81,7GiB

A maior parte do volume estava ligada a uma única sessão pai retomada. Essa sessão pai gerou 2.393 arquivos JSONL de Subagent, cuja soma do tamanho lógico foi de cerca de 731,5GiB. No momento da investigação, o processo pai codex resume estava em execução havia cerca de 23 horas.

Em que workload isso ocorreu

O workflow relatado foi o seguinte.

Executar o Codex TUI em um projeto local
Trabalhar em uma sessão longa usando Subagent ou recursos de colaboração
Retomar uma sessão pai existente com codex resume <thread-id>
Manter o processo retomado em execução por várias horas
A sessão pai cria repetidamente Subagents com depth 1

Nesse workflow, eram criados centenas de arquivos JSONL filhos por dia, e muitos chegavam a 400~500MiB em poucos minutos. Ainda assim, quem reportou deixou claro que isso não é um procedimento mínimo de reprodução, mas um workflow reproduzível observado em ambiente real.

Assim, a principal combinação de condições de amplificação que pode ser confirmada pelo material público atual é a seguinte.

Sessão pai de longa duração  
+ codex resume  
+ criação repetida de Subagent  
+ Context Compaction  
+ persistência permanente de Tool output e eventos de sessão

Essa combinação é confirmada pelos dados do caso público, mas ainda não foi demonstrado que qualquer um desses fatores isoladamente sempre cause o problema.

O que cresceu dentro de um único arquivo

Um Subagent representativo executou por cerca de 3 minutos e 19 segundos, mas registrou 483.714.063 bytes e 353.255 registros JSONL. Isso equivale a cerca de 1.770 registros por segundo e aproximadamente 2,31MiB de gravação por segundo.

Os registros que mais ocuparam espaço nesse arquivo foram os seguintes.

event_msg/token_count        185.461    cerca de 139,3MB  
compacted                      1.618    cerca de 121,6MB  
event_msg/patch_apply_end     36.295    cerca de 110,7MB  
event_msg/agent_message      104.653     cerca de 41,6MB  
response_item/message          9.947     cerca de 34,4MB  
world_state                      607     cerca de 18,6MB  
turn_context                   5.322     cerca de 11,0MB

Não era um único registro JSON gigante ocupando quase todo o arquivo, mas sim vários tipos de eventos sendo gravados milhares a centenas de milhares de vezes em um curto período de execução. Quem reportou analisou isso como uma grave amplificação de eventos.

Outro arquivo representativo tinha cerca de 925,6MB, dos quais 175 registros compacted ocupavam cerca de 571,6MB e 27.848 custom_tool_call_output ocupavam cerca de 211,7MB. Esse arquivo foi apresentado como evidência de que, além da quantidade de eventos, a preservação repetida de payloads grandes de Compaction e Tool output também contribui para o aumento de tamanho.

Qual é a causa

Até o momento, a issue no GitHub não traz uma Root Cause Analysis confirmada pela OpenAI. Portanto, o que segue são causas estimadas a partir dos dados levantados por quem investigou os arquivos de sessão.

1. Amplificação de eventos por Subagent

Em um único Subagent executado por cerca de 3 minutos, foram salvos mais de 180 mil token_count, mais de 100 mil agent_message e mais de 30 mil patch_apply_end. Levanta-se a possibilidade de que mais eventos do que a atividade visível ao usuário, ou registros repetidos desses eventos, estejam sendo enviados ao writer da sessão filha.

2. Armazenamento repetido do histórico de Compaction

Em sessões grandes, os registros compacted ocupavam a maior parte do arquivo. Em uma issue separada do Codex, a #24948, também foi relatado um caso em que replacement_history de Context Compaction e a Tool output original eram gravados repetidamente, fazendo um único JSONL chegar a 732MB e o diretório completo de sessions a cerca de 91GB. Essa issue foi reproduzida com Codex CLI 0.118.0 em macOS arm64 e registrada em 28 de maio de 2026.

3. Materialização duplicada do histórico anterior ao retomar

Em uma issue separada da Codex App para Windows, a #29531, foi relatado um caso em que, ao retomar uma sessão existente que já havia passado de 2GB, novos arquivos rollout de 2,3~2,4GB foram gerados novamente em um diretório de data novo. Quem reportou supõe que os arquivos novos não registram apenas eventos incrementais, mas copiam ou reproduzem novamente o contexto histórico existente.

4. Duplicação do estado ou da saída da sessão pai em cada arquivo de Subagent

Na issue #34061, 2.393 sessões filhas geradas a partir de uma única sessão pai ocuparam cerca de 731,5GiB, e nos arquivos filhos foram observados repetidamente compacted, Tool output e eventos de alta frequência. Com base nisso, estima-se que a duplicação do estado da sessão pai ou do stream de eventos em cada JSONL de Subagent seja um dos principais fatores de amplificação. Trata-se de uma inferência a partir dos dados públicos atuais, não de uma causa confirmada pela OpenAI.

Estado atual da correção

A issue #34061, que trata do maior problema de uso de disco por Subagent, continua aberta em 20 de julho de 2026, e a versão de reprodução indicada nela é o Codex CLI 0.144.6.

A issue #24948, sobre Compaction e Tool output, também está aberta, e a issue #29531, sobre duplicação no Resume, igualmente permanece aberta.

Portanto, considerando apenas o estado público atual das issues, não há evidência de uma release oficial em que o problema geral de crescimento dos JSONL de sessão esteja resolvido. Também ainda não está claro se todas essas issues derivam do mesmo bug de código ou se são vários problemas de persistência combinados.

Como verificar

Verificar o tamanho total das sessões:

du -sh ~/.codex/sessions

Verificar o tamanho por ano/mês:

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

Verificar os maiores arquivos JSONL:

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

Verificar a quantidade de arquivos por mês:

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

Em casos semelhantes à issue #34061, a quantidade de arquivos em um mês específico pode disparar, ou podem ser encontrados centenas ou milhares de arquivos de sessão filha com centenas de MB cada.

Mitigação temporária

Até que uma correção oficial seja confirmada, faz sentido reduzir os seguintes workloads como medida temporária.

Não manter uma única sessão pai em codex resume por longos períodos
Não criar grandes quantidades de Subagents em sessões longas retomadas
Em vez de devolver grandes saídas de comandos diretamente ao contexto, salvar em arquivo e consultar apenas os trechos necessários
Verificar periodicamente o tamanho mensal de ~/.codex/sessions e os arquivos JSONL grandes

Essas são medidas preventivas para evitar as condições de amplificação observadas nas issues #24948, #29531 e #34061, e não um workaround oficialmente validado.

Apagar arquivos de sessão pode recuperar espaço em disco, mas pode impedir que a sessão correspondente seja reaberta com codex resume. É mais seguro encerrar primeiro os processos do Codex, fazer backup das sessões necessárias e só então apagar.

Outra issue relacionada: amplificação de escrita no log de feedback em SQLite

Esse problema é diferente do logs_2.sqlite com logging excessivo já apresentado no GeekNews, tanto na localização de armazenamento quanto na função.

A issue anterior tratava da gravação contínua de logs globais de diagnóstico e feedback em nível TRACE nos arquivos abaixo, ampliando o volume de escrita no SSD.

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

Esse problema foi reportado em 14 de junho de 2026 na GitHub Issue #28224, e foi resumido que um PR para reduzir eventos de WebSocket e logs ruidosos diminuiu cerca de 85% dos logs. Parte das correções entrou no Codex 0.142.0, e correções adicionais foram registradas como alvo da release 0.143.0.

Já o problema atual afeta ~/.codex/sessions/**/rollout-*.jsonl, que armazena histórico de sessão passível de retomada, e Context Compaction, Resume e persistência de sessão de Subagent foram observados como principais condições de amplificação. Não há evidência de que a correção do log de feedback em SQLite resolva por si só o problema dos JSONL de sessão.

Resumo

O repositório de sessões do Codex CLI pode crescer de forma anormal em workloads onde uma sessão pai retomada por longo tempo cria Subagents repetidamente. No maior caso público, 2.393 sessões filhas geradas por uma única sessão pai ocuparam cerca de 731,5GiB, e o diretório total de sessions cresceu para cerca de 755GiB.

Dentro das sessões, foram observados ao mesmo tempo amplificação de eventos, com centenas de milhares de eventos registrados em pouco tempo, e preservação repetida de histórico compacted e Tool output. Também há um caso separado em que histórico prévio de vários GB foi gerado novamente em novos arquivos rollout durante o Resume.

O problema foi reportado em maior escala no Codex CLI para macOS, mas duplicação semelhante de sessão também foi confirmada na Codex App para Windows, e as principais issues relacionadas continuam abertas em 20 de julho de 2026. Até que uma correção oficial seja confirmada, é necessário limitar o uso prolongado de Resume e o uso massivo de Subagents, além de verificar periodicamente o tamanho de ~/.codex/sessions.