Codex CLI sta dando qualche grattacapo a chi lavora con la programmazione assistita dall’intelligenza artificiale, e il motivo non ha nulla a che fare con la qualità del codice prodotto. Il problema, individuato nella versione a riga di comando dello strumento sviluppato da OpenAI, riguarda il modo in cui l’applicazione scrive informazioni diagnostiche sul disco. E le conseguenze possono essere pesanti, perché nel mirino ci finiscono direttamente gli SSD consumer, quelli montati sui computer di tutti i giorni.
La faccenda è venuta a galla su GitHub, dove diversi addetti ai lavori hanno cominciato ad analizzare una segnalazione piuttosto allarmante. In pratica il software accumula quantità di dati fuori scala su un database SQLite locale, arrivando a consumare in pochi mesi la resistenza teorica che molte unità a stato solido sono progettate per garantire nell’arco della loro intera vita.
Il bug che logga tutto e si mangia il disco
Tutto è partito da uno sviluppatore che aveva notato un’attività del disco decisamente sospetta mentre usava Codex CLI. Andando a fondo, ha scoperto che la sorgente di questo traffico anomalo era un database chiamato logs_2.sqlite, parcheggiato nella cartella di configurazione del programma.
I numeri parlano da soli. In appena 21 giorni il software aveva generato circa 37 terabyte di scrittura. Proiettando il dato su base annuale si arriva a qualcosa come 640 TB. Per capire quanto sia tanto, basta confrontarlo con le specifiche di un comune SSD da 1 TB, che di solito dichiara una resistenza compresa tra 600 e 1.200 TBW, ovvero Terabytes Written. In altre parole, un solo anno di utilizzo rischierebbe di bruciare buona parte del ciclo di vita previsto per l’intero disco.
La radice del problema sta nel sistema di logging, impostato sul livello TRACE. È il più dettagliato in assoluto, quello che normalmente si usa solo quando si fa debug e si vuole tracciare ogni minimo movimento. Con questa configurazione attiva il programma registra praticamente tutto: caricamenti WebSocket, operazioni sul file system, messaggi interni di ogni tipo. Si stima che circa il 71% delle informazioni archiviate derivi proprio da eventi TRACE del tutto superflui in condizioni normali.
A complicare ulteriormente le cose ci si mette la write amplification. Il database SQLite esegue di continuo inserimenti, aggiornamenti e cancellazioni, e questo genera sulla memoria NAND una quantità di scritture fisiche molto più alta rispetto alla semplice crescita del file che vediamo. Risultato: l’usura reale dell’SSD è sensibilmente superiore a quella che si potrebbe immaginare guardando solo le dimensioni del log.
C’è un rimedio temporaneo, ma il fix non è ancora completo
L’effetto più diretto di tutto questo è un’usura accelerata dell’unità di archiviazione, con il rischio concreto di un degrado delle prestazioni nel lungo periodo. Su alcuni sistemi Linux si sono anche verificati problemi legati all’esaurimento dello spazio disponibile, con il database che si gonfia fino a saturare la partizione.
Il problema, va detto, era già stato segnalato in passato sotto forme diverse. Alcuni aggiornamenti recenti hanno corretto vari aspetti legati all’affidabilità del database, però la questione della mole di dati scritti non risulta ancora del tutto risolta.
Nell’attesa di una correzione definitiva, su Linux e macOS esiste un modo per limitare i danni. Si può reindirizzare il file di log verso una directory temporanea in RAM usando un collegamento simbolico. Dato che il database non contiene conversazioni né dati importanti, perderne il contenuto a ogni riavvio non crea alcun problema pratico durante l’utilizzo dello strumento.