OpenAI Codex presenta un error que podría estropear su SSD en menos de un año

Si utiliza la CLI de Codex de OpenAI y la deja en ejecución durante largos periodos de tiempo, es posible que su SSD se vea sometido a una carga excesiva.

Un usuario de GitHub llamado 1996fanrui documentó el problema el 14 de junio tras observar una actividad del disco inusualmente elevada en su equipo. Tras investigar un poco, descubrió que Codex estaba sobrecargando continuamente una base de datos SQLite local (almacenada en ~/.codex/logs_2.sqlite) con escrituras de registros de diagnóstico. Durante 21 días de funcionamiento, la unidad había registrado alrededor de 37 TB de escrituras. A anualizar, eso supone aproximadamente 640 terabytes al año. Un SSD de consumo típico de 1 TB tiene una vida útil nominal de unos 600 TBW, por lo que este error, de no corregirse, podría agotar toda la resistencia garantizada de su unidad en menos de un año.

El culpable es una configuración de registro que probablemente nadie tenía intención de hacer llegar a los usuarios finales. El canal de retroalimentación SQLite de Codex se ejecuta, por defecto, en el nivel global TRACE —la configuración que genera más ruido—. Registra todo, desde cargas útiles sin procesar de WebSocket hasta eventos cotidianos del sistema de archivos, como la apertura de «passwd» y «ld.so.cache». Además, ignora la variable de entorno estándar RUST_LOG, por lo que no hay una forma obvia de desactivarlo. Alrededor del 71 % de los datos registrados son ruido de nivel TRACE que no tiene una finalidad diagnóstica real, al menos para el usuario medio.

Lo que empeora la situación es la amplificación de escritura. La base de datos no solo está creciendo, sino que además realiza decenas de miles de operaciones de inserción y eliminación por minuto. Físicamente, está escribiendo en la unidad mucho más de lo que el tamaño del archivo sugiere.

De hecho, se trata de un problema conocido en diversas formas desde, al menos, abril, con múltiples informes relacionados presentados a lo largo del año. El reciente registro de cambios de OpenAI mencionó algunas correcciones de fiabilidad de SQLite, pero no ha abordado el problema de la tasa de escritura. La cuestión sigue sin resolverse.

Mientras tanto, Linux y macOS pueden crear un enlace simbólico de «~/.codex/logs_2.sqlite» a «/tmp/» para redirigir las escrituras a la RAM. El archivo no contiene datos de conversación, por lo que no supone ningún problema perderlo al reiniciar el sistema.