Ein Logging-Fehler in OpenAIs Codex-CLI kann unbemerkt Terabytes auf lokale SSDs schreiben und so die Lebensdauer der Platte spürbar verkürzen. Für Entwicklerteams, die den KI-Agenten dauerhaft auf der eigenen Hardware laufen lassen, ist das ein stiller Kostenfaktor.
drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen
Kommt Ihnen das bekannt vor? Ein Codex-Prozess läuft tagelang im Hintergrund, und niemand schaut auf die Schreiblast. Genau dort setzt das Problem an, das ein Nutzer im offiziellen GitHub-Issue zum Codex-Logging dokumentiert hat.
Das Wichtigste in Kürze
- Bei einem Nutzer landeten in 21 Tagen rund 37 Terabyte auf der SSD, hochgerechnet etwa 640 Terabyte pro Jahr.
- Eine typische 1-Terabyte-SSD verträgt über ihr Leben oft nur rund 600 Terabyte, der Fehler frisst diese Reserve in unter einem Jahr.
- Ursache ist eine SQLite-Senke, die alles auf TRACE-Stufe protokolliert und die Umgebungsvariable RUST_LOG ignoriert.
- Ein offizieller Fix fehlt bislang, ein Workaround leitet die Datei in den Arbeitsspeicher um.
Was genau schreibt so viel auf die Platte?
Die Schreiblast stammt aus einer SQLite-Datei für Feedback-Logs, die alle Log-Ziele dauerhaft auf der Stufe TRACE protokolliert. In der untersuchten Datenbank machten reine TRACE-Einträge rund 70 Prozent der Bytes aus.
Die Senke sammelt Daten, die kaum jemand braucht: rohe Websocket- und SSE-Protokolldaten, gespiegelte Telemetrie und banale Dateisystem-Ereignisse, etwa das Öffnen von Systemdateien. Die übliche Drossel über RUST_LOG greift nicht, weil die Senke diese Variable schlicht übergeht.
Den eigentlichen Schaden richtet die Schreibverstärkung an. Die Datei selbst bleibt mit rund einem Gigabyte klein, doch die Datenbank fügt im Schnitt 36.211 Zeilen alle 15 Sekunden ein und löscht alte gleich wieder. Auf der Platte landen so weit mehr Schreibvorgänge, als die Dateigröße vermuten lässt.
Warum verschleißen SSDs durch übermäßiges Logging?
Jede Flash-Zelle verträgt nur eine begrenzte Zahl an Schreib- und Löschzyklen, gemessen als TBW (Terabytes Written). Ist dieses Budget aufgebraucht, steigt das Ausfallrisiko deutlich.
Gängige Consumer-SSDs liegen je nach Größe zwischen rund 150 und 600 TBW. TLC-Speicher hält pro Zelle oft nur einige hundert bis tausend Zyklen aus. 640 Terabyte pro Jahr sprengen dieses Budget bei vielen Laptops in wenigen Monaten.
Das Muster ist nicht neu. Schon früher belasteten fehlkonfigurierte Telemetrie- und Debug-Logs Datenträger über Gebühr, und im Codex-Tracker häufen sich seit April ähnliche Meldungen zu wuchernden Logs und vollen Festplatten. Der einzelne Bug ist also eher Symptom einer fehlenden Schreibdisziplin als ein Ausreißer.
Agentische KI-Werkzeuge laufen mit weitreichenden lokalen Rechten, doch die Ressourcen-Disziplin bleibt der blinde Fleck. Ein Agent, der Ihre SSD in Monaten verschleißt, kostet am Ende mehr als jedes Abo.
— Michael Dobler, Herausgeber Dr. Web
Was sollten Entwickler und Firmen im DACH-Raum jetzt tun?
Prüfen Sie die installierte Codex-Version, beobachten Sie die SSD-Schreiblast über SMART-Werte und begrenzen Sie das Logging, bevor der Datenträger leidet.
Auf Linux und macOS leitet ein Workaround die Datei ~/.codex/logs_2.sqlite per Symlink nach /tmp/ in den Arbeitsspeicher um. Die Datei enthält keine Gesprächsdaten, ihr Verlust beim Neustart ist also unkritisch. Ein offizieller Patch, der die Schreibrate selbst senkt, steht weiter aus.
Für Teams gilt der gleiche Grundsatz wie bei jedem autonomen Agenten auf Entwickler-Hardware: Schreiblast gehört ins Monitoring. Wie schnell solche Agenten sonst Budgets sprengen, zeigt unser Beitrag zur Token-Krise im Mittelstand. Wer Codex frisch einführt, findet im KI-Bereich von Dr. Web und im LLMs-Ratgeber die nötige Einordnung.
