Bug logging in Codex: il rischio è riempire SSD con terabyte di dati

Un bug individuato nella versione a riga di comando di Codex CLI, lo strumento di programmazione sviluppato da OpenAI, potrebbe ridurre drasticamente la durata operativa degli SSD consumer.

Il problema non riguarda errori nel codice generato dall’AI, ma il modo in cui l’applicazione registra informazioni diagnostiche sul disco locale. La segnalazione, emersa su GitHub e analizzata da diversi osservatori del settore, descrive una situazione in cui il software scrive quantità anomale di dati su un database SQLite, consumando in pochi mesi la resistenza teorica garantita da molte unità a stato solido.

Il bug che logga tutto e consuma l’SSD

La segnalazione è partita da uno sviluppatore che aveva notato un’attività anomala del disco durante l’utilizzo di Codex CLI. L’origine del traffico era un database locale denominato logs_2.sqlite, collocato nella directory di configurazione dell’applicazione.

In 21 giorni il software aveva generato circa 37 terabyte di scrittura, proiettando il dato su base annuale si arriverebbe a circa 640 TB. Per capire la portata del problema basta confrontare questi numeri con le specifiche di molti SSD consumer da 1 TB, che dichiarano valori di resistenza compresi tra 600 e 1.200 TBW (Terabytes Written). La causa è una configurazione del sistema di logging impostata sul livello TRACE, il più dettagliato disponibile, normalmente usato solo in fase di debug.

Con questa impostazione il programma registra praticamente ogni evento: caricamenti WebSocket, operazioni sul file system, messaggi interni. Circa il 71% delle informazioni archiviate deriverebbe da eventi TRACE superflui in condizioni normali. A peggiorare la situazione interviene la write amplification: il database SQLite esegue continuamente inserimenti, aggiornamenti e cancellazioni, generando scritture fisiche sulla NAND molto superiori rispetto alla semplice crescita del file. Il risultato è un consumo effettivo dell’SSD sensibilmente più alto di quanto appaia.

Workaround disponibile, fix ancora incompleto

Le conseguenze più immediate riguardano l’usura accelerata dell’unità di archiviazione, con un aumento della probabilità di degrado delle prestazioni nel lungo periodo.

Su alcuni sistemi Linux si sono verificati anche problemi legati all’esaurimento dello spazio disponibile. Il problema era stato segnalato in precedenza sotto forme diverse e alcuni aggiornamenti recenti hanno corretto aspetti legati all’affidabilità del database, ma la questione della quantità di dati scritti non risulta ancora completamente risolta.

In attesa di una correzione definitiva, su Linux e macOS è possibile reindirizzare il file di log verso una directory temporanea in RAM tramite collegamento simbolico: poiché il database non contiene conversazioni o dati essenziali, la perdita del contenuto dopo un riavvio non causa problemi operativi rilevanti.