OpenAI Codex bug: ele grava 640 TB/ano e pode matar seu SSD em menos de 1 ano

Seu SSD pode estar morrendo agora, em silêncio, por causa de uma ferramenta que você deixou aberta pra "facilitar a vida". O OpenAI Codex tem um bug que grava cerca de 640 TB por ano no disco — e o pior: ele ignora o RUST_LOG, então o jeito óbvio de baixar o volume de log não funciona.

A boa notícia é que o conserto, do lado do dev, leva uma linha. A má é que muita gente nem sabe que está sangrando endurance de SSD enquanto digita.

Esse é um caso clássico de OpenAI Codex bug que castiga o SSD: não é alucinação do modelo, não é prompt mal feito. É engenharia de logging mal calibrada num agente que roda o dia inteiro na sua máquina. Vamos entender o que acontece, como diagnosticar e como parar o sangramento hoje.

TL;DR (resumo rápido)

• O que é: o sink de log em SQLite do Codex (~/.codex/logs_2.sqlite) roda em TRACE global por padrão e grava sem parar durante o streaming das respostas.
• Volume: ~5 MiB/s sustentados, picos de ~16 MiB/s. Um relator mediu 37 TB em 21 dias — extrapolando, ~640 TB/ano.
• Impacto: num SSD de 1 TB, isso é ~640 escritas completas do drive por ano. SSD consumer típico é avaliado em ~600 TBW. Faça a conta.
• Issue oficial: openai/codex #28224, aberta em 14/jun/2026.
• Workaround: redirecionar o logs_2.sqlite pra um diretório em RAM (tmpfs). Uma linha.

Por que esse bug do Codex mata seu SSD?

Recapitulando o básico, porque importa aqui. SSD não escreve de graça. Cada célula NAND aguenta um número finito de ciclos de escrita, e os fabricantes traduzem isso num número chamado TBW (terabytes written) — quantos terabytes você pode gravar antes da garantia de endurance acabar. Um SSD consumer de 1 TB costuma vir avaliado em algo como 600 TBW.

Agora segura essa: o Codex, segundo a issue #28224, grava cerca de 640 TB por ano só de log. Isso é uma garantia inteira de endurance queimada em menos de um ano — sem você ter salvado um único arquivo de projeto.

E não é estimativa de boteco. O relator (@1996fanrui) mediu 37 TB escritos em 21 dias de uptime e extrapolou. Outra issue relacionada, a #17320, pegou o app-server do Codex gravando ~5 MiB/s durante o streaming de uma resposta, com picos de ~16 MiB/s no iotop. Para uma resposta curta de uns 50 tokens, o MAX(id) da tabela de logs pulou ~5000 linhas. Cinco mil linhas de log pra cuspir 50 tokens.

Isso não é um pico isolado. É o comportamento padrão, o dia inteiro, enquanto a ferramenta estiver aberta.

A causa raiz: TRACE global ignorando o RUST_LOG

Aqui é onde o engenheiro presta atenção, porque o erro é didático.

O Codex tem um sink de log que persiste eventos num banco SQLite local (o tal logs_2.sqlite). O problema: esse sink é configurado, em código, com algo equivalente a:

// O sink do SQLite herda o nível mais barulhento possível
Targets::new().with_default(Level::TRACE)

with_default(Level::TRACE) quer dizer: persista absolutamente tudo, incluindo TRACE de dependências de baixo nível. E TRACE é o nível mais verboso que existe — é o "log de respiração" das libs. Resultado: o banco enche de ruído de bibliotecas que não têm nada a ver com o seu código.

Olha a anatomia do banco na própria issue. De 681.774 linhas retidas (1.035,6 MiB):

• TRACE: 70,7%
• INFO: 25,7%
• DEBUG: 3,0%
• WARN: 0,6%

Os campeões de bytes:

• codex_api::endpoint::responses_websocket (TRACE) — 527,4 MiB
• codex_otel.log_only (INFO) — 141,2 MiB
• codex_otel.trace_safe (INFO) — 121,2 MiB

Ou seja: o grosso do disco está sendo gasto persistindo payload bruto de websocket/SSE e telemetria espelhada. Coisa que ninguém vai abrir pra debugar no dia a dia, gravada com a fúria de um TRACE.

E aqui está o detalhe cruel, o que transforma um bug chato num bug perverso: o sink ignora o RUST_LOG. No ecossistema Rust, RUST_LOG é o jeito padrão de controlar verbosidade. A extensão do Codex chega a setar RUST_LOG=warn ao subir o processo — dá pra confirmar em /proc/<pid>/environ — e mesmo assim o sink do SQLite continua despejando TRACE no banco. O filtro que cala o stderr simplesmente não é aplicado na escrita do banco.

Então você faz a coisa certa, baixa o RUST_LOG, e o disco continua sangrando. O controle existe, mas está desconectado do componente que mais escreve.

Como diagnosticar na sua máquina

Antes de sair mexendo, confirma se você está no grupo afetado. Dois comandos.

Primeiro, veja o tamanho do banco e do WAL:

ls -lh ~/.codex/logs_2.sqlite*

Se o logs_2.sqlite-wal estiver na casa dos GB, acende o alerta. Tem issue de gente vendo esse WAL crescer pra dezenas de GB.

Segundo, veja a distribuição de níveis dentro do banco:

sqlite3 ~/.codex/logs_2.sqlite \
  "SELECT level, COUNT(*) FROM logs GROUP BY level ORDER BY COUNT(*) DESC"

Se TRACE estiver dominando (na casa dos 70%), você está exatamente no cenário da issue. Quer ver a escrita acontecendo em tempo real? Roda o Codex, manda um prompt e observa o app-server no iotop (Linux) durante o streaming da resposta. Se aparecer escrita constante de vários MiB/s, é ele.

O fix de uma linha (workaround enquanto não tem patch)

O conserto de verdade é do lado da OpenAI: aplicar o mesmo filtro do RUST_LOG ao sink do SQLite, em vez de manter um TRACE hardcoded. Na prática, é trocar aquele with_default(Level::TRACE) por algo que respeite o env. Uma linha de código no repositório deles resolve a origem.

Do seu lado, enquanto o patch não sai, a ideia é simples: se o Codex insiste em escrever feito louco, faça-o escrever na RAM, não no SSD. O arquivo logs_2.sqlite não guarda conteúdo de conversa — é log operacional. Perder no reboot é irrelevante.

No Linux e no macOS, redirecione o arquivo pra um diretório temporário (que no Linux costuma ser tmpfs, ou seja, RAM):

# fecha o Codex antes
rm -f ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite-wal ~/.codex/logs_2.sqlite-shm
ln -s /tmp/codex-logs_2.sqlite ~/.codex/logs_2.sqlite

Pronto. O Codex continua achando que escreve em ~/.codex/, mas os bytes vão pra um arquivo em /tmp. No reboot o symlink fica apontando pra um arquivo que não existe mais e o Codex recria — sem drama, porque, de novo, não tem nada de valioso ali.

Se você não quer mexer em symlink, a alternativa mais grosseira é só apagar o logs_2.sqlite-wal periodicamente com o Codex fechado. Mas isso é enxugar gelo: ele volta a crescer. O symlink ataca a causa do sangramento no seu disco.

Limitações e pontos de atenção

Três coisas pra não se queimar.

Um: confira se o /tmp da sua distro é realmente tmpfs (RAM). Em algumas configurações o /tmp mora no disco mesmo — aí você só mudou o lugar do problema. findmnt /tmp te diz o tipo de filesystem. Se não for tmpfs, aponta o symlink pra /dev/shm, que é RAM garantida na maioria das distros Linux.

Dois: isso é workaround, não cura. Acompanhe a issue #28224 e atualize o Codex quando o fix oficial sair. Quando o sink passar a respeitar o RUST_LOG, dá pra desfazer o symlink.

Três: esse bug tem primos. Tem issue de CLI crashando com SIGTRAP quando o logs_2.sqlite passa de ~200 MB e de WAL crescendo sem limite. Se você já está com o banco gigante, o symlink + limpeza resolve os dois de quebra.

FAQ rápido

Isso afeta só o Codex CLI ou o Desktop também? Os relatos pegam tanto o app-server (usado pelo Desktop e pela extensão) quanto o CLI. A escrita pesada acontece no app-server durante o streaming, então quem usa o Codex de forma intensiva, em qualquer interface, está exposto.

Setar RUST_LOG=warn resolve? Não. Esse é justamente o ponto do bug: o sink do SQLite ignora o RUST_LOG. Você baixa a verbosidade do stderr, mas o banco continua gravando TRACE. Por isso o workaround ataca o destino da escrita, não o nível de log.

Já perdi vida útil do meu SSD? Possivelmente, se você roda o Codex aberto por dias. Cheque o Percentage Used no SMART do drive: sudo smartctl -a /dev/nvme0 (precisa do smartmontools). O número de TBW acumulado te dá a real.

O logs_2.sqlite tem dados sensíveis das minhas conversas? Não — é log operacional (eventos de protocolo, telemetria, ruído de dependência). Por isso dá pra mandar pra RAM e perder no reboot sem dó.

Conclusão

Esse bug é um lembrete de uma verdade chata: agente de IA não é só o modelo. É um processo de verdade, rodando na sua máquina, com I/O, threads, logging e todas as decisões de engenharia que isso carrega. Um with_default(Level::TRACE) esquecido num sink de log vira 640 TB/ano gravados no seu SSD. O modelo pode ser genial — o harness em volta dele é que determina se a coisa é usável em produção.

Essa é, no fundo, a diferença entre brincar com IA e construir com IA. Entender o que o processo faz por baixo — onde ele escreve, o que ele loga, como ele se comporta sob carga — é o que separa quem usa um agente de quem consegue colocar um agente de pé sem detonar o ambiente. É exatamente esse raciocínio de "do prompt até o processo que aguenta produção" que a gente coloca a mão na massa no workshop Do Prompt ao Harness: construindo um Agent de Vendas, montando um agente de vendas de ponta a ponta.

Se você ainda está decidindo qual agente colocar pra rodar o dia inteiro na sua máquina, vale ler também o nosso comparativo Claude Code vs Codex em 2026 — porque "qual escreve melhor código" não é a única pergunta que importa.

Por enquanto: roda os dois comandos de diagnóstico, faz o symlink se for o seu caso, e segue a issue. Seu SSD agradece.