OpenAI Codex bevat een fout die ervoor kan zorgen dat uw SSD binnen een jaar defect raakt

Als u de Codex CLI van OpenAI gebruikt en deze gedurende langere tijd actief laat draaien, kan uw SSD zwaar worden belast.

Een GitHub-gebruiker met de naam 1996fanrui heeft het probleem op 14 juni gedocumenteerd nadat hij of zij ongewoon hoge schijfactiviteit op zijn of haar computer had opgemerkt. Na wat onderzoek ontdekte hij of zij dat Codex continu een lokale SQLite-database (opgeslagen in ~/.codex/logs_2.sqlite) overspoelde met diagnostische logboekvermeldingen. Gedurende 21 dagen uptime had de schijf ongeveer 37 TB aan schrijfbewerkingen verwerkt. Op jaarbasis komt dat neer op ongeveer 640 terabyte per jaar. Een standaard SSD van 1 TB voor consumenten heeft een geschatte levensduur van ongeveer 600 TBW — dus deze bug zou, indien niet aangepakt, de volledige gegarandeerde levensduur van uw schijf in minder dan een jaar kunnen opgebruiken.

De boosdoener is een logconfiguratie die waarschijnlijk door niemand bedoeld was om aan eindgebruikers te worden geleverd. De SQLite-feedbackmodule van Codex draait standaard op het globale TRACE-niveau — de meest ‘luidruchtige’ instelling die er is. Deze registreert alles, van ruwe WebSocket-payloads tot alledaagse bestandssysteemgebeurtenissen zoals het openen van ‘passwd’ en ‘ld.so.cache’. Bovendien negeert het de standaardomgevingsvariabele RUST_LOG, waardoor er geen voor de hand liggende manier is om dit uit te schakelen. Ongeveer 71% van de gelogde gegevens bestaat uit 'ruis' op TRACE-niveau die geen echt diagnostisch doel dient, althans niet voor de gemiddelde gebruiker.

Wat de situatie nog verergert, is schrijfversterking. De database groeit niet alleen, maar doorloopt ook tienduizenden invoeg- en verwijderingsbewerkingen per minuut. Er wordt fysiek veel meer naar de schijf geschreven dan de bestandsgrootte doet vermoeden.

Dit is in feite al sinds ten minste april in verschillende vormen een bekend probleem, waarbij gedurende het jaar meerdere gerelateerde meldingen zijn ingediend. In de recente changelog van OpenAI werd ingegaan op enkele betrouwbaarheidsverbeteringen voor SQLite, maar het probleem met de schrijfsnelheid is niet aangepakt. De kwestie is nog steeds volledig onopgelost.

Ondertussen, Linux en macOS gebruikers een symbolische link kunnen aanmaken van '~/.codex/logs_2.sqlite' naar '/tmp/' om schrijfbewerkingen naar het RAM-geheugen om te leiden. Het bestand bevat geen gespreksgegevens, dus het is geen probleem als het bij het opnieuw opstarten verloren gaat.