OpenAI Codex: Fehler könnte SSD-Lebensdauer in weniger als einem Jahr überschreiten

Wer die Codex-Befehlszeilenschnittstelle von OpenAI über längere Zeiträume nutzt, könnte seine SSD deutlich stärker belasten als erwartet.

Auf GitHub machte der Nutzer „1996fanrui“ am 14. Juni auf das Problem aufmerksam, nachdem er ungewöhnlich hohe Schreibaktivitäten auf seinem System festgestellt hatte. Seine Analyse ergab, dass Codex fortlaufend Diagnoseprotokolle in eine lokale SQLite-Datenbank unter „~/.codex/logs_2.sqlite“ schreibt. Innerhalb von nur 21 Tagen wurden dadurch rund 37 Terabyte an Daten auf die SSD geschrieben. Hochgerechnet entspricht das etwa 640 Terabyte pro Jahr. Zum Vergleich: Viele Consumer-SSDs mit einer Kapazität von 1 TB sind für etwa 600 TBW (Terabytes Written) ausgelegt. Sollte das Problem dauerhaft bestehen bleiben, könnte die garantierte Schreibkapazität eines solchen Laufwerks bereits innerhalb eines Jahres ausgeschöpft werden.

Ursache des Problems ist offenbar eine Logging-Konfiguration, die ursprünglich nicht für Endanwender vorgesehen war. Die SQLite-Feedback-Senke von Codex arbeitet standardmäßig auf der globalen TRACE-Stufe – der detailliertesten Protokollierungsebene. Erfasst werden dabei nicht nur wichtige Diagnosedaten, sondern auch rohe WebSocket-Nutzdaten und alltägliche Systemereignisse wie Dateizugriffe auf „passwd“ oder „ld.so.cache“. Besonders problematisch ist, dass die übliche Umgebungsvariable „RUST_LOG“ die Protokollierung nicht wirksam reduziert. Nach den veröffentlichten Analysen entfallen rund 71 Prozent aller gespeicherten Daten auf TRACE-Protokolle, die für die meisten Nutzer kaum praktischen Nutzen haben.

Hinzu kommt ein Effekt namens Schreibverstärkung (Write Amplification). Die Datenbank wächst nicht nur kontinuierlich an, sondern führt auch permanent Einfüge-, Aktualisierungs- und Löschvorgänge durch. Dadurch werden physisch deutlich mehr Daten auf die SSD geschrieben, als die eigentliche Dateigröße vermuten lässt.

Das Problem ist in unterschiedlichen Ausprägungen bereits seit April bekannt. Im Laufe des Jahres wurden mehrere entsprechende Fehlerberichte eingereicht. Zwar enthielten jüngste Codex-Updates Verbesserungen bei der Zuverlässigkeit der SQLite-Datenbank, die außergewöhnlich hohe Schreibrate wurde bislang jedoch nicht adressiert.

Bis eine offizielle Lösung verfügbar ist, können Linux- und macOS-Nutzer die Datei „~/.codex/logs_2.sqlite“ per symbolischem Link nach „/tmp“ umleiten. Dadurch werden die Schreibvorgänge in den Arbeitsspeicher verlagert. Da die Datenbank keine eigentlichen Konversationsdaten speichert, gilt ein Verlust der Inhalte nach einem Neustart in der Regel als unkritisch.