Codex writes SQLite logs, threatens SSD endurance

The durable lesson is not one tool's bug but a design trap in long-running, client-side AI agents: verbose telemetry defaults can impose silent, sustained hardware cost on the user's machine. A TRACE-level log sink that persists every dependency event and raw protocol payload into a WAL-backed SQLite store generates write I/O proportional to the logging rate regardless of the final file size - so a database that looks small on disk can still burn through SSD endurance. If you ship or run client-side agents, treat the default log level and a write/retention cap as production-critical settings, not afterthoughts.

In issue #28224 on the openai/codex repository (opened June 14, 2026), a user reported the Codex CLI continuously writing large amounts of data to its local SQLite feedback log - ~/.codex/logs_2.sqlite plus its -wal and -shm files. The reporter measured roughly 37 TB of writes after about 21 days of uptime, extrapolating to about 640 TB/year, equivalent to around 640 full-drive writes per year on a 1 TB SSD versus common consumer endurance ratings near 600 TBW. The Register subsequently covered the issue, framing the wasted writes as a cost borne across many users.

The issue traces the behavior to the SQLite feedback log sink being installed with a global TRACE-level default, persisting dependency internals (tokio-tungstenite, hyper_util, inotify events), raw WebSocket and SSE payload bodies, and OpenTelemetry mirror events. In the reporter's sample, TRACE-level entries accounted for roughly 70 percent of retained bytes, and adding the two otel mirror targets pushed the theoretically droppable share to around 96 percent. A 15-second sample showed about 36,211 rows inserted while the retained row count stayed flat - the signature of a continuous insert-and-prune cycle that amplifies writes without growing the database.

The report links at least eight related issues documenting the same pattern across Codex Desktop and CLI, including excessive WAL writes during streaming and indefinite WAL growth when stale processes hold the file open. OpenAI has since largely addressed it: per the issue thread and Codex release notes, the default SQLite log level was lowered from TRACE to INFO and noise sources trimmed, with fixes landing in release 0.142.0 and follow-up work reported to cut roughly 85 percent of the log writes.

If you run Codex long-term on consumer hardware, update to 0.142.0 or later and verify the logs_2.sqlite write rate has dropped; more broadly, audit any client-side agent's telemetry defaults, retention caps, and whether raw protocol payloads are persisted locally.