Un bug de logging en Codex puede provocar escrituras de varios TB en el SSD local y desgastar rápidamente su vida útil

 (github.com/openai)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Codex escribe de forma continua grandes volúmenes de datos en la base de datos de logs de feedback SQLite local, y en un entorno de un usuario se registraron unos 37TB en el SSD principal tras 21 días de funcionamiento
  • Extrapolado, esto equivale a unos 640TB al año, o alrededor de 640 escrituras completas de una unidad de 1TB por año, lo que podría agotar en menos de un año la vida útil garantizada de algunos SSD de consumo (aprox. 600 TBW)
  • Aunque solo se conservan unas 500 mil filas, el contador AUTOINCREMENT superó los 5.5 mil millones de ID, lo que deja una brecha de unas 10 mil veces entre las filas retenidas y los ID insertados acumulados
  • La causa es que el sink de sincronización de logs de feedback de SQLite está configurado con el valor global predeterminado TRACE (Targets::new().with_default(Level::TRACE)), por lo que persiste tanto logs internos de dependencias como payloads raw de protocolo de gran tamaño
  • El issue se cerró después de que el 22 de junio de 2026 se fusionaran dos PR, bloqueando alrededor del 85% de los logs

Síntomas principales y alcance del impacto

  • Codex genera escrituras continuas y voluminosas en los siguientes archivos
    • ~/.codex/logs_2.sqlite
    • ~/.codex/logs_2.sqlite-wal
    • ~/.codex/logs_2.sqlite-shm
  • Tras 21 días de funcionamiento, se registraron unos 37TB en el SSD principal, y al revisar por proceso/archivo se confirmó que el log SQLite de Codex era una de las principales fuentes de escritura sostenida
  • Esto equivale a unos 640TB al año, es decir, alrededor de 640 escrituras completas de la unidad por año en un SSD de 1TB
  • Algunos SSD de consumo tienen una clasificación de alrededor de 600 TBW, por lo que su vida útil de escritura garantizada podría agotarse en menos de un año

Datos de evidencia

  • Evidence1 — amplificación de escritura (write amplification)

    • Tamaño actual del archivo logs_2.sqlite: 1.2 GiB
    • Filas retenidas actualmente: 506,149
    • row id acumulado asignado: 5,543,677,486
    • Hay una brecha de unas 10 mil veces entre las filas retenidas (aprox. 0.5M) y los ID insertados acumulados (5.5 mil millones+), lo que sugiere más de 10TB de churn histórico de logs incluso sin contar WAL, índices, pruning, checkpoints, reescritura de páginas y amplificación a nivel de dispositivo

  • Evidence2 — distribución por nivel/target

    • 681,774 filas retenidas, con un contenido de logs retenidos estimado en unos 1,035.6 MiB
    • Proporción por nivel: TRACE 70.7%, INFO 25.7%, DEBUG 3.0%, WARN 0.6%
    • Principales 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
    • Las principales fuentes son, en su mayoría, logs TRACE globales, logs de telemetría espejados y registro de payloads raw de websocket/SSE
    • codex_otel.log_only + codex_otel.trace_safe representan además 25.3%, y si se filtran esas categorías se podría eliminar alrededor del 96% de los bytes de logs retenidos en la muestra
    • La fuente TRACE más frecuente (target=log) incluye muchos elementos de bajo nivel como inotify event (por ejemplo ld.so.cache 128,764 veces), llamadas internas de tokio-tungstenite y WouldBlock

  • Medición de la amplificación de escritura

    • En una muestra de 15 segundos, las filas retenidas permanecieron en 681,774, pero se insertaron unas 36,211 filas
    • La amplificación de escritura se produce por un patrón repetido de insert-and-prune de insertar → indexar → escribir en WAL → podar

Causa estimada

  • El sink de logs de feedback SQLite se instala con el valor global predeterminado TRACE (Targets::new().with_default(Level::TRACE))
  • Como resultado, todos los targets se almacenan de forma persistente a nivel TRACE, incluyendo logs internos/de dependencias y payloads raw de protocolo de gran tamaño

Dirección de corrección propuesta

  • Mantener los logs de feedback, pero reducir el alcance del almacenamiento persistente por defecto
    • No usar TRACE global en el sink de logs de feedback SQLite
    • Subir el umbral o eliminar ruido de poco valor como target=log, hyper_util, internals de tokio-tungstenite, spam de inotify y logs de bajo nivel de OpenTelemetry SDK
    • En vez de guardar payloads completos de websocket/SSE raw, almacenar resúmenes (tipo de evento, tiempo consumido, éxito/fracaso, uso de tokens y longitud en bytes del payload)
    • Evitar guardar eventos espejados de codex_otel.log_only / codex_otel.trace_safe, salvo cuando sean útiles para debugging
    • Como un límite por hilo no basta, agregar un límite global de tamaño/escritura para la DB de logs
  • Una opción como sqlite_logs_enabled = false también sería útil, pero la solución principal es un mejor filtrado por defecto

Reportes de reproducción en múltiples plataformas

  • macOS

    • En un entorno macOS 15.7.7 / Codex 26.616.51431, logs_2.sqlite tenía 113M, MAX(id)=34,277,360, 31,405 filas retenidas, y en dos muestras de 60 segundos se confirmaron unas 60 escrituras por segundo
    • También se reportó un caso donde el proceso codex escribió unos 50GB durante una sesión de 1 a 2 horas

  • Windows

    • En Codex Desktop para Windows (codex.exe app-server --analytics-default-enabled), se siguieron insertando filas TRACE aunque no había RUST_LOG=warn ni una configuración explícita de trace
    • Unas 71k filas retenidas, y el valor logs de sqlite_sequence superaba los 18.5 millones, lo que indica abundante churn histórico de insert/prune
    • En una distribución de 10 minutos hubo 1,812 filas TRACE, y entre los principales targets TRACE estaban codex_api::endpoint::responses_websocket (3.5MB+) y codex_api::sse::responses
    • Comportamiento esperado: con RUST_LOG=warn, no deberían almacenarse de forma persistente TRACE internos/de dependencias ni payloads grandes

Riesgos adicionales y mitigaciones temporales

  • Riesgo de pérdida de datos

    • Si el disco se llena, reiniciar podría impedir el inicio de sesión en Linux
    • El modo /goal de Codex puede intentar liberar espacio en disco borrando archivos/carpetas, lo que podría causar pérdida de datos

  • Scripts temporales de mitigación

    • trim-codex-wal.sh, que recorta el WAL en ejecución usando PRAGMA wal_checkpoint(TRUNCATE), y puede ejecutarse cada 15 minutos con cron
    • fix-codex-wal.sh, que elimina archivos de log/WAL y luego envía SIGTERM→SIGKILL a procesos relacionados con Codex para recuperar espacio en disco de inmediato
    • Si se agrega un trigger de SQLite (block_log_inserts) para ignorar inserciones en la tabla logs, el crecimiento del WAL se detiene; para revertirlo, usar DROP TRIGGER IF EXISTS block_log_inserts
      • Como VACUUM reescribe la DB, puede provocar una gran escritura puntual en archivos grandes, por lo que se recomienda ejecutar DELETE/VACUUM después de agregar el trigger y confirmar que el crecimiento del WAL se detuvo
      • Como modifica un esquema SQLite privado, futuras actualizaciones/migraciones de Codex podrían recrear tablas, eliminar el trigger, etc.
    • Hasta que llegue una corrección permanente, también se sugiere poner esa DB en un ramdisk para evitar daño al SSD

Resolución y cierre

  • El 22 de junio de 2026, la fusión de dos PR redujo los logs en aproximadamente 85%, y con eso el issue se dio por resuelto
    • Se dejó de registrar todos los eventos de Responses WebSocket (#29432)
    • Se filtraron targets ruidosos en los logs persistentes (#29457)
  • Un parche propuesto por separado cambia el almacenamiento predeterminado de TRACE global a INFO+, y sube a WARN+ categorías como codex_otel.log_only, codex_otel.trace_safe, hyper_util, log y opentelemetry_sdk
  • Los cambios se publicaron en rust-v0.142.0

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Opiniones en Hacker News

  • Codex me parece uno de los ejemplos más notorios de slopware
    En macOS, con solo dejar visible la ventana, usa 100% de la GPU para mostrar el mensaje del spinner
    Solo el mensaje del spinner lleva la GPU al 100% en una MBP M5, y como los ventiladores suenan fuerte durante la mayor parte del tiempo de espera del modelo, hay que tener cuidado al usar batería
    Este issue lleva casi 6 meses en GitHub, y probablemente viene desde que lanzaron este montón de cosas hecho con vibe coding
    Aunque uno quisiera arreglarlo por su cuenta, no se puede porque, por alguna razón, es código cerrado
    Se discute mucho qué modelo es mejor y si el vibe coding es viable, pero este parece ser el nivel de lo que puede hacer con vibe coding una de las empresas con más financiamiento, personal y capacidad de modelos
    Con el CEO diciendo ya que están “enfocados en programar”, errores tan graves como este parecen una señal de que algo está realmente roto dentro de la empresa, y en Polymarket casi nadie cree ya que OpenAI vaya a sacar pronto un modelo líder
    Es trágico, porque el mundo necesita un competidor de Anthropic

    • Claude Code también está justo al lado, así que no debería quedar fuera como ejemplo de slopware
    • Si la IA da una productividad 10x y está cerca de AGI o ASI, no entiendo cómo productos como Codex o Claude Code CLI pueden seguir siendo tan malos
      Uno pensaría que la “revolución de la IA agéntica” ya debería haber resuelto este tipo de problemas
      Supongo que internamente no han de estar diciendo “estamos procesando, por favor espera” o “la tarea es demasiado difícil”
    • Cuando trabajaba en una organización donde básicamente todo se publicaba como open source, incluyendo proyectos paralelos, solo había una razón para dejar algo como cerrado: vergüenza
      Nadie quiere ser la cara pública de una base de código basura
      Y si además estás usando ese código para justificar precios absurdos, la carga debe sentirse triple
    • No es solo Codex: la app de ChatGPT en macOS también, si la dejas abierta unas horas, termina usando 60 GB de RAM y mata todas las demás apps
      No lo entiendo
      Incluso si intento usar Google AI Studio en el navegador, se va al 100% de CPU
      Al final dan ganas de hacer todo como apps nativas
    • Al principio se decía que el mundo necesitaba a Anthropic como competidor de ChatGPT, y ahora ya dimos la vuelta completa

  • En X subieron una solución temporal para este problema[1]
    sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"
    Además, en una laptop, al ejecutar VACUUM FULL sobre ese archivo sqlite, bajó de 27 GB a 73 MB[2]
    [1]: https://xcancel.com/bdsqlsz/status/2067964486615810369
    [2]: https://xcancel.com/jeethu/status/2068087449469780434

    • Una vez más, las reglas a nivel de base de datos salvan el día
    • La solución real es dejar de usarlo y pasarse a Pi

  • Todos están criticando a OpenAI, y con razón, pero vale la pena recordar que, a diferencia de Claude Code, Codex sí se puede personalizar oficialmente: https://github.com/openai/codex
    También es bastante fácil de parchear

    • Ese es el CLI, no la app propietaria de Codex de la que se está hablando aquí

  • Qué fuerte
    El issue lleva una semana abierto y, por lo que veo, OpenAI simplemente sigue en silencio
    Yo pensaba que este tipo de vendedores sería extremadamente sensible a problemas así, así que no lo entiendo
    Obviamente deben tener varios agentes monitoreando posibles issues en GitHub y proponiendo arreglos, ¿no? …¿no?
    Hacer que sus propias herramientas arreglen issues de GitHub en tiempo real debería ser algo trivial

    • OpenAI parece bastante flojo para corregir issues
      Mi ejemplo favorito es el #2472: en el lanzamiento de GPT-5 hicieron una demo diciendo que lo habían “arreglado”, pero el ticket sigue abierto y ese “arreglo” ni siquiera se ha fusionado
      La publicación original que señala esto es https://blog.tymscar.com/posts/openaiunmergeddemo/ y el issue es https://github.com/openai/openai-python/issues/2472
    • Había un issue en GitHub sobre este mismo problema desde abril
      Uso bastante Codex y estoy muy satisfecho con el rendimiento (UX y resultados), pero cuesta entender que todavía no hayan arreglado esto

  • Este problema parece haber sido corregido[0], y probablemente entre en la próxima versión
    [0] https://github.com/openai/codex/commit/e98d43ac372ddf7f513c0...

  • El vibe coding lleva el “muévete rápido y rompe cosas” a un nivel totalmente distinto

    • Justo ahora en nuestra empresa estamos lidiando con una gran caída porque la basura hecha con vibe coding de alguien salió terriblemente mal
    • Ya casi no quedan cosas por romper
    • Si no hubiera deuda técnica, el vibe coding por lo general sí sirve para prototipar
      Pero en productos reales jamás va a reemplazar a un ingeniero de software de verdad

  • Un poco fuera de tema, pero estas empresas tienen que dejar de ensuciar la carpeta raíz del repositorio con Claude.md o copilot.md
    Deberían juntarse de una vez y acordar una estructura de carpetas conocida, como docs/llm/*

  • A finales del año pasado, cuando Claude Code estaba hecho un desastre por la latencia, OpenAI dejó escapar una victoria que casi tenía asegurada
    Hoy en día Codex tiene retraso al escribir desde que arranca, y Claude Code, aunque a veces se congela, por lo general cuando presiono una tecla… literalmente… aparece lo que tecleé

    • En mi caso es exactamente al revés
    • Siento que Claude Code es casi inutilizable
      Siempre tengo que escribir en neovim cuando son más de unas cuantas palabras

  • En realidad, este es un error bastante típico
    Lanzaron el producto con logs de trazas/depuración activados para todo, aunque curiosamente el impacto no aparece de la forma habitual
    Antes, un desarrollador activaba logging a nivel trace, la app se volvía catastróficamente lenta y lo arreglaban de inmediato en la siguiente actualización; pero ahora la memoria, la CPU y la velocidad de disco han mejorado tanto que ya llegamos a un punto donde no se manifiesta de esa manera tan evidente, y eso es una locura

    • También influye que el trabajo agéntico se haga del lado del servidor, así que pareciera que da igual que el cliente liviano se coma todos los recursos locales

  • Ojalá alguien le done unos tokens a esta valiente startup. Parece que los necesitan