Codex OpenAI bug: 640 TB/año en logs SQLite y SSDs en riesgo

¿Qué está pasando con Codex y los 640 TB de logs?

Un bug crítico en Codex de OpenAI está generando escritura excesiva de logs en SQLite, con un cálculo estimado de hasta 640 TB por año si la tasa de escritura se mantiene constante. Esta cifra, propuesta por usuarios en GitHub, ilustra la magnitud del problema: el módulo de logging emite eventos TRACE de forma descontrolada, degradando rápidamente la vida útil de los SSDs y causando fallos de sistema por falta de espacio en disco.

Para founders y equipos de desarrollo que dependen de herramientas de IA para coding, este bug representa un riesgo operativo real: desde llenado constante de disco hasta corrupción de bases de datos locales que bloquean completamente el flujo de trabajo.

¿Cuál es la causa técnica del bug?

El problema se origina en el módulo de SQLite WAL (Write-Ahead Logging) dentro de Codex. Durante el streaming de datos, el sistema emite una cantidad masiva de eventos de seguimiento (TRACE logs) sin mecanismos de limpieza, rotación o limitación.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Los archivos afectados son principalmente logs_2.sqlite y su archivo WAL asociado, ubicados en el directorio ~/.codex/ del usuario. Según reportes de la comunidad, estos archivos pueden alcanzar 1 GB o más en sesiones normales de uso, consumiendo no solo espacio en disco sino también la durabilidad del SSD debido a la escritura continua.

El cálculo de 640 TB/año es una estimación hipotética que los usuarios realizaron extrapolando la tasa de escritura observada durante un año completo. No es un dato oficial de OpenAI, pero sirve como alerta sobre la severidad del problema si no se mitiga.

¿Qué impacto real están reportando los desarrolladores?

La comunidad ha documentado múltiples casos de impacto severo:

Reproducibilidad alta: Usuarios reportan poder reproducir el bug «tantas veces» que algunos crearon scripts automatizados de limpieza
Llenado constante de disco: El espacio se agota rápidamente, especialmente en máquinas con SSDs de capacidad limitada
Degradación de rendimiento: Después de eliminar los archivos de logs, usuarios reportan que Codex versión 5.5 se vuelve significativamente más rápido en razonamiento y detección de bugs
Corrupción de archivos: En algunos casos, logs_2.sqlite se corrompe completamente, mostrando como «datos genéricos» en lugar de una base de datos SQLite válida
Bloqueo del flujo de trabajo: Cuando el disco se llena o los archivos se corrompen, Codex deja de funcionar hasta que se aplica una mitigación manual

¿Qué soluciones ha propuesto la comunidad?

Hasta junio de 2026, OpenAI no ha emitido una solución oficial ni parche definitivo para este bug. Sin embargo, la comunidad ha desarrollado varias mitigaciones efectivas:

Script de limpieza automática (Bash)

Usuarios han creado scripts que eliminan automáticamente el archivo SQLite WAL y terminan el proceso de Codex para prevenir el llenado de disco. Este enfoque reactivo funciona pero requiere ejecución periódica.

Parche de código vía Pull Request

Existe un Pull Request en GitHub creado por un miembro de la comunidad que modifica la lógica de logging para corregir la escritura excesiva. Este parche aún no ha sido mergeado oficialmente, pero el código está disponible para revisión.

Renombrado de archivos corruptos

Cuando los archivos SQLite están corruptos, la solución es renombrarlos (ej. a .bak) para que Codex los recree automáticamente:

mv ~/.codex/logs_2.sqlite ~/.codex/logs_2.sqlite.bak
mv ~/.codex/state_5.sqlite ~/.codex/state_5.sqlite.bak

Parche de IPC para sistemas compartidos

En sistemas Linux compartidos (como clusters SLURM), un parche manual en extension.js cambia la ubicación del socket IPC de /tmp/codex-ipc/ (compartido) a una ruta por usuario (~/.codex-ipc) para evitar conflictos de permisos.

Importante: Estos parches manuales se sobrescriben con cada actualización de la extensión, requiriendo re-aplicación.

¿Existen antecedentes de bugs similares en herramientas de desarrollo?

Este no es el primer caso de escritura excesiva de logs en herramientas de desarrollo. Antecedentes relevantes incluyen:

Bugs TOCTOU (Time-of-Check to Time-of-Use): Problemas donde la validación y el uso de recursos no están sincronizados, comunes en sistemas de IA
Corrupción de SQLite por acceso simultáneo: Incidentes documentados en múltiples agentes de desarrollo donde archivos de base de datos se corrompen por escritura descontrolada
Log4Shell (CVE-2021-44228): Aunque de naturaleza diferente, demostró cómo el procesamiento no validado de logs puede causar fallos críticos
XZ Utils (CVE-2024-3094): Mostró riesgos en artefactos de build manipulados, relevante para herramientas que generan código automáticamente

Estos antecedentes refuerzan la necesidad de monitoreo proactivo en herramientas de IA que operan a nivel de sistema.

¿Qué significa esto para tu startup?

Si tu equipo usa Codex u otras herramientas de IA para desarrollo, este bug tiene implicaciones operativas directas que debes abordar:

Riesgos para tu infraestructura

Costos imprevistos de hardware: La degradación acelerada de SSDs puede forzar reemplazos prematuros, especialmente en equipos con máquinas de desarrollo de gama media
Downtime no planificado: Cuando el disco se llena o los archivos se corrompen, el desarrollo se detiene hasta que se aplica la mitigación
Pérdida de datos de sesión: La corrupción de logs puede eliminar historiales de sesiones, contextos de conversación y configuraciones locales
Riesgo de seguridad: Archivos de logs masivos pueden contener información sensible del código que estás desarrollando

Acciones concretas que debes implementar hoy

Acción 1: Monitoreo proactivo del espacio en disco

Configura alertas automatizadas que notifiquen cuando el directorio ~/.codex/ exceda un umbral (ej. 500 MB). En sistemas Linux/macOS, puedes usar un cron job:

0 * * * * find ~/.codex -name "*.sqlite" -size +500M -exec echo "ALERTA: {}" \;

Esto te dará visibilidad antes de que el problema cause downtime.

Acción 2: Implementa rotación de logs manual

Mientras no haya parche oficial, crea un script que elimine o archive los archivos de logs periódicamente:

#!/bin/bash
# Limpieza semanal de logs de Codex
find ~/.codex -name "logs_2.sqlite*" -mtime +7 -delete
find ~/.codex -name "*.wal" -mtime +1 -delete

Ejecuta esto vía cron semanalmente para mantener el crecimiento bajo control.

Acción 3: Evalúa alternativas temporalmente

Si el bug está afectando significativamente tu flujo de trabajo, considera:

Usar Codex CLI en lugar de la extensión de VS Code (algunos usuarios reportan menos problemas)
Implementar revisión de código asistida por IA en el servidor en lugar de local
Postergar actualizaciones de la extensión hasta que se publique un parche oficial

Acción 4: Documenta incidentes para tu equipo

Crea un runbook interno que detalle:

Cómo identificar el bug (síntomas: disco lleno, Codex no carga, archivos corruptos)
Pasos de mitigación inmediata (renombrar archivos, limpiar WAL)
Contacto para escalar si el problema persiste

Esto reducirá el tiempo de resolución de incidentes de horas a minutos.

¿Cuándo se espera una solución oficial de OpenAI?

Al momento de este artículo (junio 2026), OpenAI no ha comunicado una fecha estimada para un parche oficial. El Pull Request de la comunidad está bajo revisión, pero no hay garantía de cuándo será mergeado.

Recomendación: Suscríbete al issue #28224 en GitHub para recibir notificaciones cuando haya actualizaciones oficiales. Mientras tanto, las mitigaciones de la comunidad son tu mejor defensa.

Conclusión

El bug de escritura excesiva de logs en Codex de OpenAI es un recordatorio crítico de que las herramientas de IA, aunque poderosas, pueden tener fallos operativos severos que impactan directamente tu infraestructura. El cálculo de 640 TB/año —aunque hipotético— ilustra la magnitud del problema si no se mitiga.

Para founders y líderes técnicos: la lección va más allá de Codex. Cualquier herramienta de IA que opere a nivel de sistema requiere monitoreo proactivo, planes de mitigación y alternativas de respaldo. No asumas que porque una herramienta es de un proveedor grande está libre de bugs críticos.

Implementa las acciones concretas descritas arriba hoy mismo: monitoreo de disco, rotación de logs manual, y documentación de incidentes. Tu equipo (y tus SSDs) te lo agradecerán.