Codex writes SQLite logs, threatens SSD endurance

In issue #28224 on the openai/codex GitHub repository (opened June 14, 2026), a user reported that the Codex CLI is continuously writing large amounts of data to the local SQLite feedback log database, specifically to ~/.codex/logs_2.sqlite, ~/.codex/logs_2.sqlite-wal, and ~/.codex/logs_2.sqlite-shm. The reporter measured approximately 37 TB of writes on their main SSD after about 21 days of uptime, extrapolating to roughly 640 TB/year - equivalent to about 640 full-drive writes per year on a 1 TB SSD, compared to common consumer endurance ratings near 600 TBW.

The issue identifies the SQLite feedback log sink as installed with a global TRACE-level default: Targets::new().with_default(Level::TRACE). This persists all targets at TRACE level by default, including dependency internals (tokio-tungstenite, hyper_util, inotify events), raw WebSocket/SSE payload bodies, and OpenTelemetry mirror events (codex_otel.log_only, codex_otel.trace_safe). TRACE-level entries account for roughly 70.7% of retained bytes in the sample; adding the two otel mirror targets brings the share to around 96% of retained log bytes that could theoretically be dropped without disabling feedback logs entirely.

A 15-second sample showed approximately 36,211 rows inserted while the retained row count stayed flat, confirming a continuous insert-and-prune cycle: rows are written to the WAL, indexed, then pruned - generating ongoing write I/O proportional to the logging rate regardless of the final database size on disk.

The issue links at least eight related reports on the same repository documenting the same logging behavior across Codex Desktop and CLI builds, including #17320 (excessive WAL writes during streaming), #24275 (Desktop SQLite growth during normal use), #22444 (WAL grows indefinitely when stale processes hold the file open), and #27911 (goals_1.sqlite write amplification at ~11 MB/s).

Narrow what is persisted by default - drop the global TRACE default, suppress low-value dependency noise, avoid storing full raw WebSocket/SSE payloads, and add a global logs DB size/write cap. An opt-out flag (sqlite_logs_enabled = false) is suggested as an escape hatch but not the primary fix.

Persistent, high-volume local logging into a WAL-backed SQLite store can generate sustained write amplification via continuous checkpointing; this is a known risk pattern in long-running developer tooling and client-side agents. For practitioners, this is a reminder that client-side telemetry and feedback collection can carry real hardware costs on consumer SSDs with finite TBW ratings. Monitoring the openai/codex repository for fixes - such as configurable log levels, retention limits, or reduced-write telemetry backends - is advisable for anyone running Codex CLI long-term on consumer hardware.