Un informe de error abierto en el repositorio de OpenAI Codex (issue #28224) advierte de que el subsistema de logs de retroalimentación basado en SQLite que utiliza el Codex CLI escribe de forma continua y muy intensiva sobre el disco. Tras 21 días de uso, el autor midió aproximadamente 37 TB de escrituras acumuladas, lo que extrapolado a un año arroja unos 640 TB anuales. En un SSD de 1 TB, eso equivale a unas 640 reescrituras completas del disco al año, una cifra cercana o superior a la resistencia TBW (total de bytes escritos) garantizada por muchos SSD de consumo, que ronda los 600 TBW. En consecuencia, el disco podría consumir toda su vida útil en menos de un año.
El problema se concentra en tres archivos de la carpeta ~/.codex/: logs_2.sqlite, logs_2.sqlite-wal y logs_2.sqlite-shm. En la base de datos, el autor retiene unas 681.774 filas que ocupan alrededor de 1.035 MiB. Los registros de nivel TRACE representan el 70,7% del contenido retenido, seguidos de INFO (25,7%), DEBUG (3%) y WARN (0,6%). Las principales fuentes de ruido son los eventos TRACE globales de inotify, los logs espejados de OpenTelemetry (codex_otel.log_only y codex_otel.trace_safe) y el volcado crudo de payloads de WebSocket y SSE.
El informe documenta además una fuerte amplificación de escritura: en una muestra de 15 segundos se insertaron 36.211 filas mientras el número de filas retenidas apenas varió, lo que indica un ciclo continuo de insertar, indexar, escribir en el WAL y podar. La causa probable es que el sink SQLite se instala con el nivel TRACE por defecto, incluyendo dependencias internas y payloads de protocolo. Como solución, el autor propone mantener los logs de retroalimentación activos pero reducir lo que se persiste: eliminar el TRACE global, filtrar el ruido de bajo valor de dependencias (hyper_util, tokio-tungstenite, inotify), guardar resúmenes en lugar de payloads crudos de WebSocket/SSE, y añadir un límite global de tamaño y escrituras para la base de datos. El hilo enlaza también con issues previos que ya documentaban un crecimiento descontrolado de logs_N.sqlite y un uso intensivo de disco por parte del proceso codex en reposo.