Bug de logging do Codex pode gerar gravações na casa dos TB em SSDs locais e desgastar rapidamente sua vida útil

 (github.com/openai)
1 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O Codex grava continuamente grandes volumes de dados no banco de logs de feedback SQLite local e, em um ambiente de usuário, após 21 dias de funcionamento cerca de 37 TB foram gravados no SSD principal
  • Isso equivale a cerca de 640 TB por ano, ou aproximadamente 640 gravações completas da unidade por ano em um SSD de 1 TB, podendo esgotar em menos de 1 ano a vida útil garantida de gravação de alguns SSDs de consumo (cerca de 600 TBW)
  • Embora apenas cerca de 500 mil linhas sejam retidas, o contador AUTOINCREMENT ultrapassou 5,5 bilhões de IDs, criando uma diferença de cerca de 10 mil vezes entre linhas preservadas e IDs de inserção acumulados
  • A causa é que o sink de sincronização do log de feedback em SQLite foi configurado com o TRACE global como padrão (Targets::new().with_default(Level::TRACE)), fazendo com que até logs internos de dependências e payloads brutos de protocolo em grande volume fossem gravados permanentemente
  • Em 22 de junho de 2026, dois PRs foram mesclados, bloqueando cerca de 85% dos logs e encerrando o issue

Principais sintomas e escopo do impacto

  • O Codex faz gravações contínuas e volumosas nos seguintes arquivos
    • ~/.codex/logs_2.sqlite
    • ~/.codex/logs_2.sqlite-wal
    • ~/.codex/logs_2.sqlite-shm
  • Após 21 dias de execução, cerca de 37 TB foram gravados no SSD principal, e inspeções por processo/arquivo confirmaram que os logs SQLite do Codex eram a principal fonte de gravação contínua
  • Isso equivale a cerca de 640 TB por ano, ou aproximadamente 640 gravações completas da unidade por ano em um SSD de 1 TB
  • Alguns SSDs de consumo têm classificação de cerca de 600 TBW, o que pode consumir a vida útil garantida de gravação em menos de 1 ano

Dados de evidência

  • Evidence1 — amplificação de escrita (write amplification)

    • Tamanho atual do arquivo logs_2.sqlite: 1.2 GiB
    • Linhas atualmente retidas: 506,149
    • row id total alocado: 5,543,677,486
    • Há uma diferença de cerca de 10 mil vezes entre as linhas retidas (cerca de 0,5M) e os IDs acumulados de inserção (5,5B+), sugerindo mais de 10 TB de churn histórico de logs mesmo sem contar WAL, índices, pruning, checkpoints, regravação de páginas e amplificação no nível do dispositivo

  • Evidence2 — distribuição por nível/alvo

    • 681,774 linhas retidas, com conteúdo de log preservado estimado em cerca de 1,035.6 MiB
    • Participação por nível: TRACE 70.7%, INFO 25.7%, DEBUG 3.0%, WARN 0.6%
    • Maiores pares target+level
      • 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
      • log (TRACE) 97.4 MiB
    • As principais fontes são, em sua maioria, logs TRACE globais, logs de telemetria espelhados e gravação de payloads brutos de websocket/SSE
    • codex_otel.log_only + codex_otel.trace_safe respondem por mais 25.3%, e filtrar essas categorias poderia remover cerca de 96% dos bytes de log preservados na amostra
    • A fonte TRACE mais frequente (target=log) inclui muitos itens de baixo nível como inotify event (por exemplo, ld.so.cache 128,764 vezes), chamadas internas de tokio-tungstenite e WouldBlock

  • Medição da amplificação de escrita

    • Em uma amostra de 15 segundos, o número de linhas retidas permaneceu em 681,774, mas cerca de 36,211 linhas foram inseridas
    • O padrão repetido de insert-and-prune — inserir → indexar → gravar no WAL → podar — gera amplificação de escrita

Causa estimada

  • O sink de log de feedback em SQLite foi instalado com o TRACE global como padrão (Targets::new().with_default(Level::TRACE))
  • Com isso, todos os alvos passam a ser armazenados permanentemente em nível TRACE, incluindo logs internos/de dependências e payloads brutos de protocolo em grande volume

Direção de correção proposta

  • Manter os logs de feedback, mas reduzir o escopo do armazenamento persistente por padrão
    • Não usar TRACE global no sink de log de feedback SQLite
    • Aumentar o limiar ou remover ruído de baixo valor como target=log, hyper_util, internals do tokio-tungstenite, spam de inotify e logs de baixo nível do OpenTelemetry SDK
    • Em vez de armazenar payloads brutos completos de websocket/SSE, guardar apenas um resumo (tipo de evento, duração, sucesso/falha, uso de tokens, tamanho do payload em bytes)
    • Evitar armazenar eventos espelhados de codex_otel.log_only / codex_otel.trace_safe, exceto quando forem úteis para depuração
    • Como limites por thread não bastam, adicionar também um limite global de tamanho/gravação para o banco de logs
  • Uma opção como sqlite_logs_enabled = false também seria útil, mas a correção principal é uma filtragem padrão melhor

Relatos de reprodução em múltiplas plataformas

  • macOS

    • Em macOS 15.7.7 / Codex 26.616.51431, logs_2.sqlite tinha 113M, MAX(id)=34,277,360, 31,405 linhas retidas, e duas amostras de 60 segundos mostraram cerca de 60 gravações por segundo
    • Houve relato de uma sessão de 1–2 horas em que o processo codex gravou cerca de 50 GB

  • Windows

    • No Codex Desktop para Windows (codex.exe app-server --analytics-default-enabled), linhas TRACE continuaram sendo inseridas mesmo sem RUST_LOG=warn e sem configuração explícita de trace
    • Havia cerca de 71 mil linhas retidas, enquanto o valor logs em sqlite_sequence passava de 18,5 milhões, indicando muito churn histórico de insert/prune
    • Em uma distribuição de 10 minutos, havia 1,812 linhas TRACE, com codex_api::endpoint::responses_websocket (3.5MB+) e codex_api::sse::responses entre os principais alvos TRACE
    • Comportamento esperado: com RUST_LOG=warn, logs TRACE internos/de dependências e payloads volumosos não deveriam ser armazenados persistentemente

Riscos adicionais e medidas paliativas temporárias

  • Risco de perda de dados

    • Se o disco encher, um reboot pode impedir o login no Linux
    • O modo /goal do Codex pode tentar liberar espaço em disco apagando arquivos/pastas, o que pode causar perda de dados

  • Scripts temporários de mitigação

    • trim-codex-wal.sh, que reduz o WAL em execução usando PRAGMA wal_checkpoint(TRUNCATE), podendo ser executado a cada 15 minutos via cron
    • fix-codex-wal.sh, que apaga os arquivos de log/WAL e envia SIGTERM → SIGKILL para processos relacionados ao Codex para liberar espaço imediatamente
    • Também é possível adicionar um gatilho SQLite (block_log_inserts) para ignorar inserções na tabela logs, interrompendo o crescimento do WAL; para reverter, use DROP TRIGGER IF EXISTS block_log_inserts
      • Como VACUUM regrava o banco, ele pode causar uma grande escrita única em arquivos grandes; por isso, recomenda-se primeiro adicionar o trigger, confirmar que o crescimento do WAL parou, e só então executar DELETE/VACUUM
      • Como isso altera um schema privado do SQLite, futuras atualizações/migrações do Codex podem recriar tabelas, remover o trigger etc.
    • Até sair uma correção permanente, também foi sugerido colocar esse banco em um ramdisk para evitar desgaste do SSD

Resolução e encerramento

  • Em 22 de junho de 2026, a mesclagem de dois PRs reduziu os logs em cerca de 85%, e o issue foi marcado como concluído
    • Interrupção do logging de todos os eventos de Responses WebSocket (#29432)
    • Filtragem de alvos ruidosos nos logs persistentes (#29457)
  • Um patch proposto separadamente troca o TRACE global por armazenamento padrão em INFO+, elevando codex_otel.log_only, codex_otel.trace_safe, hyper_util, log e opentelemetry_sdk para WARN+
  • As correções foram lançadas em rust-v0.142.0

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Comentários do Hacker News

  • Codex me parece um dos casos mais infames de slopware
    No macOS, só de deixar a janela visível ele usa 100% da GPU para exibir a mensagem do spinner
    100% da GPU em um MBP M5 só por causa da mensagem do spinner, e os ventiladores ficam girando forte durante boa parte do tempo de espera pelo modelo, então é bom tomar cuidado ao usar na bateria
    Esse problema está no GitHub há quase 6 meses e provavelmente existe desde que lançaram essa tranqueira feita com vibe coding
    Mesmo que eu quisesse corrigir, por algum motivo não dá, porque é código fechado
    Há muito debate sobre qual modelo é melhor e se vibe coding funciona, mas esse parece ser o nível do que uma das empresas com mais dinheiro, gente e capacidade de modelo consegue fazer com vibe coding
    Quando o CEO já declarou que a empresa está “focada em programação”, um erro grave desses parece sinal de que há algo realmente quebrado internamente, e no Polymarket quase ninguém acha que a OpenAI vai lançar tão cedo um modelo líder
    É trágico, porque o mundo precisa de um concorrente para a Anthropic

    • O Claude Code também está bem ao lado, então não pode ficar de fora dos exemplos de slopware
    • Se a IA realmente entrega produtividade 10x e está perto de AGI ou ASI, não entendo como produtos como Codex ou Claude Code CLI ainda conseguem ser tão ruins
      Parece que a “revolução da IA agêntica” já deveria ter resolvido esse tipo de problema
      Espero que internamente eles não estejam dizendo “estamos processando, aguarde” ou “essa tarefa é difícil demais”
    • Quando eu trabalhava numa organização que deixava praticamente tudo em código aberto, havia só um motivo para manter algo fechado, inclusive projetos paralelos: vergonha
      Ninguém quer ser a cara pública de uma base de código horrível
      E se você ainda estiver usando esse código para justificar preços absurdos, esse peso deve ser triplicado
    • Não é só o Codex: o app do ChatGPT no macOS também chega a consumir 60 GB de RAM com o passar das horas e mata todos os outros apps
      Não faz sentido
      Mesmo tentando usar o Google AI Studio no navegador, ele consome 100% da CPU
      Dá vontade de achar que vou ter de transformar tudo em app nativo
    • No começo diziam que o mundo precisava da Anthropic como concorrente do ChatGPT, e agora a situação deu uma volta completa

  • Publicaram no X uma solução temporária para esse problema[1]
    sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"
    Além disso, ao executar VACUUM FULL nesse arquivo sqlite em um notebook, ele caiu de 27 GB para 73 MB[2]
    [1]: https://xcancel.com/bdsqlsz/status/2067964486615810369
    [2]: https://xcancel.com/jeethu/status/2068087449469780434

    • Mais uma vez, uma regra no nível do banco de dados salvando o dia
    • A solução real é parar de usar isso e migrar para Pi

  • Todo mundo está criticando a OpenAI, e com razão, mas vale lembrar que, ao contrário do Claude Code, o Codex é oficialmente customizável: https://github.com/openai/codex
    Também é bem fácil de aplicar patch

    • Isso é o CLI, não o app Codex proprietário de que estão falando aqui

  • Chocante
    Já faz uma semana que a issue foi aberta e, pelo que vejo, a OpenAI simplesmente está em silêncio
    Eu achava que fornecedores desse tipo seriam extremamente sensíveis a esse tipo de problema, então não entendo
    Presumivelmente eles já devem ter vários agentes monitorando issues em potencial no GitHub e propondo correções, certo? …Certo?
    Fazer as próprias ferramentas corrigirem issues do GitHub em tempo real deveria ser algo trivial a essa altura

    • A OpenAI parece bem fraca para corrigir issues
      Meu exemplo favorito é a #2472: fizeram uma demonstração no palco do lançamento do GPT-5 dizendo que estava “corrigida”, mas o ticket continua aberto e essa “correção” nem foi incorporada
      O post original apontando isso é https://blog.tymscar.com/posts/openaiunmergeddemo/ e a issue é https://github.com/openai/openai-python/issues/2472
    • Havia uma issue no GitHub sobre esse mesmo problema desde abril
      Eu uso bastante o Codex e estou muito satisfeito com o desempenho dele (UX e saída), mas é difícil entender por que esse problema ainda não foi corrigido

  • Esse problema parece ter sido corrigido[0] e deve entrar na próxima versão
    [0] https://github.com/openai/codex/commit/e98d43ac372ddf7f513c0...

  • Vibe coding leva o “mova-se rápido e quebre tudo” a um nível completamente diferente

    • Neste exato momento, na nossa empresa, estamos segurando uma grande indisponibilidade porque a porcaria feita com vibe coding de alguém deu muito errado
    • Já está faltando coisa para quebrar
    • Se não houver dívida técnica, vibe coding costuma ser útil para prototipagem
      Em produto real, engenheiros de software de verdade nunca serão substituídos

  • Um pouco fora do assunto, mas essas empresas precisam parar de sujar a raiz do repositório com Claude.md ou copilot.md
    Deviam se juntar de uma vez e definir uma estrutura de pasta conhecida, como docs/llm/*

  • No fim do ano passado, quando o Claude Code estava um desastre por causa da latência, a OpenAI deixou escapar uma vitória quase garantida
    Hoje em dia, o Codex já começa com atraso na digitação desde o início, enquanto o Claude Code, embora às vezes trave, no geral quando eu aperto uma tecla ele… literalmente… mostra o que eu digitei

    • No meu caso é exatamente o contrário
    • Sinto que o Claude Code está quase inutilizável
      Sempre preciso digitar no neovim quando vou escrever mais do que algumas palavras

  • Isso na verdade é um erro bem típico
    Lançaram com logs de rastreamento/depuração ativados para tudo, mas o engraçado é que o impacto não aparece do jeito tradicional
    Antigamente, um desenvolvedor ativava logging em nível trace, o app ficava catastroficamente lento e isso era corrigido já na atualização seguinte; agora memória, CPU e disco ficaram tão absurdamente rápidos que chegamos num ponto em que isso já não se revela de forma tão imediata, o que é insano

    • Também contribui o fato de que o trabalho agêntico acontece no lado do servidor, então aparentemente tudo bem se um cliente leve devorar recursos locais

  • Queria que alguém doasse alguns tokens para essa valente startup. Parece que eles estão precisando de ajuda