En pocas palabras: No. La versión 0.142.0 de Codex CLI reduce pero no elimina el problema del issue #28224: los logs SQLite de feedback siguen escribiendo volúmenes excesivos al disco —hasta 640 TB anuales en uso intensivo—, así que el desgaste del SSD continúa sin un parche definitivo.
El issue #28224 de Codex CLI reportó que los logs SQLite de feedback de la herramienta pueden escribir hasta 640 TB por año al disco local, desgastando un SSD en cuestión de meses. El problema de logging de Codex SQLite está documentado en GitHub.
Si corrés Codex localmente todo el día, esto te toca. Vale la pena entender qué pasa antes de que tu disco empiece a tirar errores.
Codex es la herramienta de línea de comandos (CLI) de OpenAI para programar asistido por IA desde la terminal. El problema de logging de Codex SQLite es un bug, reportado en el issue #28224, por el cual los logs de feedback se escriben sin límite a una base SQLite local, generando hasta 640 TB de escrituras anuales y acelerando el desgaste del SSD. Afecta a quien ejecuta Codex de forma intensiva en su propia máquina.
En 30 segundos
- 640 TB al año. Es la cifra del título del issue #28224: escrituras a SQLite que pueden llegar a ese volumen en uso continuo.
- ~73 GB por hora. Esos 640 TB anuales dan unos 1,75 TB diarios si la herramienta escribe sin parar.
- El SSD es la víctima. Con ese ritmo, el TBW de un disco de consumo típico se agota en pocos meses, no en años.
- Conviene seguir el hilo. El estado y cualquier corrección se discuten en el propio issue de GitHub.
- Hay mitigaciones. Limpiar los logs, monitorear el disco y actualizar a la última versión disponible reducen el daño mientras tanto.
OpenAI es una organización estadounidense de investigación en inteligencia artificial, fundada en 2015, que desarrolla sistemas de IA avanzados como los modelos GPT-4 y ChatGPT.
¿Qué es el problema de logging de Codex SQLite?
Ponele que dejás Codex corriendo mientras trabajás. Cada interacción con la CLI genera “feedback logs” que se escriben a una base de datos SQLite en tu disco. Hasta acá, normal. El tema es que esos logs se escriben de forma continua y, según el reporte, sin una política de retención que los limite o los rote. Complementá con comparar Codex con Claude Code.
El resultado lo dice el título del issue #28224 en GitHub: “los logs SQLite de feedback de Codex pueden escribir ~640 TB/año y consumir rápido la resistencia del SSD”. No es un detalle menor. Es el tipo de bug que no ves hasta que tu disco empieza a fallar.
¿Por qué pasa? Escrituras frecuentes a SQLite, sin compresión ni rotación visible para el usuario. La base crece, el disco trabaja, y vos ni te enterás hasta que mirás el espacio ocupado o el SMART del SSD.
¿Cuál es el consumo real de espacio de Codex?
Hagamos la cuenta, que es la parte que asusta. Si tomás los 640 TB anuales del issue y los repartís, te queda esto:
- ~1,75 TB por día en uso continuo (640 dividido 365).
- ~73 GB por hora si la herramienta escribe sin pausa.
- Más de 1 GB por minuto en el peor escenario sostenido.
Ojo con un matiz importante: esos 640 TB son escrituras acumuladas, no espacio ocupado al mismo tiempo. SQLite puede reescribir y sobreescribir, así que tu disco no necesariamente muestra 640 TB llenos. Pero para la salud del SSD, lo que importa son las escrituras totales, y ahí la cifra pega de lleno.
¿Cuál es el impacto en la vida útil del SSD?
Acá viene lo bueno (o lo malo, según cómo lo mires). Los SSD no se desgastan por leer, se desgastan por escribir. Cada celda de memoria flash aguanta una cantidad finita de ciclos de escritura, y los fabricantes lo expresan con la spec TBW (Terabytes Written): cuántos terabytes podés escribir antes de que el disco entre en zona de riesgo. Te puede servir nuestra cobertura de explorar los modelos de Anthropic.
Un SSD de consumo de 500 GB suele venir con un TBW de entre 150 y 300 TB, según el modelo y el fabricante (es un rango general de la industria, conviene mirar la ficha de tu disco puntual). Ahora cruzá ese dato con 640 TB de escritura anual: agotás el presupuesto de escrituras en menos de medio año.
| Métrica | Valor estimado |
|---|---|
| Escritura por hora (uso continuo) | ~73 GB |
| Escritura por día | ~1,75 TB |
| Escritura por año | ~640 TB (issue #28224) |
| TBW típico SSD consumer 500 GB | 150 a 300 TBW (dato general de industria) |
| Tiempo estimado para agotar el TBW | 3 a 6 meses de uso intenso |
Para una notebook personal ya es feo. Para un servidor en producción que corre Codex de fondo, es directamente un riesgo operativo. Los síntomas de un SSD castigado son conocidos: lentitud creciente, errores de I/O, y en el peor caso, el disco que se vuelve de solo lectura o muere.
¿Qué versiones de Codex están afectadas?
El reporte documenta el comportamiento de logging excesivo, pero no especifica una versión concreta en la que aparezca o se corrija. Para saber si tu instalación está afectada conviene medirlo directamente (lo vemos abajo) y revisar el hilo del issue.
¿Cuál es el estado de la corrección? Conviene chequearlo en las release notes oficiales de OpenAI y en el propio hilo del issue, que es donde se discute en tiempo real. Lo que está claro es que actualizar a la última versión disponible es mejor que quedarse en una vieja, pero no asumas que con eso quedó cerrado. Sobre eso hablamos en ver las mejores ofertas disponibles.
¿Cómo verificar si tu instalación está afectada?
No hace falta confiar en la suerte. Podés medirlo en dos minutos.
En Linux o macOS
- Buscá los archivos SQLite en la carpeta de datos de Codex con
find ~ -name "*.sqlite" -o -name "*.db"y mirá su tamaño. - Medí el peso de la carpeta con
du -shapuntando al directorio de datos. - Monitoreá en vivo con
watch -n5 du -sh ruta/al/logpara ver si crece mientras usás la herramienta.
En Windows (PowerShell)
- Listá y ordená por tamaño con
Get-ChildItem -Recurse -Filter *.sqlite | Sort-Object Length -Descending. - Revisá el espacio del volumen con
Get-Volumeantes y después de una sesión larga. - Mirá los timestamps de modificación: si el archivo SQLite se actualiza cada pocos segundos, ahí tenés tu confirmación.
Si ves un archivo que pesa decenas de GB o que crece a ojos vista, estás afectado. Si después de un par de horas de uso apenas se movió, probablemente tu versión ya mitiga el tema.
¿Qué soluciones hay mientras se resuelve el bug?
Hasta que llegue una corrección definitiva, te quedan mitigaciones. Ninguna es perfecta, pero bajan el daño.
- Actualizá a la última versión. Aunque actualizar no garantiza cerrar el tema del todo, las releases siguientes pueden traer mejoras adicionales.
- Limpiá los logs de forma periódica. Un script en cron (Linux/macOS) o en el Programador de tareas (Windows) que vacíe o borre el SQLite de feedback en intervalos regulares.
- Revisá si podés desactivar el logging. Si la configuración de Codex expone una opción para apagar o limitar el feedback log, usala.
- Movió los logs a otro disco. Mandar las escrituras a un disco secundario (idealmente un HDD o un SSD viejo y sacrificable) protege tu disco principal.
- Monitoreá automático. Una alerta cuando el archivo supere cierto tamaño te avisa antes de que sea tarde.
Si lo corrés en infraestructura propia y manejás hosting o servidores, conviene tener el monitoreo de disco integrado desde el arranque. En esos casos un panel de control de hosting decente, como el que ofrece donweb.com, te deja vigilar el uso de almacenamiento sin armar todo a mano.
Qué está confirmado y qué no
- Confirmado: existe el issue #28224 en el repo de Codex, que reporta escrituras de hasta ~640 TB/año a SQLite.
- Confirmado: el problema afecta a la resistencia (endurance) del SSD por volumen de escrituras.
- Pendiente: el estado de la corrección y si existe una solución definitiva.
- Pendiente: el detalle técnico exacto de qué cambió en cada release y el cronograma de una solución definitiva.
Errores comunes al lidiar con este problema
- Creer que actualizar lo arregla y olvidarse. Pasar a la última versión ayuda, pero no es garantía. Seguí monitoreando el disco después de actualizar.
- Borrar el SQLite mientras Codex corre. Si la herramienta tiene el archivo abierto, podés corromperlo o que se regenere al instante. Frená el proceso, limpiá, y reiniciá.
- Confundir espacio ocupado con escrituras totales. El disco puede mostrar pocos GB y aun así estar recibiendo terabytes de escrituras. Lo que mata al SSD es lo segundo, no lo primero.
- Ignorar el SMART del disco. Las herramientas de salud del SSD muestran las escrituras acumuladas. Si nunca las miraste, este es buen momento para empezar.
Preguntas Frecuentes
¿Cuál es el problema de logging de Codex?
Codex CLI escribe logs de feedback de forma continua a una base SQLite local, sin una política de retención clara. Según el issue #28224 de GitHub, esto puede generar hasta 640 TB de escrituras por año en uso intenso.
¿Cuánto espacio consume Codex en el disco?
En uso continuo, las escrituras llegan a unos 73 GB por hora y cerca de 1,75 TB por día. El espacio ocupado al mismo tiempo puede ser menor, porque SQLite reescribe datos, pero las escrituras totales son las que estresan al SSD. Esto se conecta con lo que analizamos en conocer otras herramientas de OpenAI.
¿El problema ya está resuelto?
El issue documenta el problema, pero las fuentes disponibles no confirman una corrección definitiva. Conviene revisar las release notes oficiales y el hilo de GitHub para el estado actual.
¿Cómo sé si mi sistema está afectado?
Buscá los archivos SQLite en la carpeta de datos de Codex y mirá su tamaño y sus timestamps de modificación. En Linux/macOS usá du -sh y find; en Windows, Get-ChildItem y Get-Volume. Si crecen rápido durante el uso, estás afectado.
¿Qué impacto tiene en la vida útil del SSD?
Con 640 TB de escritura anual, agotás el TBW de un SSD de consumo típico (150 a 300 TBW) en pocos meses. Eso acelera el desgaste y puede llevar a errores de I/O o falla del disco, sobre todo en servidores de producción.
Conclusión
El issue #28224 puso sobre la mesa algo que muchos no miran: una herramienta de IA puede desgastarte el SSD sin que te des cuenta, a razón de 640 TB de escrituras al año. El problema de logging de Codex SQLite está documentado pero no hay confirmación de una solución definitiva, y eso obliga a no confiarse.
¿Qué hacer hoy? Medí el tamaño de tus archivos SQLite, actualizá a la última versión, armá una limpieza periódica y dejá un monitoreo de disco corriendo. Si Codex vive en un servidor de producción, tratá esto como prioridad, no como curiosidad. Y seguí el hilo en GitHub: ahí va a aparecer la corrección definitiva cuando llegue.