# Codex writes SQLite logs, threatens SSD endurance > Source: > Published: 2026-06-22 08:14:18.653122+00:00 # Codex writes SQLite logs, threatens SSD endurance In an issue filed on the openai/codex GitHub repository (issue #28224), a user reported that the Codex CLI continuously writes large SQLite feedback logs, located at ~/.codex/logs_2.sqlite, ~/.codex/logs_2.sqlite-wal, and ~/.codex/logs_2.sqlite-shm. The reporter measured about **37 TB** written to their main SSD after roughly **21 days of uptime**, which they extrapolated to roughly **640 TB/year**. The issue note connects that extrapolation to endurance figures by observing that **1 TB** consumer SSDs would see about **640 full-drive writes per year**, and many consumer drives list ratings near **600 TBW**, implying the observed logging rate could consume an SSD's warranted write endurance in under a year. The report includes retained-row counts and process-level checks attributing the continuous writes to Codex's SQLite logs. ### What happened In an issue filed on the openai/codex GitHub repository (issue #28224), 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**, and the issue text extrapolates that to roughly **640 TB/year**, noting that on a **1 TB** SSD this equates to about **640 full-drive writes per year**, compared to common consumer endurance ratings near **600 TBW**. ### Technical details The issue includes process- and file-level checks that identify the Codex SQLite files as the primary continuous writers. The reporter provided retained-row counts inside logs_2.sqlite and observed continuous WAL activity tied to the Codex process. Those artifacts are logged within the GitHub issue as evidence. ### Editorial analysis Persistent, high-volume local logging into a small SQLite store can generate sustained write amplification via the WAL (-wal) file and frequent checkpoints; industry experience shows this pattern can rapidly increase SSD write cycles on long-running developer tooling and client-side agents. ### Context and significance For practitioners, this is a reminder that local feedback collection and verbose client logging can have hardware costs, especially on consumer-grade SSDs with finite TBW ratings. Similar issues have prompted changes to logging frequency, batching, or configurable retention in other developer tools. ### What to watch Observers should watch for responses or fixes on the openai/codex repository, such as opt-in logging, reduced write frequency, configurable retention, or migration to less write-intensive telemetry mechanisms. Also monitor related issue threads for reproducible metrics on different platforms and SSD models. ## Scoring Rationale The issue documents a concrete measurement that could affect developer workflows and device reliability, making it notable for practitioners running long-lived client tooling. It is not a broad-platform vulnerability, so its industry impact is meaningful but limited to deployments and tooling configurations. Practice interview problems based on real data 1,500+ SQL & Python problems across 15 industry datasets — the exact type of data you work with. [Try 250 free problems](/problems)