Imagine abrir o terminal, rodar o Codex da OpenAI para escrever umas funções, tomar um café, e quando voltar — seu SSD já perdeu semanas de vida útil. Parece exagero? Um desenvolvedor descobriu que o Codex CLI está, silenciosamente, destruindo SSDs ao redor do mundo.

640 TB por Ano: Os Números que Assustam

Um desenvolvedor abriu uma issue no GitHub do Codex com dados que fariam qualquer engenheiro de storage engasgar. Ele monitorou as escritas no disco por 21 dias de uso normal do Codex CLI e encontrou 37 terabytes gravados no SSD principal.

Fazendo a conta simples: 37 TB em 21 dias dá aproximadamente 640 TB por ano.

Agora coloca isso em perspectiva. Um SSD NVMe de consumo típico — tipo Samsung 980 Pro, WD Black SN850 — tem uma classificação de endurance (TBW) entre 300 e 600 terabytes. Ou seja, o Codex sozinho consegue esgotar a vida útil inteira do seu SSD em menos de 12 meses.

Se você tem um SSD mais barato, a situação é ainda pior. Modelos QLC com TBW de 200-300 podem morrer em meses.

O Que Está Acontecendo Por Baixo dos Panos

O culpado é um banco de dados SQLite localizado em ~/.codex/. Três arquivos:

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

O Codex usa esses arquivos para armazenar logs de feedback — dados de telemetria que supostamente ajudam a OpenAI a melhorar o produto. Até aí, nada demais. Todo software faz logging.

O problema é como esse logging foi implementado.

O sink de logs usa Targets::new().with_default(Level::TRACE) como configuração global. Se você não é familiar com níveis de logging, TRACE é o nível mais verboso que existe. É o equivalente a colocar uma câmera em cada neurônio do software e gravar absolutamente tudo.

// O que a OpenAI fez (simplificado)
Targets::new().with_default(Level::TRACE)

// O que deveria ter feito
Targets::new()
    .with_target("codex_core", Level::INFO)
    .with_target("codex_agent", Level::DEBUG)
    // Sem capturar ruído de dependências

Resultado? O Codex grava:

• Payloads completos de WebSocket/SSE — cada token que o modelo retorna
• Eventos de inotify — cada vez que um arquivo é tocado no diretório monitorado
• Logs internos de dependências — ruído do Tokio, Hyper, e outros crates Rust
• Eventos de OpenTelemetry duplicados — porque sim, os mesmos dados são escritos duas vezes

Uma análise do conteúdo retido mostrou que 70,7% são logs TRACE que ninguém nunca vai ler, e 25,3% são eventos de telemetria espelhados — ou seja, duplicados.

O Write Amplification que Ninguém Percebeu

Aqui a coisa fica ainda mais sinistra. O banco SQLite mantém cerca de 500 mil linhas ativas. Parece razoável, certo? Mas o contador de AUTOINCREMENT estava em 5,5 bilhões.

Isso significa uma proporção de 10.000:1 entre linhas inseridas e linhas retidas. O Codex insere dados freneticamente e depois apaga a maior parte, num ciclo infinito de insert-and-prune.

Para quem não entende por que isso é devastador: SSDs não funcionam como HDs. Cada célula NAND tem um número finito de ciclos de escrita. Quando você escreve e apaga repetidamente, está literalmente gastando a vida física do hardware. E com SQLite, a situação é pior ainda — o WAL (Write-Ahead Log) precisa sincronizar com o banco principal, gerando escritas adicionais que o sistema operacional nem reporta.

# Quer ver o estrago no Linux?
# Confira os bytes escritos no seu disco
cat /proc/diskstats | awk '{print $3, $10 * 512 / 1024 / 1024 / 1024, "GB"}'

# Ou use o smartctl para ver o TBW acumulado
sudo smartctl -a /dev/nvme0n1 | grep "Data Units Written"

Um sample de 15 segundos capturado pelo autor da issue mostrou 36.211 linhas inseridas enquanto o total retido ficava estável. O banco está girando como uma máquina de lavar — entra dado por um lado, sai pelo outro, e o SSD paga o preço.

Não É um Bug Novo — É um Bug Ignorado

Aqui vai o detalhe que irrita: esse problema não surgiu ontem. Existem pelo menos 8 issues no repositório do Codex documentando variações desse mesmo bug. A mais antiga, issue #17320, reporta escritas excessivas no WAL do SQLite durante streaming e aponta que a variável RUST_LOG é completamente ignorada pelo sink de feedback.

O changelog do Codex menciona “correções de confiabilidade do SQLite” em versões recentes, mas nenhuma delas abordou o volume de escritas. A OpenAI consertou crashes e corrompimento de dados, mas o problema fundamental — TRACE-level logging para um banco de dados local — continua lá.

No Windows a situação chegou a ser pior. A issue #29177 reporta que o Codex Desktop causa travamentos completos do sistema por causa da I/O excessiva no SQLite. Não é só o SSD morrendo aos poucos — é o PC inteiro engasgando.

Quanto Já Morreu do Seu SSD?

Se você usa o Codex há algum tempo e nunca checou, agora é a hora. No Linux:

# Instale o smartmontools se não tiver
sudo apt install smartmontools

# Veja as estatísticas do SSD
sudo smartctl -a /dev/nvme0n1

# Procure por "Data Units Written"
# Cada unidade = 512 KB * 1000 = ~512 MB
# Multiplique pelo número para ter o total em TB

No macOS:

# Instale via Homebrew
brew install smartmontools

# Confira
sudo smartctl -a /dev/disk0

Se o número de “Data Units Written” parecer absurdamente alto para o tempo que você tem o SSD, o Codex pode ser o responsável.

A Solução Temporária (Workaround)

Enquanto a OpenAI não resolve isso de verdade, existe um workaround que funciona no Linux e macOS. A ideia é redirecionar os logs do SQLite para o /tmp/, que normalmente roda em RAM (tmpfs):

# Pare o Codex primeiro
# Depois mova e crie o symlink
mv ~/.codex/logs_2.sqlite /tmp/codex_logs.sqlite
mv ~/.codex/logs_2.sqlite-wal /tmp/codex_logs.sqlite-wal
mv ~/.codex/logs_2.sqlite-shm /tmp/codex_logs.sqlite-shm

ln -s /tmp/codex_logs.sqlite ~/.codex/logs_2.sqlite
ln -s /tmp/codex_logs.sqlite-wal ~/.codex/logs_2.sqlite-wal
ln -s /tmp/codex_logs.sqlite-shm ~/.codex/logs_2.sqlite-shm

Com isso, os logs vão para a RAM e desaparecem no próximo reboot. Seu SSD fica em paz.

Atenção: isso significa que os logs de feedback são perdidos a cada reinicialização. Se você quer preservar algum dado de debug, faça backup antes.

Outra alternativa mais radical é simplesmente apagar os arquivos periodicamente com um cron job:

# Adicione ao crontab: apaga logs do Codex a cada hora
0 * * * * rm -f ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite-wal ~/.codex/logs_2.sqlite-shm

O Que a OpenAI Deveria Fazer

O autor da issue propôs correções que removeriam 96% do volume de escritas sem desabilitar a funcionalidade de feedback:

1. Trocar TRACE por INFO nos módulos core do Codex — mantém logs úteis, corta o ruído
2. Eliminar logs de dependências — ninguém precisa de TRACE do Tokio ou Hyper
3. Armazenar resumos em vez de payloads completos — o tamanho cru de cada resposta WebSocket não precisa ir para o banco
4. Implementar limites de tamanho — um cap global de, digamos, 500 MB no banco evitaria o cenário apocalíptico

São mudanças triviais. Literalmente trocar uma linha de configuração e adicionar um check de tamanho. O fato de isso não ter sido feito até agora, com 8 issues abertas, é… revelador.

O Elefante na Sala: Telemetria ou Desleixo?

Eu tenho uma teoria sobre por que esse bug existe e por que não foi consertado. A resposta está no incentivo.

Para a OpenAI, quanto mais dados de telemetria, melhor. Cada prompt que você envia, cada resposta que o modelo gera, cada arquivo que o agente toca — tudo isso é ouro para treinar a próxima versão. O logging em TRACE não é um acidente — é a configuração que maximiza a coleta de dados.

Não estou dizendo que é intencional destruir SSDs. Mas quando o bug que maximiza a coleta de dados é também o bug que ninguém tem pressa em consertar… a gente começa a desconfiar.

E é especialmente irônico vindo de uma ferramenta que roda localmente. Um dos argumentos de venda do Codex CLI é que ele opera no seu terminal, no seu ambiente. Mas ele grava cada keystroke e cada resposta num banco SQLite que, eventualmente, vai matar o hardware onde está rodando.

SSDs São Mais Frágeis do que Você Pensa

Muita gente trata SSD como se fosse eterno. “Ah, mas o meu tem 600 TBW, nunca vou chegar nisso.” Em uso normal, provavelmente não. Um usuário típico escreve entre 5 e 20 GB por dia — o que dá uns 3 a 7 TB por ano.

Mas “uso normal” não inclui um agente de IA escrevendo 1,76 TB por dia em logs TRACE.

E tem mais: o TBW oficial é medido com write amplification factor (WAF) próximo de 1.0, usando workloads sequenciais otimistas. Na prática, com escritas aleatórias pequenas (exatamente o padrão do SQLite), o WAF real pode ser 2x, 3x ou mais. Então aqueles 640 TB/ano podem se traduzir em mais de 1 petabyte de escritas físicas na NAND.

A diferença é obscena.

Quem Mais Faz Isso?

O Codex não é a única ferramenta dev com apetite voraz por I/O. Editores como VS Code com extensões pesadas, Docker com imagens grandes, e builds de CI/CD locais também pesam no SSD. Mas nenhum deles se aproxima de 640 TB/ano.

Para referência, um setup Docker intenso com builds diárias gera talvez 50-100 TB/ano. O Codex é 6 a 12 vezes pior que o cenário mais pesado que a maioria dos devs encontra.

E diferente de Docker ou builds, os logs do Codex não produzem nada de valor para o usuário. É puro overhead — dados de telemetria que só beneficiam a OpenAI.

Como Monitorar Escritas no Disco em Tempo Real

Se você quer ver ao vivo o que o Codex está fazendo com seu SSD, o iotop é seu melhor amigo:

# Instale se necessário
sudo apt install iotop-c

# Monitore escritas em tempo real (precisa de root)
sudo iotop -o -a

# Para algo mais granular, use o blktrace
sudo blktrace -d /dev/nvme0n1 -o - | blkparse -i -

Outra abordagem é usar o inotifywait para vigiar diretamente os arquivos do Codex:

# Monitore mudanças nos arquivos de log
inotifywait -m ~/.codex/ -e modify -e create -e delete

Se você ver centenas de eventos por segundo no logs_2.sqlite, confirmou o problema.

Ferramentas Alternativas que Não Destroem Seu Hardware

Se esse bug está te fazendo repensar suas opções, vale lembrar que o mercado de agentes de código em terminal é competitivo em 2026:

• Claude Code — Agente da Anthropic que roda no terminal. Usa logs mais conservadores e não tem esse tipo de problema documentado.
• Aider — Open source, leve, e não grava terabytes de telemetria no seu disco.
• Cursor — IDE dedicada que faz o processamento pesado na nuvem, poupando o SSD local.

Nenhum deles é perfeito, mas nenhum ameaça matar seu hardware.

O Que Fazer Agora

Se você usa o Codex CLI:

1. Cheque seu SSD — Use smartctl para ver quanto já foi escrito
2. Aplique o workaround — Redirecione os logs para /tmp/ ou RAM
3. Monitore — Configure alertas para escritas anômalas no disco
4. Acompanhe a issue — #28224 no GitHub é o lugar certo
5. Considere alternativas — Se o bug não for resolvido em breve, migrar pode ser a decisão mais econômica

O irônico dessa história toda é que o Codex é uma ferramenta para escrever código melhor. Mas o código que grava os logs? Esse não passou por nenhum code review decente. Uma linha de configuração mal feita está custando hardware real de pessoas reais — e a empresa que vale centenas de bilhões não consertou porque, no fim das contas, os dados que estão matando seu SSD são os mesmos dados que alimentam o próximo modelo.