Mehrere Nutzer berichten, dass Codex Desktop beziehungsweise der Codex-App-Server während aktiver Sitzungen ungewöhnlich viele Daten in eine lokale SQLite-Protokolldatenbank schreibt. Ein öffentliches Fehlerprotokoll im offiziellen OpenAI-Codex-Repository dokumentiert unter Linux etwa fünf Megabyte Schreiblast pro Sekunde, kurzzeitig bis zu 16 Megabyte. Weitere Berichte nennen schnell wachsende Dateien namens logs_2.sqlite und logs_2.sqlite-wal.
Was technisch belegt ist
Der GitHub-Bericht enthält reproduzierbare Messungen mit Systemwerkzeugen und Abfragen der SQLite-Datenbank. Demnach wurden während der Ausgabe eines Modells zahlreiche Einträge der Stufe TRACE gespeichert, obwohl der Prozess mit einer restriktiveren Protokolleinstellung gestartet worden sei. Hinweise aus dem offenen Quellcode und weitere Fehlerberichte stützen, dass der lokale Protokollspeicher bei aktiver Nutzung erhebliche Schreiblast und Leistungsprobleme verursachen kann.
Damit ist ein konkretes Softwareproblem plausibel und öffentlich dokumentiert. Nicht belegt ist dagegen die pauschale Behauptung, Codex zerstöre SSDs oder habe bestimmte Laufwerksausfälle verursacht. Einzelne Nutzer bringen Defekte mit der Schreiblast in Verbindung, doch ohne Geräte- und Telemetriedaten lässt sich dieser Kausalzusammenhang nicht nachweisen. Die Lebensdauer einer SSD hängt zudem von Modell, Kapazität, bisheriger Nutzung, Temperatur und weiteren Faktoren ab.
Eine wachsende WAL-Datei ist außerdem nicht mit derselben Menge dauerhaft gespeicherter Nutzdaten gleichzusetzen. SQLite schreibt Änderungen zunächst in ein Write-Ahead-Log und überführt sie später in die Hauptdatenbank. Häufiges Einfügen, Löschen und erneutes Schreiben kann deshalb deutlich mehr physische Schreibarbeit erzeugen, als die sichtbare Dateigröße vermuten lässt. Umgekehrt beweist eine große Datei allein noch keinen drohenden Hardwaredefekt.
Moderne SSDs verteilen Schreibvorgänge über Speicherzellen und melden Gesundheitswerte. Ob die beobachtete Last relevant ist, lässt sich eher über längerfristige Systemmessungen und die vom Laufwerk gemeldeten Gesamtbytes beurteilen als über einen einzelnen Screenshot. Aussagen, ein Laufwerk werde nach Erreichen einer Grenze stets zuverlässig schreibgeschützt, wären ebenfalls zu pauschal: Das Verhalten hängt vom Controller und Fehlerbild ab.
Kein bestätigter Fix in einer bestimmten Version
In Community-Beiträgen wurde behauptet, eine bestimmte Version der App habe das Problem bereits vollständig behoben. In den geprüften offiziellen Quellen findet sich dafür kein belastbarer Nachweis. Auch ein RAM-Laufwerk oder ein Eingriff per Symlink wird im GitHub-Thread lediglich als inoffizieller Workaround vorgeschlagen. Solche Änderungen können Diagnoseinformationen verlieren lassen und sollten nicht als allgemein sichere Lösung dargestellt werden.
Wer eine hohe Schreiblast beobachtet, sollte zuerst Codex aktualisieren, die Anwendung vollständig neu starten und prüfen, ob das Verhalten mit der aktuellen Version reproduzierbar bleibt. Für einen Fehlerbericht sind App-Version, Betriebssystem, Größe der SQLite- und WAL-Dateien sowie eine zeitlich begrenzte Messung der Schreiblast hilfreicher als Vermutungen über bereits entstandenen Hardwareverschleiß.
Bei Firmenrechnern sollte zusätzlich geklärt werden, ob Sicherheits- oder Diagnosewerkzeuge dieselben Dateien überwachen und dadurch weitere Schreibzugriffe auslösen. Regelmäßige Datensicherungen sind unabhängig von Codex sinnvoll. Wer bereits Warnungen des Laufwerks, Dateisystemfehler oder Abstürze sieht, sollte die Arbeit stoppen und die IT beziehungsweise den Gerätehersteller einbeziehen, statt allein an der Logdatenbank zu experimentieren.
🎯 Was das für die Praxis bedeutet
1. Ruhig messen: Aktivitätsanzeige, Task-Manager oder Systemwerkzeuge können zeigen, ob Codex während einer Sitzung tatsächlich dauerhaft schreibt.
2. Aktualisieren und melden: Tritt das Problem in der neuesten Version weiter auf, sollte es mit reproduzierbaren Messwerten im offiziellen Codex-Repository gemeldet werden.
3. Keine riskanten Schnelllösungen: Datenbanken nicht löschen, verschieben oder per Symlink umleiten, ohne Codex zu beenden und eine Sicherung anzulegen. In verwalteten Unternehmensumgebungen gehört ein solcher Eingriff in die Hände der IT.
