Codex-Logging-Bug kann Schreibvorgänge im TB-Bereich auf lokalen SSDs verursachen und die SSD-Lebensdauer schnell aufbrauchen

 (github.com/openai)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Codex schreibt fortlaufend große Datenmengen in eine lokale SQLite-Feedback-Log-DB; in einer Benutzerumgebung wurden nach 21 Tagen Laufzeit etwa 37 TB auf die Haupt-SSD geschrieben
  • Hochgerechnet entspricht das etwa 640 TB pro Jahr, also bei einer 1-TB-SSD rund 640 vollständigen Laufwerksschreibvorgängen pro Jahr; damit könnte die garantierte Lebensdauer mancher Consumer-SSDs (ca. 600 TBW) in weniger als einem Jahr aufgebraucht werden
  • Es werden nur etwa 500.000 Zeilen aufbewahrt, aber der AUTOINCREMENT-Zähler überschritt 5,5 Milliarden IDs, was auf eine Lücke von etwa dem 10.000-Fachen zwischen aufbewahrten Zeilen und kumulativen Insert-IDs hinweist
  • Ursache ist, dass der SQLite-Feedback-Log-Sink mit dem globalen TRACE-Standardwert (Targets::new().with_default(Level::TRACE)) konfiguriert wurde und dadurch interne Logs aus Abhängigkeiten sowie große rohe Protokoll-Payloads dauerhaft mitschreibt
  • Am 22. Juni 2026 wurden zwei PRs zusammengeführt, die etwa 85 % der Logs blockieren; damit wurde das Issue geschlossen

Zentrale Symptome und Auswirkungsbereich

  • Codex verursacht fortlaufend große Schreibvorgänge in folgenden Dateien
    • ~/.codex/logs_2.sqlite
    • ~/.codex/logs_2.sqlite-wal
    • ~/.codex/logs_2.sqlite-shm
  • Nach 21 Tagen Laufzeit wurden etwa 37 TB auf die Haupt-SSD geschrieben; Prüfungen auf Prozess- und Dateiebene bestätigten das Codex-SQLite-Log als wesentliche Quelle dauerhafter Schreibvorgänge
  • Auf ein Jahr hochgerechnet etwa 640 TB, was bei einer 1-TB-SSD ungefähr 640 vollständigen Laufwerksschreibvorgängen pro Jahr entspricht
  • Manche Consumer-SSDs sind nur für etwa 600 TBW ausgelegt, sodass ihre garantierte Schreib-Lebensdauer in weniger als einem Jahr erreicht werden könnte

Belegdaten

  • Evidence1 — Schreibverstärkung (write amplification)

    • Aktuelle Größe der Datei logs_2.sqlite: 1,2 GiB
    • Aktuell aufbewahrte Zeilen: 506.149
    • Kumulativ vergebene Row-ID: 5.543.677.486
    • Zwischen aufbewahrten Zeilen (ca. 0,5 Mio.) und kumulativen Insert-IDs (5,5 Mrd.+) besteht ein Abstand von etwa dem 10.000-Fachen; selbst ohne WAL, Indizes, Pruning, Checkpoints, Seiten-Rewrites und gerätebedingte Verstärkung wird ein historischer Log-Churn im Umfang von über 10 TB geschätzt

  • Evidence2 — Verteilung nach Level/Ziel

    • 681.774 aufbewahrte Zeilen, geschätzter Inhalt der aufbewahrten Logs etwa 1.035,6 MiB
    • Anteil nach Level: TRACE 70,7 %, INFO 25,7 %, DEBUG 3,0 %, WARN 0,6 %
    • Größte target+level-Paare
      • codex_api::endpoint::responses_websocket (TRACE) 527,4 MiB
      • codex_otel.log_only (INFO) 141,2 MiB
      • codex_otel.trace_safe (INFO) 121,2 MiB
      • log (TRACE) 97,4 MiB
    • Die Hauptquellen sind globale TRACE-Logs, gespiegelte Telemetrie-Logs und das Mitschreiben roher WebSocket-/SSE-Payloads
    • codex_otel.log_only + codex_otel.trace_safe machen zusätzlich 25,3 % aus; durch Filterung dieser Kategorien ließen sich in der Stichprobe etwa 96 % der Bytes aufbewahrter Logs entfernen
    • Die häufigste TRACE-Quelle (target=log) umfasst viele Low-Level-Einträge wie inotify event (z. B. ld.so.cache 128.764-mal), interne Aufrufe von tokio-tungstenite und WouldBlock

  • Messung der Schreibverstärkung

    • In einer 15-Sekunden-Stichprobe blieben die aufbewahrten Zeilen bei 681.774 konstant, während etwa 36.211 Zeilen eingefügt wurden
    • Schreibverstärkung entsteht durch ein wiederholtes Insert-and-Prune-Muster aus Einfügen → Indexierung → WAL-Schreiben → Pruning

Vermutete Ursache

  • Der SQLite-Feedback-Log-Sink wurde mit dem globalen TRACE-Standardwert (Targets::new().with_default(Level::TRACE)) eingerichtet
  • Dadurch werden alle Targets auf TRACE-Level dauerhaft gespeichert, einschließlich interner/abhängigkeitsbezogener Logs und großer roher Protokoll-Payloads

Vorgeschlagene Korrekturrichtung

  • Das Feedback-Logging beibehalten, aber den standardmäßig dauerhaft gespeicherten Umfang einschränken
    • Keinen globalen TRACE-Wert für den SQLite-Feedback-Log-Sink verwenden
    • Den Schwellenwert für Rauschen mit geringem Nutzwert wie target=log, hyper_util, interne tokio-tungstenite-Logs, inotify-Spam und Low-Level-Logs des OpenTelemetry-SDK anheben oder diese entfernen
    • Statt vollständiger Speicherung roher WebSocket-/SSE-Payloads nur Zusammenfassungen speichern (Ereignistyp, Dauer, Erfolg/Fehlschlag, Token-Nutzung, Payload-Größe in Bytes)
    • Gespiegelte Events von codex_otel.log_only / codex_otel.trace_safe nur dann speichern, wenn sie für Debugging tatsächlich nützlich sind
    • Ein Cap nur pro Thread reicht nicht aus; zusätzlich sollte eine globale Obergrenze für Größe/Schreibvolumen der Log-DB eingeführt werden
  • Eine Option wie sqlite_logs_enabled = false ist ebenfalls nützlich, aber der Kern der Lösung ist eine bessere Standardfilterung

Reproduktionsberichte auf mehreren Plattformen

  • macOS

    • Unter macOS 15.7.7 / Codex 26.616.51431 wurden für logs_2.sqlite 113M, MAX(id)=34,277,360 und 31.405 aufbewahrte Zeilen gemessen; in zwei 60-Sekunden-Stichproben wurden etwa 60 Schreibvorgänge pro Sekunde beobachtet
    • Für Sitzungen von 1–2 Stunden wurde berichtet, dass der codex-Prozess etwa 50 GB geschrieben hat

  • Windows

    • Unter Codex Desktop für Windows (codex.exe app-server --analytics-default-enabled) wurden trotz RUST_LOG=warn und ohne explizite TRACE-Konfiguration fortlaufend TRACE-Zeilen eingefügt
    • Etwa 71.000 aufbewahrte Zeilen, und der logs-Wert in sqlite_sequence lag über 18,5 Mio., was auf umfangreichen früheren Insert/Prune-Churn hindeutet
    • In einer 10-Minuten-Verteilung gab es 1.812 TRACE-Zeilen; zu den wichtigsten TRACE-Targets gehörten codex_api::endpoint::responses_websocket (3,5 MB+) und codex_api::sse::responses
    • Erwartetes Verhalten: Bei RUST_LOG=warn sollten interne/abhängigkeitsbezogene TRACE-Logs und große Payloads nicht dauerhaft gespeichert werden

Zusätzliche Risiken und temporäre Gegenmaßnahmen

  • Risiko von Datenverlust

    • Wenn der Datenträger voll ist, kann unter Linux nach einem Neustart die Anmeldung fehlschlagen
    • Der Codex-Modus /goal kann versuchen, Speicherplatz freizumachen, und dabei Dateien/Ordner löschen, was zu Datenverlust führen kann

  • Skripte zur vorübergehenden Abhilfe

    • trim-codex-wal.sh, das ein laufendes WAL trimmt (PRAGMA wal_checkpoint(TRUNCATE)), kann per cron alle 15 Minuten ausgeführt werden
    • fix-codex-wal.sh, das Log-/WAL-Dateien löscht und anschließend Codex-bezogenen Prozessen SIGTERM → SIGKILL sendet, um sofort Speicherplatz freizugeben
    • Wenn ein SQLite-Trigger (block_log_inserts) hinzugefügt wird, der Inserts in die Tabelle logs ignoriert, wächst das WAL nicht weiter; zum Rückgängigmachen dient DROP TRIGGER IF EXISTS block_log_inserts
      • Da VACUUM die DB neu schreibt, kann dies bei großen Dateien einmalig sehr große Schreibvorgänge auslösen; empfohlen wird daher, erst den Trigger zu setzen und das Stoppen des WAL-Wachstums zu bestätigen und danach DELETE/VACUUM auszuführen
      • Da dies eine Änderung an einem privaten SQLite-Schema ist, könnten künftige Codex-Updates/Migrationen Tabellen neu anlegen oder Trigger entfernen
    • Bis ein dauerhafter Fix vorliegt, wurde auch vorgeschlagen, diese DB auf einer Ramdisk abzulegen, um SSD-Schäden zu vermeiden

Lösung und Abschluss

  • Am 22. Juni 2026 wurde das Issue nach dem Merge von zwei PRs als erledigt markiert, da dadurch etwa 85 % weniger Logs anfielen
    • Logging aller Responses-WebSocket-Events beendet (#29432)
    • Filterung von Noise-Targets aus persistenten Logs (#29457)
  • Ein separat vorgeschlagener Patch ersetzt globales TRACE durch standardmäßige Speicherung ab INFO+ und hebt codex_otel.log_only, codex_otel.trace_safe, hyper_util, log, opentelemetry_sdk usw. auf WARN+ an
  • Die Änderungen wurden in rust-v0.142.0 veröffentlicht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Hacker-News-Kommentare

  • Ich halte Codex für eines der berüchtigtsten Beispiele von Slopware
    Auf macOS zieht es 100 % der GPU allein dafür, Spinner-Meldungen anzuzeigen, selbst wenn man nur das Fenster sichtbar lässt
    Auf einem MBP M5 erreicht allein die Spinner-Meldung 100 % GPU-Auslastung, und weil der Lüfter die meiste Zeit beim Warten auf das Modell laut läuft, sollte man im Akkubetrieb vorsichtig sein
    Dieses Issue ist seit fast 6 Monaten auf GitHub, vermutlich schon seit der Veröffentlichung dieses per Vibe Coding zusammengezimmerten Durcheinanders
    Selbst wenn man es selbst beheben wollte, geht das nicht, weil es aus irgendeinem Grund Closed Source ist
    Es gibt viele Debatten darüber, welches Modell besser ist und ob Vibe Coding praktikabel ist, aber das scheint mir ungefähr das Niveau zu sein, das selbst eines der am besten ausgestatteten Unternehmen bei Finanzierung, Personal und Modellfähigkeiten mit Vibe Coding zustande bringt
    Wenn der CEO bereits gesagt hat, man konzentriere sich aufs „Coding“, dann wirkt so ein schwerer Fehler wie ein Zeichen dafür, dass intern wirklich etwas kaputt ist, und auf Polymarket glaubt inzwischen fast niemand mehr, dass OpenAI bald wieder ein führendes Modell herausbringt
    Das ist tragisch, weil die Welt einen Konkurrenten zu Anthropic braucht

    • Direkt daneben steht auch Claude Code, also sollte man es bei Beispielen für Slopware nicht auslassen
    • Wenn KI 10-fache Produktivität bringt und AGI oder ASI nahe ist, verstehe ich nicht, wie Produkte wie Codex oder Claude Code CLI immer noch so miserabel sein können
      Man sollte meinen, die „agentische KI-Revolution“ hätte solche Probleme längst lösen müssen
      Hoffentlich heißt es intern nicht gerade „Bitte warten, Verarbeitung läuft“ oder „zu schwierige Aufgabe“
    • Als ich in einer Organisation gearbeitet habe, die grundsätzlich alles als Open Source veröffentlichte, gab es nur einen Grund, etwas geheim zu halten, selbst bei Side Projects: Scham
      Niemand will das öffentliche Gesicht einer Codebase sein, die nach Müll aussieht
      Wenn man mit genau diesem Code dann auch noch absurde Preise rechtfertigt, dürfte diese Last etwa dreimal so groß sein
    • Nicht nur Codex, auch die ChatGPT-App auf macOS frisst, wenn sie ein paar Stunden offen bleibt, mit der Zeit 60 GB RAM und schießt alle anderen Apps ab
      Ich verstehe das nicht
      Selbst wenn ich Google AI Studio im Browser benutzen will, geht die CPU auf 100 %
      Am Ende muss man wohl alles selbst als App bauen
    • Anfangs hieß es, die Welt brauche Anthropic als Konkurrenten zu ChatGPT, und jetzt hat sich das komplett umgedreht

  • Auf X gibt es einen temporären Workaround für dieses Problem[1]
    sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"
    Außerdem hat jemand auf einem Notebook VACUUM FULL auf diese sqlite-Datei ausgeführt, wodurch sie von 27 GB auf 73 MB geschrumpft ist[2]
    [1]: https://xcancel.com/bdsqlsz/status/2067964486615810369
    [2]: https://xcancel.com/jeethu/status/2068087449469780434

    • Wieder einmal retten Regeln auf Datenbankebene den Tag
    • Die echte Lösung ist, die Nutzung einzustellen und zu Pi zu wechseln

  • Alle kritisieren OpenAI, und das zu Recht, aber im Gegensatz zu Claude Code lässt sich Codex offiziell anpassen: https://github.com/openai/codex
    Es ist auch ziemlich leicht zu patchen

    • Das ist die CLI, nicht die proprietäre Codex-App, um die es hier geht

  • Schockierend
    Das Issue ist seit einer Woche offen, und soweit ich das sehe, schweigt OpenAI einfach
    Ich hätte gedacht, dass solche Anbieter bei solchen Problemen extrem sensibel reagieren, ich verstehe das nicht
    Sie haben doch sicher mehrere Agenten laufen, die potenzielle GitHub-Issues überwachen und Fixes vorschlagen? …Oder?
    Mit den eigenen Tools GitHub-Issues in Echtzeit zu beheben, sollte doch offensichtlich eine Kleinigkeit sein

    • OpenAI scheint beim Beheben von Issues ziemlich schwach zu sein
      Mein persönliches Lieblingsbeispiel ist #2472: Auf der GPT-5-Launch-Bühne wurde demonstriert, dass es „behoben“ sei, aber das Ticket ist noch offen und dieser „Fix“ wurde nicht einmal gemergt
      Der ursprüngliche Beitrag, der das herausgestellt hat, ist https://blog.tymscar.com/posts/openaiunmergeddemo/ und das Issue ist https://github.com/openai/openai-python/issues/2472
    • Es gab seit April ein GitHub-Issue zum gleichen Problem
      Ich benutze Codex viel und bin mit der Performance (UX und Output) sehr zufrieden, aber dass dieses Problem immer noch nicht behoben wurde, ist schwer nachzuvollziehen

  • Dieses Problem scheint behoben zu sein[0] und dürfte im nächsten Release enthalten sein
    [0] https://github.com/openai/codex/commit/e98d43ac372ddf7f513c0...

  • Vibe Coding hebt „move fast and break things“ auf ein völlig anderes Niveau

    • Bei uns in der Firma hängt gerade ein schwerwiegender großer Ausfall an irgendeinem per Vibe Coding erzeugten Müll von jemandem
    • Inzwischen geht uns sogar langsam das aus, was man noch kaputtmachen könnte
    • Wenn es keine technische Schuld gäbe, wäre Vibe Coding fürs Prototyping meist nützlich
      In echten Produkten werden echte Softwareingenieure niemals vollständig ersetzt werden

  • Etwas off topic, aber diese Firmen sollten aufhören, das Root-Verzeichnis des Repositories mit Claude.md oder copilot.md zuzumüllen
    Sie sollten sich einmal zusammensetzen und eine bekannte Ordnerstruktur wie docs/llm/* festlegen

  • Als Claude Code Ende letzten Jahres wegen der Latenz ein Desaster war, hat OpenAI einen fast sicheren Sieg verspielt
    In letzter Zeit hat Codex schon beim Start Eingabelatenz, während Claude Code zwar gelegentlich hängt, aber im Allgemeinen, wenn ich eine Taste drücke, … buchstäblich … genau das anzeigt, was ich gedrückt habe

    • Bei mir ist es genau umgekehrt
    • Claude Code fühlt sich für mich fast unbenutzbar an
      Wenn ich mehr als ein paar Wörter tippen will, muss ich immer in neovim schreiben

  • Das ist eigentlich ein sehr typischer Fehler
    Man hat mit Tracing-/Debug-Logs für alles aktiviert ausgeliefert, nur dass sich die Auswirkungen diesmal auf unübliche Weise zeigen
    Früher hätte ein Entwickler versehentlich Logging auf Trace-Level eingeschaltet, die App wäre katastrophal langsam geworden und es wäre sofort im nächsten Update behoben worden; verrückt ist heute, dass Speicher, CPU und Plattengeschwindigkeit so viel besser geworden sind, dass es sich nicht mehr sofort auf diese offensichtliche Weise zeigt

    • Dazu kommt, dass agentische Arbeit serverseitig stattfindet und ein dünner Client deshalb offenbar ruhig lokale Ressourcen komplett auffressen darf

  • Hoffentlich spendet jemand diesem tapferen Startup ein paar Tokens. Sie scheinen Hilfe zu brauchen