Ein kürzlich aufgetretenes Logging-Problem in Codex verwandelte eine unauffällige lokale Datenbank in einen überraschend intensiven SSD-Schreiber. Laut dem ursprünglichen GitHub-Bericht konnten die SQLite-Feedback-Logs von Codex unter dem gemeldeten Nutzungsmuster ungefähr 640 TB pro Jahr schreiben. Für eine Consumer-SSD mit einer Bewertung von etwa 600 TBW ist diese Zahl nicht nur ein kleines Durcheinander; sie liegt nahe an der garantierten Schreibausdauer des Laufwerks.

Das Merkwürdige daran ist, dass die Log-Datenbank gar nicht riesig wirkte. Die Datei konnte bei etwa einem Gigabyte liegen, während sich die tatsächlichen historischen Schreibvorgänge im Hintergrund weiter anhäuften. Genau deshalb erregte dieser Fehler so viel Aufmerksamkeit: Er füllte die Festplatte nicht auf offensichtliche Weise, konnte aber dennoch Schreibzyklen aufbrauchen.

Quellenhinweis: Dieser Artikel basiert auf dem BAAI-Hub-Repost des Berichts von Xinzhiyuan und wurde mit dem öffentlichen GitHub-Issue sowie der Diskussion auf Hacker News abgeglichen. Markenlogos, QR-Codes, Aufforderungen zum Folgen und nicht zugehörige dekorative Bilder der Originalseite wurden nicht übernommen.

Wie 640 TB an SSD-Schreibvorgängen entstehen können

Die Zahl klingt zunächst übertrieben, daher hilft es, mit der Messung zu beginnen.

Im GitHub-Issue sagte der Berichterstatter, dass die Haupt-SSD nach etwa 21 Tagen Betriebszeit rund 37 TB geschrieben hatte. Auf ein volles Jahr hochgerechnet ergibt das ungefähr 640 TB. Als mutmaßliche Hauptquelle galt die lokale SQLite-Feedback-Log-Datenbank von Codex.

Codex schrieb in Dateien unterhalb des lokalen Konfigurationsverzeichnisses:

~/.codex/logs_2.sqlite
~/.codex/logs_2.sqlite-wal
~/.codex/logs_2.sqlite-shm

Das Verhalten war nicht einfach „die Protokolldatei wächst ewig weiter“. Stattdessen sah es eher nach einer Einfügen-und-Bereinigungs-Schleife aus: Codex fügte neue Zeilen ein und löschte dann alte Zeilen, um die Anzahl der beibehaltenen Zeilen stabil zu halten. Die sichtbare Dateigröße blieb relativ ruhig, aber das Laufwerk musste dennoch die wiederholten Schreibvorgänge verarbeiten.

Eine 15-Sekunden-Stichprobe aus dem Bericht zeigte das Problem deutlich:

Das bedeutet, dass etwa 36.211 Zeilen in 15 Sekunden eingefügt wurden, obwohl die Anzahl der beibehaltenen Zeilen überhaupt nicht zunahm. Von außen wirkte die Datenbank stabil, doch darunter setzte sich die Schreibaktivität fort.

Die häufigen Logeinträge waren außerdem nicht alle hochwertige Anwendungsereignisse. Die Beispiele umfassten wiederholtes Rauschen auf Dateisystem- und Abhängigkeitsebene, etwa inotify-Ereignisse:

128,764x TRACE log: inotify event: ... name: Some("ld.so.cache")
37,982x TRACE log: inotify event: ... name: Some("locale.alias")
23,843x TRACE log: inotify event: ... name: Some("passwd")

Das Ergebnis war ein lokales Logging-System, das den Speicher immer wieder neu beschreiben konnte, während es den Nutzern nur sehr wenige sichtbare Anzeichen dafür gab, dass etwas Ungewöhnliches geschah.

Eine 1-GB-Datei kann dennoch Hunderte von Terabyte an Schreibvorgängen verursachen

Der kontraintuitivste Teil dieses Vorfalls ist einfach: Bei SSD-Verschleiß geht es um die gesamten Schreibvorgänge, nicht um die aktuelle Dateigröße.

Eine lokale Datenbank kann bei etwa 1 GB bleiben, während die Anwendung wiederholt Teile davon schreibt, bereinigt, indiziert, Checkpoints erstellt und neu schreibt. Aus Sicht der Speicherintegrität zählt nicht nur, wie groß die Datei heute aussieht. Entscheidend ist, wie viele Daten im Laufe der Zeit geschrieben wurden.

Der Bericht enthielt einen Snapshot, der die Diskrepanz leichter erkennbar machte:

Die aktuelle Datenbank behielt nur etwa eine halbe Million Zeilen, während die automatisch inkrementierte Zeilen-ID bereits 5,5 Milliarden überschritten hatte. Das ist der Kern der Write-Amplification-Geschichte: Alte Zeilen können aus der aktuellen Datenbankansicht verschwinden, aber die Schreibvorgänge auf die Festplatte, durch die sie erstellt wurden, haben bereits stattgefunden.

Auch SQLite’s WAL, oder Write-Ahead Logging, spielt hier eine Rolle. Im WAL-Modus werden Änderungen an eine separate -wal-Datei angehängt, bevor sie per Checkpoint zurück in die Hauptdatenbank geschrieben werden. WAL ist ein normaler und nützlicher SQLite-Mechanismus, aber wenn eine Anwendung sehr häufig Einfügungen und Löschungen durchführt, kann er die Menge der im Hintergrund stattfindenden Festplattenaktivität vervielfachen.

Einfach gesagt: Das Notizbuch sieht immer noch dünn aus, aber dieselben Seiten wurden viele Male beschrieben, gelöscht und neu beschrieben.

Ursache: Eine RUST_LOG-Einstellung, die sich nicht so verhielt, wie Benutzer es erwarteten

Der Bericht verwies auf ein besonders wichtiges Konfigurationsdetail im Protokollierungspfad von Codex:

Targets::new().with_default(Level::TRACE)

Im Rust-tracing-Ökosystem wird die Protokollfilterung häufig über Targets und Levels gesteuert. Benutzer können vernünftigerweise erwarten, dass die Umgebungsvariable RUST_LOG dabei hilft, die Ausführlichkeit der Protokolle auf etwas wie info, warn oder niedriger zu reduzieren.

In diesem Pfad verwendete die SQLite-Senke für Feedback-Protokolle jedoch standardmäßig TRACE. TRACE ist die ausführlichste Stufe und kann Low-Level-Details von Abhängigkeiten, rohe Protokollaktivitäten und anderes Debugging-Rauschen erfassen. Der Problembericht argumentierte, dass diese Standardeinstellung bedeutete, dass die lokale persistente Protokolldatenbank weiterhin weit mehr speicherte, als sie sollte.

Die Verteilung der beibehaltenen Protokolle zeigte, wie dominant Inhalte auf TRACE-Ebene waren:

Der Bericht stellte außerdem fest, dass zwei gespiegelte, OpenTelemetry-bezogene Protokollquellen, codex_otel.log_only und codex_otel.trace_safe, einen weiteren großen Teil der beibehaltenen Protokollbytes ausmachten. In diesem Beispiel schätzte der Berichterstatter, dass das Herausfiltern dieser störenden Kategorien den Großteil des gespeicherten Protokollvolumens entfernen könnte, ohne Feedback-Protokolle vollständig zu deaktivieren.

Deshalb war der Fehler für Entwickler so frustrierend. Es ging nicht einfach nur um „Sie haben vergessen, die Protokollierung zu konfigurieren.“ Es wirkte eher wie: „Sie haben versucht, die Protokollierung zu reduzieren, aber dieser Pfad hat trotzdem weiterhin ausführliche Protokolle dauerhaft gespeichert.“

Dies war nicht das erste verwandte Problem

Der Bericht behandelte dies nicht als einzelnen, isolierten Vorfall. Er führte eine Reihe verwandter Codex-Probleme rund um SQLite-Protokolle, WAL-Wachstum, starke Festplattenaktivität sowie unbegrenzte oder übermäßige lokale Protokollierung auf.

Einige im Bericht erwähnte Beispiele waren:

KI-Coding-Tools werden zunehmend wie ständig verfügbare Entwicklungspartner behandelt. Sie lesen Dateien, überwachen Repositorys, halten Sitzungen am Leben, sammeln Telemetriedaten und bewahren Kontext. Dadurch werden lokale Budgets für Festplatte, Arbeitsspeicher und CPU genauso wichtig wie Token-Budgets und Modellqualität.

Die Korrekturen wurden gemergt, aber die Debatte endete nicht

Das GitHub-Issue fügte später ein Update hinzu, in dem es hieß, dass drei Pull Requests gemergt worden seien und dass das eigene Codex-Feedback des Meldenden auf eine geschätzte Reduzierung der Logs um 85 % hindeute.

Das Issue listete die drei Korrekturen wie folgt auf:

Eine Reduzierung um 85 % ist erheblich, aber sie ist nicht dasselbe wie der Nachweis, dass lokales Logging nun ein festes langfristiges Schreibbudget hat. Genau diese Unterscheidung ist der Grund, warum die Diskussion weiterging. Entwickler fragten nicht nur, ob dieser konkrete Fehler reduziert worden war; sie fragten, ob KI-Coding-Agenten klarere Grenzen für persistente lokale Telemetrie haben sollten.

Das GitHub-Issue enthielt außerdem einen einfachen Workaround, den ein Kommentator teilte. Er blockiert Einfügungen in die Tabelle logs, indem ein SQLite-Trigger erstellt wird:

sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS
  block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE);
  END;"

Verwenden Sie Workarounds wie diesen mit Vorsicht. Sie können lokale Log-Schreibvorgänge reduzieren, aber sie können auch Diagnosedaten entfernen, die Support-Teams oder Entwickler später benötigen könnten. Im Allgemeinen ist es sicherer, auf eine behobene Version zu aktualisieren und das aktuelle Log-Verhalten zu überprüfen, als eine Anwendungsdatenbank stillschweigend zu ändern, ohne die Abwägungen zu verstehen.

Der Kampf der Coding-Tools verbrennt mehr als nur SSDs

Die Diskussion ging schnell über Codex allein hinaus. Auf Hacker News brachten Entwickler auch allgemeinere Beschwerden über KI-Coding-Tools vor: hohe GPU-Auslastung, hoher Speicherverbrauch, Hintergrundaktivität und große lokale Debug-Logs.

Diese Reaktion ist nachvollziehbar. Moderne KI-Coding-Assistenten sind längst keine einfachen Befehlszeilenprogramme mehr. Viele von ihnen verhalten sich eher wie lokale Agenten: Sie überwachen Projekte, kommunizieren mit entfernten Modellen, verwalten Kontext, führen Befehle aus und behalten den Zustand über Aufgaben hinweg bei. Diese Leistungsfähigkeit ist nützlich, schafft aber auch eine neue Kategorie technischer Verantwortung.

Ein Tool kann sich in der Benutzeroberfläche „in Ordnung“ anfühlen und dennoch im Hintergrund still Ressourcen verbrauchen. Schnelle CPUs, großer Arbeitsspeicher und moderne NVMe-Laufwerke können Probleme lange verbergen. Die App friert möglicherweise nicht ein. Die Festplatte läuft vielleicht nicht voll. Das Terminal reagiert womöglich weiterhin. Doch die Zustandszähler der Hardware können eine andere Geschichte erzählen.

Deshalb wurde dieser Vorfall zu einer nützlichen Fallstudie für KI-Entwicklertools. Die Modellfähigkeit ist wichtig, aber die lokale Betriebsqualität ebenfalls. Ein Coding-Agent, der auf dem Rechner eines Entwicklers läuft, braucht vernünftige Standardeinstellungen, Aufbewahrungsgrenzen, Log-Rotation und eine Möglichkeit für Nutzer, zu verstehen, was er tut.

FAQ

Was war der Codex-SQLite-Logfehler?

Es handelte sich um ein gemeldetes Codex-Protokollierungsproblem, bei dem lokale SQLite-Feedback-Logs sehr große Mengen an Schreibvorgängen auf dem Datenträger erzeugen konnten. Der GitHub-Bericht schätzte bei dem vom Melder gemessenen Nutzungsmuster etwa 640 TB Schreibvorgänge pro Jahr.

Warum konnte eine kleine logs_2.sqlite-Datei trotzdem eine SSD abnutzen?

Die Lebensdauer einer SSD hängt von der insgesamt über die Zeit geschriebenen Datenmenge ab, nicht nur von der aktuellen Dateigröße. Eine Datenbank kann wiederholt einfügen, löschen, in das WAL schreiben, Checkpoints durchführen und Indizes aktualisieren, während sie auf dem Datenträger weiterhin klein erscheint.

Was bedeutet SQLite-WAL in diesem Kontext?

WAL steht für Write-Ahead Logging. SQLite schreibt Änderungen zunächst in eine separate -wal-Datei und überträgt sie später per Checkpoint zurück in die Hauptdatenbank. Das ist normales Verhalten, kann jedoch viel Aktivität verursachen, wenn Einfügungen und Löschungen sehr häufig stattfinden.

Welche Rolle spielte TRACE-Logging?

TRACE ist die ausführlichste Protokollstufe. In der gemeldeten Stichprobe machten Inhalte auf TRACE-Ebene etwa 70,7 % der beibehaltenen Protokollbytes aus, und in dem Issue wurde argumentiert, dass ausführliche Abhängigkeits- und Protokoll-Logs standardmäßig dauerhaft gespeichert wurden.

Hat OpenAI das Codex-Logging-Problem behoben?

Im Update des GitHub-Issues hieß es, dass drei PRs zusammengeführt wurden, wobei der Melder schätzte, dass auf Grundlage der Rückmeldungen aus seiner Codex-Nutzung etwa 85 % der Logs vermieden werden könnten. Zwei Korrekturen wurden als in 0.142.0 veröffentlicht aufgeführt, während die dritte als für 0.143.0 geplant angegeben wurde.

Sollten Nutzer Codex-Logs manuell löschen oder blockieren?

Manuelle Änderungen sollten mit Vorsicht behandelt werden, da sie Diagnoseinformationen entfernen und Nebenwirkungen haben können. Ein sichererer erster Schritt besteht darin, Codex zu aktualisieren, die Protokolldateien zu prüfen und bei Bedenken die SSD-Schreibzähler zu überwachen.

Ist das nur ein Codex-Problem?

Dieser konkrete Bericht konzentrierte sich auf Codex. Das umfassendere Anliegen gilt jedoch für lokale KI-Agenten im Allgemeinen: Ständig aktive Tools benötigen klare Ressourcenbudgets für Festplatte, CPU, Arbeitsspeicher, Telemetrie und aufbewahrte Logs.

Verwandte Tools

• OpenAI Codex GitHub-Repository: Das öffentliche Repository für Codex CLI und den zugehörigen Quellcode.

• SQLite: Die eingebettete Datenbank-Engine, die von vielen lokalen Anwendungen und Tools verwendet wird.

• SQLite-Dokumentation zu Write-Ahead Logging: Offizielle Dokumentation, die erklärt, wie WAL funktioniert und warum Checkpointing wichtig ist.

• Rust tracing: Das im Codex-Issue besprochene Rust-Framework für strukturiertes Logging und Diagnostik.

• smartmontools: Eine Tool-Sammlung zur Überprüfung von SMART-Gesundheitsdaten von Speichermedien, einschließlich SSD-Schreibzählern auf unterstützten Laufwerken.

• Hacker News: Die Diskussionsplattform, auf der der Codex-Logging-Bericht größere Aufmerksamkeit unter Entwicklern erregte.

Verwandte Links

• Codex SQLite-Feedback-Protokolle, Issue #28224: Das zentrale GitHub-Issue, das die gemeldete Schreibschätzung von 640 TB/Jahr und die Belege dokumentiert.

• Protokollierung jedes Responses-WebSocket-Ereignisses stoppen #29432: Einer der zusammengeführten PRs, die als Teil der Arbeit zur Reduzierung der Protokollierung aufgeführt sind.

• Störende Ziele aus persistenten Protokollen filtern #29457: Der PR konzentrierte sich darauf, störende Ziele der persistenten Protokollierung herauszufiltern.

• Persistierung überbrückter Protokollereignisse stoppen #29599: Der Folge-PR zielte darauf ab, die Persistierung überbrückter Abhängigkeits-Protokollereignisse zu stoppen.

• Hacker-News-Diskussion: Community-Diskussion über Codex-Protokollierung, SSD-Schreibvorgänge und die Qualität von KI-Coding-Tools.

• OpenAI Codex CLI README: Offizielle README des Repositorys zur Installation und Ausführung der Codex CLI.

• SQLite-WAL-Dokumentation: Offizielle Erklärung zu WAL-Dateien, Checkpoints und Leistungsaspekten.