Por Canuto  

Un problema reportado en Codex CLI de OpenAI estaría provocando un volumen anormal de escrituras sobre unidades SSD, hasta el punto de consumir en menos de un año la resistencia típica de un disco de consumo de TB 1 si el sistema permanece activo durante largos periodos.
***

  • Un usuario documentó cerca de TB 37 de escrituras en 21 días de actividad continua.
  • La causa sería un registro de diagnóstico en nivel TRACE global sobre una base SQLite local.
  • Como medida temporal, usuarios de Linux y macOS pueden redirigir el archivo de logs a /tmp/.

OpenAI Codex CLI quedó en el centro de una alerta técnica tras un reporte que apunta a un patrón de escrituras en disco inusualmente alto. El problema, si se mantiene sin corrección, podría acelerar de forma severa el desgaste de un SSD de consumo.

La advertencia surgió después de que un usuario de GitHub identificado como 1996fanrui documentara el comportamiento el 14 de junio. Según su hallazgo, Codex estaba escribiendo de forma constante registros de diagnóstico en una base de datos SQLite local ubicada en ~/.codex/logs_2.sqlite.

La relevancia del caso trasciende lo anecdótico porque toca un punto crítico de la infraestructura moderna. Muchas herramientas de IA para desarrolladores operan durante jornadas largas, procesos continuos o sesiones persistentes que pueden permanecer activas durante días o semanas.

En ese contexto, un sistema de registro mal configurado no solo ocupa espacio. También puede traducirse en un volumen real de escrituras físicas que reduce la vida útil de unidades de estado sólido, un componente cuya resistencia se mide en terabytes escritos a lo largo del tiempo.

Notebookcheck reportó que, durante 21 días de tiempo de actividad, la unidad analizada había absorbido cerca de TB 37 en escrituras. Llevado a una escala anual, ese ritmo equivaldría a unos TB 640 por año.

Qué se observó en el sistema y por qué preocupa

La cifra resulta especialmente delicada si se compara con la especificación de muchos SSD de consumo. Un modelo típico de TB 1 suele estar clasificado alrededor de TB 600 de vida útil garantizada en términos de TBW, o terabytes escritos.

Eso implica que, bajo ese patrón de uso, la resistencia teórica del disco podría agotarse en menos de un año. No significa que la unidad falle exactamente al alcanzar ese umbral, pero sí que entraría en una zona de desgaste mucho más acelerado.

El usuario que investigó el caso no se limitó a medir el tamaño del archivo de logs. También identificó que la base de datos estaba siendo golpeada constantemente por inserciones y eliminaciones en volúmenes muy altos.

Ese detalle es importante porque el tamaño visible del archivo no refleja por sí solo el desgaste total del disco. En almacenamiento flash, las escrituras internas pueden superar ampliamente lo que el usuario percibe como crecimiento neto de datos.

La situación encaja con un fenómeno conocido como amplificación de escrituras. En términos simples, el sistema puede terminar escribiendo físicamente mucho más de lo que parece, debido a cómo se actualizan bloques, índices y operaciones internas de la base de datos.

En el caso de Codex, el impacto no provendría de contenido valioso para el usuario final. Según la información citada por la publicación, cerca del 71% de los datos registrados corresponderían a ruido de nivel TRACE sin un propósito diagnóstico real para el usuario promedio.

El origen técnico del fallo en Codex CLI

El reporte atribuye el problema a una configuración de logging que no debió llegar así a usuarios finales. El sumidero de retroalimentación de SQLite de Codex se estaría ejecutando en nivel TRACE global por defecto, el ajuste más verboso posible.

Ese nivel de detalle hace que el sistema registre prácticamente todo. Entre los elementos capturados figuran cargas útiles crudas de WebSocket y eventos rutinarios del sistema de archivos, como la apertura de archivos como passwd y ld.so.cache.

Para un entorno de depuración muy específico, un registro tan exhaustivo puede tener sentido temporalmente. El problema aparece cuando ese comportamiento se mantiene activado por defecto en equipos de uso normal y durante sesiones prolongadas.

La situación se complica todavía más porque, según el mismo reporte, Codex ignoraría la variable de entorno estándar RUST_LOG. Eso elimina una vía habitual que desarrolladores y administradores usarían para reducir la verbosidad del sistema.

En otras palabras, el usuario no tendría una forma obvia e inmediata de bajar el nivel de logs sin aplicar soluciones alternativas. Esa falta de control contribuye a que el problema se vuelva persistente y difícil de mitigar por medios convencionales.

Desde una perspectiva operativa, este tipo de fallos puede pasar desapercibido por bastante tiempo. Un equipo puede seguir funcionando con aparente normalidad mientras el disco acumula escrituras intensivas en segundo plano.

Un problema conocido desde hace meses

De acuerdo con los detalles del caso, el problema sería conocido en distintas formas desde al menos abril. Además, se habrían presentado varios informes relacionados a lo largo del año.

Ese historial sugiere que no se trata de un incidente completamente nuevo ni de un comportamiento aislado en una sola máquina. Más bien apunta a una debilidad persistente en la forma en que Codex maneja su registro local.

La publicación también señaló que el changelog reciente de OpenAI incluyó algunas correcciones de confiabilidad vinculadas con SQLite. Sin embargo, esas mejoras no habrían abordado el problema central de la tasa de escritura.

Por ello, el asunto seguiría completamente abierto. Hasta el momento descrito por la fuente, no se había presentado una solución definitiva que eliminara el exceso de escrituras sobre la unidad.

Para quienes siguen la evolución del software de IA, este caso sirve además como recordatorio de un reto frecuente. La velocidad de despliegue de nuevas herramientas puede dejar en segundo plano problemas de eficiencia básica que solo emergen bajo uso prolongado.

En estaciones de trabajo dedicadas a programación, automatización o agentes de IA, ese tipo de detalle importa mucho. El costo no se limita al rendimiento, sino que puede trasladarse al hardware y a la confiabilidad del entorno de desarrollo.

Medidas temporales para Linux y macOS

Mientras no exista una corrección oficial para el comportamiento de escritura, algunos usuarios ya manejan soluciones provisionales. La principal recomendación para Linux y macOS es redirigir el archivo ~/.codex/logs_2.sqlite hacia /tmp/ mediante un enlace simbólico.

La lógica detrás de esa medida es sencilla. En muchos sistemas, /tmp/ puede residir en memoria RAM o en almacenamiento temporal, lo que evita trasladar ese volumen constante de escrituras a la unidad SSD principal.

El remedio propuesto tiene una ventaja práctica importante. El archivo de logs señalado no contendría datos de conversación, por lo que perderlo al reiniciar el sistema no representaría un perjuicio funcional relevante para el usuario.

Aun así, se trata de una mitigación y no de una solución real al bug. Requiere cierto conocimiento técnico y no sustituye la necesidad de que el software reduzca su nivel de escritura por diseño.

También conviene tener presente que no todos los entornos gestionan /tmp/ exactamente igual. En algunos equipos o distribuciones, su comportamiento puede variar, por lo que el efecto práctico dependerá de la configuración local.

Para usuarios menos experimentados, el mejor paso inmediato puede ser monitorear la actividad de disco si Codex permanece abierto durante horas o días. Herramientas de sistema para revisar I/O y salud del SSD pueden ayudar a detectar patrones anómalos antes de que se agraven.

Por qué este caso importa más allá de Codex

El episodio refleja una tensión creciente en el ecosistema de herramientas impulsadas por IA. A medida que estos asistentes se integran en flujos de trabajo reales, no basta con que generen código o respondan rápido; también deben operar con disciplina sobre recursos locales.

Un fallo de logging puede parecer menor frente a errores de modelo o seguridad. Sin embargo, cuando se traduce en un desgaste acelerado de hardware, el impacto económico y operativo para usuarios avanzados pasa a ser mucho más tangible.

El caso también muestra cómo comunidades técnicas abiertas suelen detectar primero este tipo de problemas. Fue la observación de un usuario, seguida por una revisión más profunda del comportamiento del sistema, la que permitió cuantificar el alcance potencial del defecto.

En sectores como desarrollo, infraestructura o automatización, una herramienta de IA puede estar corriendo casi todo el tiempo. Bajo esas condiciones, cualquier ineficiencia repetitiva escala rápidamente y deja de ser un detalle marginal.

Por ahora, la información disponible describe un problema serio, medible y todavía sin resolución completa. Para quienes usan Codex CLI de forma intensiva, la prudencia técnica sugiere revisar el consumo de escritura del disco y aplicar mitigaciones temporales hasta que llegue una corrección definitiva.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados