Bug no OpenAI Codex gera gravações excessivas em SSDs e levanta alerta sobre desgaste de hardware
A OpenAI reconheceu um problema sério no Codex: uma falha na forma como o sistema registra logs locais em SQLite vem provocando um volume desproporcional de gravações em SSDs. Na prática, a ferramenta de programação baseada em IA estava escrevendo dados de diagnóstico em uma intensidade muito maior do que o necessário, levantando preocupações reais sobre desgaste acelerado do hardware de desenvolvedores que utilizam o Codex em suas máquinas.
Para entender a gravidade do caso, é importante lembrar que SSDs têm vida útil limitada, normalmente expressa em TBW (terabytes written, ou terabytes gravados). Esse índice indica, de forma aproximada, quanto dado pode ser escrito em uma unidade antes de aumentar de forma significativa o risco de degradação, perda de desempenho ou falhas definitivas. Embora o valor de TBW varie bastante conforme o modelo, a capacidade e o fabricante, qualquer padrão de escrita contínua e desnecessária pode consumir rapidamente uma fatia relevante dessa margem projetada.
O alerta ganhou visibilidade após a abertura de um relatório de bug no repositório do agente de programação Codex. Já no título do issue, a situação parecia preocupante: os logs de feedback em SQLite poderiam chegar a cerca de 640 TB de dados escritos por ano, um volume capaz de comprometer rapidamente a resistência de SSDs de uso comum em estações de trabalho de desenvolvimento.
Um dos relatos mais detalhados foi o do desenvolvedor Rui Fan, membro do comitê de gerenciamento do projeto Apache Flink. Ele observou que, após aproximadamente 21 dias de uptime contínuo, o SSD principal de sua máquina já havia acumulado cerca de 37 TB de dados gravados. Uma análise mais aprofundada, olhando processos e arquivos específicos, indicou que os logs em SQLite gerados pelo Codex eram o principal responsável por essa escrita constante em disco.
Ao extrapolar esse ritmo para um período de 12 meses, chega-se ao número alarmante de aproximadamente 640 TB de dados gravados em um único ano. Em um SSD de 1 TB, isso equivaleria, em termos simplificados, a cerca de 640 ciclos completos de gravação da unidade. Considerando que muitos SSDs de consumo são vendidos com garantia de resistência na casa de 600 TBW, esse comportamento isolado poderia, sozinho, consumir praticamente toda a endurance coberta pela garantia em menos de um ano de uso intenso do Codex.
Isso não significa, porém, que todos os usuários experimentarão exatamente o mesmo nível de desgaste. A extensão do problema depende de uma combinação de fatores: frequência de uso do Codex, tipo e modelo do SSD, capacidade da unidade, configuração do ambiente de desenvolvimento, tempo de atividade contínua, além do volume de logs efetivamente gerado pela ferramenta em cada cenário. Ainda assim, o episódio evidencia um risco operacional relevante ligado a ferramentas de IA executadas localmente, especialmente em ambientes de desenvolvimento onde o software pode ficar rodando por longos períodos.
Outro desenvolvedor que participou da discussão fez uma análise curiosa: usando o próprio Codex para avaliar o uso de disco, ele estimou que o bug teria consumido o equivalente a US$ 38,64 da vida útil de um SSD Samsung 990 NVMe de 2 TB. Segundo esse usuário, uma projeção elaborada também com apoio do Codex sugeria que, no período de março a junho, a regressão poderia ter gerado um consumo de endurance acumulado equivalente a alguns milhões de dólares entre todos os usuários afetados.
Essa conta parte de um raciocínio econômico relativamente simples: calcula-se o custo por terabyte gravado dividindo o preço de compra do SSD pela resistência nominal em TBW informada pelo fabricante. Assim, quanto mais dados forem escritos sem necessidade, maior será a fatia proporcional da vida útil “queimada” por uma determinada aplicação. Em um dos exemplos citados no texto original, um SSD de 1 TB com preço de US$ 200 e resistência de 600 TBW teria um custo estimado de cerca de US$ 0,333 por terabyte gravado. Nessa lógica, os 37 TB observados por Rui Fan representariam aproximadamente US$ 12,33 em desgaste proporcional do dispositivo.
SSDs de maior capacidade e classificados para volumes mais altos de TBW tendem a apresentar custo menor por terabyte escrito. Um modelo de 2 TB com resistência de 1.200 TBW, por exemplo, dilui melhor o impacto econômico de cada gravação adicional. Mesmo assim, o ponto central permanece inalterado: nenhuma ferramenta de software deveria gerar, de forma silenciosa, um fluxo de escrita tão intenso e contínuo a ponto de comprometer a durabilidade de componentes físicos dos usuários, especialmente quando falamos de armazenamento primário em estações de trabalho profissionais.
A falha em questão está associada aos logs de diagnóstico gravados localmente, e não diretamente à telemetria enviada para a OpenAI. Em dezembro de 2025, os desenvolvedores do Codex já tinham anunciado planos para incluir telemetria por padrão na CLI da ferramenta, exceto em localidades onde esse tipo de coleta fosse proibida por legislação. O incidente atual, no entanto, diz respeito a registros que ficam armazenados apenas na máquina do usuário e que deveriam servir exclusivamente para ajudar engenheiros da empresa a investigar problemas técnicos de forma mais eficiente.
Esses logs permanecem na máquina local por padrão e só são compartilhados caso o próprio usuário opte por incluir esses arquivos em um relatório de feedback. O que não estava previsto é que, em alguns ambientes, os registros fossem gerados em volume tão alto, resultando em atividade de disco desnecessariamente intensa. Segundo a OpenAI, os dados armazenados tinham finalidade diagnóstica legítima, mas o padrão de escrita adotado acabou causando muito mais operações de entrada e saída (I/O) do que o antecipado durante o desenho da funcionalidade.
Um porta-voz da empresa confirmou que a equipe de engenharia está ciente do problema e trabalha na implementação de correções. Alterações recentes no código, visíveis em pull requests ligados ao projeto, mostram esforços para ajustar o comportamento dos logs, reduzir a frequência das gravações e limitar o volume total de dados persistidos em disco. Ainda assim, alguns usuários continuaram a relatar sintomas de atividade anormal em SSDs após as primeiras correções, o que indica que as tentativas de mitigação ainda precisam ser validadas em uma variedade maior de ambientes e sistemas operacionais.
A origem desse comportamento anômalo parece estar ligada à combinação de três fatores: um nível muito detalhado de logging por padrão, o uso de SQLite de forma síncrona (forçando escrita constante em disco) e a ausência de mecanismos robustos de rotação ou expiração de logs. Em outras palavras, o sistema foi configurado para registrar praticamente tudo, o tempo todo, gravando cada evento diretamente em arquivo, sem um limite claro de tamanho ou de tempo de retenção. Em máquinas que permanecem ligadas e executando o Codex por dias ou semanas, esse padrão se traduz em um volume cumulativo de escrita extremamente elevado.
O caso levanta um debate mais amplo sobre boas práticas de logging em ferramentas de desenvolvimento guiadas por IA. É comum que, em versões iniciais de produtos, equipes optem por registros muito detalhados para facilitar a depuração de falhas e o monitoramento de comportamento inesperado. Porém, quando esses mesmos padrões chegam a um público mais amplo, sem ajustes de nível de log, compressão ou rotação automática, acabam introduzindo riscos que vão além de simples problemas de desempenho – como, por exemplo, a redução real da vida útil de hardware sensível, como SSDs.
Para desenvolvedores e equipes de TI, o episódio funciona como lembrete prático de que monitorar o “Total Bytes Written” de seus SSDs pode ser tão importante quanto acompanhar CPU e memória. Ferramentas de sistema e utilitários dos próprios fabricantes costumam expor contadores de gravação acumulada, permitindo identificar comportamentos anômalos, como um aumento repentino de writes após a instalação de uma nova versão de software. Em ambientes corporativos, isso pode orientar decisões sobre políticas de atualização, uso de máquinas dedicadas para testes e até a adoção de unidades com maior resistência para workloads de desenvolvimento intensivo.
Também é uma oportunidade para repensar como times de engenharia configuram logs por padrão. Em muitos casos, faz sentido definir níveis de log mais conservadores para usuários finais (por exemplo, “warning” ou “error”), deixando o modo “debug” ou “trace” apenas para cenários específicos de diagnóstico, por tempo limitado. Outro cuidado essencial é implementar rotação de arquivos, compressão e limites de tamanho, evitando que bancos de dados de log cresçam indefinidamente ou que pequenas operações de debug resultem em centenas de gigabytes de escrita ao longo de alguns meses.
Do ponto de vista da OpenAI, o incidente reforça a necessidade de alinhar práticas de observabilidade com a responsabilidade sobre o impacto físico de seus produtos em hardware de terceiros. Ferramentas baseadas em IA tendem a ser intensivas em processamento e I/O, seja pela manipulação de grandes volumes de código, seja pela interação constante com modelos remotos. Quando somado a mecanismos de logging agressivos, esse perfil pode transformar máquinas comuns de desenvolvimento em ambientes de stress permanente para componentes como SSDs.
Para os usuários do Codex, a recomendação imediata é acompanhar as atualizações da ferramenta, ler atentamente as notas de versão e, quando possível, revisar configurações relacionadas a logs locais. Em ambientes críticos, pode ser prudente isolar o uso do Codex em máquinas ou partições específicas, preferindo SSDs com maior TBW e monitorando periodicamente o total de gravações. Em casos extremos, a simples desativação temporária de certos tipos de logs, quando possível, já pode reduzir significativamente o volume de I/O.
Por fim, o episódio evidencia um ponto-chave: mesmo em um contexto dominado por software e inteligência artificial, o limite físico do hardware continua sendo uma variável que não pode ser ignorada. Projetar ferramentas mais inteligentes também significa projetar sistemas mais conscientes do impacto que causam em recursos como armazenamento e energia. O bug no Codex não é apenas uma curiosidade técnica; é um alerta de que decisões aparentemente inofensivas de engenharia – como o nível de detalhe de um log – podem ter consequências diretas na conta bancária e na infraestrutura de quem depende dessas soluções no dia a dia.