- SSD Writes: Rui Fan, a GitHub issue author, reported 37 TB over 21 days, annualized to roughly 640 TB per year.
- Local Logs: The problem centers on SQLite feedback logs and TRACE-level write amplification, not remote telemetry storage.
- Fix Path: OpenAI-linked pull requests reduced noisy SQLite persistence, but a later desktop issue kept verification open.
- Build Check: The temporary RAM redirect moves logs off SSDs, but updated Codex builds must stop TRACE writes.
OpenAI’s Codex coding agent can write up to 640 terabytes a year to local solid state drives through SQLite feedback logs, based on a long-running setup documented by Rui Fan, a GitHub issue author and an Apache Flink project management committee member. Fan reported the issue after measuring about 37 TB over roughly 21 days: “That extrapolates to roughly 640 TB/year.”
Scope matters. Fan’s measurement covers one machine, not every Codex install, but the scale is alarming because some 1 TB consumer SSDs carry a limit of 600 terabytes written (TBW), a common endurance measure. OpenAI engineers were aware of the logging problem and working on fixes after high-volume diagnostic data was found to create more disk activity than expected.
Why Local Logs Threaten SSD Endurance
OpenAI’s Codex CLI command-line agent is designed to read, change, and run code in a selected local directory.
Local storage becomes the pressure point when agent convenience meets endurance. A coding assistant that watches a repository, streams logs, and maintains telemetry often runs for hours while terminal sessions stay open. Large TRACE payloads plus pruning turn each cycle into NAND churn while the retained database size stays ordinary.
Continuous churn, not file growth, drives the storage cost. Fan’s setup centered on local SQLite feedback logs, including the logs_2.sqlite database and companion write-ahead log (WAL) files. SQLite is a small local database format, and WAL pages write additional data to disk even when the main database seems stable.
TRACE-level logging, a very verbose diagnostic mode, widened the problem because it preserved fine-grained events that many users would rarely inspect. Codex’s SQLite feedback sink appears to have run at a global TRACE default, with raw WebSocket payloads and filesystem events becoming part of the local churn. Verbose local persistence put the storage burden on diagnostic write volume on the user’s machine, not on a growing project file or a cloud telemetry archive.
Fan’s June 14 snapshot made the endurance risk visible without obvious file growth. A 1.2 GiB database held 506,149 retained rows, yet allocated row IDs had climbed beyond 5.5 billion. In a 15-second sample, 36,211 rows arrived while retained count stayed flat, and TRACE retained bytes represented about 70.7% of the retained total, with codex_otel.log_only and codex_otel.trace_safe adding another 25.3%.
Write amplification hides from file-size monitoring when rows and WAL pages turn over while visible size stays roughly stable. The write-amplification mechanism shifts the practical risk toward hardware wear rather than remote telemetry retention, because local diagnostic records stay on the user’s device unless included in feedback.
OpenAI’s newer Codex Windows sandbox treats local file, network, and command execution as product controls on developer PCs, but sustained storage churn sits outside those safeguards. SSD endurance becomes a separate local-risk layer for persistent CLI or desktop users. For compact laptops with soldered storage, abnormal writes narrow the margin before repair becomes a device-level problem.
Operating-system disk-write counters, the Codex data directory, and the logs_2.sqlite WAL file might only surface after-the-fact indicators of abnormal churn. A product-level fix has to reduce unnecessary persistence at the logging sink before users have to diagnose wear from the outside.
Fixes Have Landed but Verification Remains
Fixes began landing by June 23. Pull request 29432 stopped persisting every successful WebSocket payload at TRACE level while keeping counters, timing metrics, parsing, and error handling. Pull request 29457 filtered noisy targets from the SQLite sink, shared the filter across app-server and terminal UI paths, and left remote OpenTelemetry export unchanged.
Pull request 29599 then rejected bridged log events inside the SQLite sink, closing a path able to bypass the earlier filter through the original dependency target. Codex desktop users still need a build-level check: on June 27, a desktop user reported that version 26.623.31921 on macOS kept persisting TRACE-level rows into logs_2.sqlite.
The temporary Linux and macOS workaround is a logs_2.sqlite /tmp redirect, moving writes to RAM while accepting that the file disappears on reboot because it holds no conversation data. Until users install a build with those sink filters, logs_2.sqlite and its WAL file remain the clearest local evidence of high-volume TRACE churn.
