- Un fallo en el registro de diagnóstico de la CLI de Codex genera hasta 640 TB de escrituras anuales.
- El origen del problema reside en una configuración de nivel TRACE en bases de datos SQLite locales.
- Un SSD estándar de 1 TB podría agotar su garantía de funcionamiento en menos de un año debido a este bug.
- Aunque existe una actualización parcial, se recomienda redirigir los logs a la memoria RAM como medida preventiva.
Si eres de los que utiliza la herramienta de línea de comandos de OpenAI Codex para agilizar tus sesiones de programación, es muy probable que te hayas llevado una sorpresa desagradable sin ni siquiera saberlo. Lo que parecía una ayuda inestimable para el desarrollo de software se ha revelado como una auténtica apisonadora para las unidades de estado sólido (SSD), debido a un patrón de escritura tan agresivo que pone en jaque la durabilidad física del hardware en un tiempo récord.
La voz de alarma saltó en la comunidad de GitHub cuando el usuario 1996fanrui documentó un comportamiento errático tras observar que su equipo trabajaba a destajo sin motivo aparente. Tras investigar las tripas del sistema, se descubrió que Codex estaba escribiendo registros de diagnóstico sin descanso en una base de datos SQLite local. Los datos son para echarse a temblar: en apenas 21 días de actividad, la unidad había soportado unos 37 TB de escrituras, lo que extrapolado a un año natural supondría una carga de trabajo cercana a los 640 terabytes.
El origen técnico de la tormenta de datos en SQLite
El culpable de este despropósito no es otro que un ajuste de registro que, seguramente por un despiste de ingeniería, llegó a los usuarios finales activado en su máxima potencia. El sistema de retroalimentación de Codex funciona por defecto en nivel TRACE, que es básicamente el modo más ruidoso y detallado posible, registrando desde eventos cotidianos del sistema de archivos hasta cargas útiles de WebSocket totalmente innecesarias para el usuario común.
Lo que agrava la situación es que el programa parece hacer oídos sordos a las configuraciones estándar que solemos usar los desarrolladores, ya que ignora la variable de entorno RUST_LOG. Esto significa que no hay una forma sencilla o evidente de bajarle el volumen a esa avalancha de anotaciones que, en un 71%, no son más que ruido de fondo sin utilidad diagnóstica real para quienes no trabajamos directamente en el núcleo de OpenAI.
Además, no se trata solo de que el archivo de logs crezca, sino de cómo lo hace. La base de datos realiza decenas de miles de operaciones de inserción y borrado por minuto, lo que provoca un fenómeno de amplificación de escritura. Esto significa que el desgaste físico en las celdas de memoria del SSD es mucho mayor de lo que el tamaño final del archivo pueda dar a entender, machacando el disco de forma silenciosa pero constante.
Un riesgo real para la garantía y salud de tu hardware
Para poner estas cifras en perspectiva, conviene recordar que un SSD doméstico de 1 TB suele tener una vida útil garantizada de unos 600 TBW (terabytes escritos). Con el ritmo de escritura que impone este bug de Codex, agotaremos la garantía de la unidad en menos de doce meses, algo que resulta inaceptable para cualquier herramienta de productividad profesional. No es solo una cuestión de espacio en disco, sino de dinero y fiabilidad a largo plazo.
Este problema ha puesto en alerta especialmente a startups y equipos de desarrollo que dependen de la automatización, donde Codex puede estar ejecutándose en segundo plano durante jornadas maratonianas. En entornos donde el disco se llena por completo, se han reportado fallos críticos en el inicio del sistema, especialmente en Linux, dejando a los desarrolladores bloqueados hasta que consiguen purgar manualmente los archivos de la carpeta ~/.codex de forma externa.
Parches oficiales y trucos para salvar el disco
Tras el revuelo montado, OpenAI ha movido ficha lanzando la versión 0.142.0 de Codex, la cual promete reducir la actividad del log persistente en un 85% al filtrar telemetría duplicada y eliminar ciertos eventos de WebSocket. Sin embargo, la comunidad técnica advierte de que el problema no está solucionado al 100%, ya que en sistemas Windows todavía se han detectado restos de ese ruido TRACE tan perjudicial en versiones recientes del software.
Mientras llega una corrección definitiva, los usuarios de Linux y macOS han encontrado un atajo muy inteligente: crear un enlace simbólico del archivo de logs hacia la carpeta /tmp/. Al hacer esto, todas las escrituras masivas se redirigen a la memoria RAM del equipo, que se vacía automáticamente al reiniciar. Como este archivo no guarda información vital ni conversaciones, perderlo no supone ningún drama y nos permite seguir trabajando sin miedo a que nuestro SSD pase a mejor vida antes de tiempo.
Estamos ante un recordatorio de que, a veces, la velocidad a la que evoluciona la inteligencia artificial deja atrás detalles de optimización básica que pueden salirnos muy caros. Es fundamental que quienes utilicen la CLI de Codex de forma intensiva vigilen de cerca la salud de sus unidades de almacenamiento y apliquen estas medidas preventivas, ya que delegar ciegamente en estas herramientas puede terminar pasando factura al componente más delicado de nuestro ordenador de trabajo.
