OpenAI's Codex CLI contains an unpatched bug that is silently writing data to developers' local SSDs at a rate of roughly 640 terabytes per year — more than the entire rated lifetime endurance of a typical 1 TB consumer drive. The issue, documented on GitHub eight days ago and now drawing widespread developer attention, has received no official response or fix from OpenAI as of Monday, June 22, 2026.

If you run Codex CLI persistently, your drive may already be sustaining permanent, irreversible damage you cannot see in any standard disk-space tool.

The Rate That Breaks Your Drive

The numbers come from a June 14 report filed as GitHub Issue #28224 by a community developer identified as 1996fanrui. After noticing high disk activity, the developer traced it to a local SQLite database Codex maintains at ~/.codex/logs_2.sqlite. Over 21 days of uptime, their SSD had absorbed approximately 37 terabytes of writes from Codex alone. Annualized, that pace works out to roughly 640 terabytes per year.

A standard 1 TB consumer SSD carries a manufacturer endurance rating — measured in terabytes written, or TBW — of roughly 600 TBW over its entire service life. At Codex's measured write rate, the tool can exhaust a drive's full warranted endurance in less than twelve months.

Why the Damage Is Invisible Until It Is Too Late

What makes this bug particularly dangerous for developers is that it leaves no obvious footprint in standard monitoring. The SQLite database prunes rows as fast as it inserts them: a 15-second sample from Issue #28224 showed the logger inserting 36,211 rows while the total retained row count held essentially flat at 681,774. The logical file size shown by tools like du barely moves. A developer watching their filesystem quota would see nothing unusual.

What they would not see is the physical reality underneath: the SQLite database runs in WAL (Write-Ahead Logging) mode, a journaling architecture that appends every write to a separate -wal journal file before periodic checkpoint operations merge the data back into the main database. When tens of thousands of insert-and-delete cycles run every minute, the WAL checkpoint process generates physical flash writes that are dramatically higher than the logical data footprint would suggest. This is the phenomenon engineers call write amplification — actual bytes committed to NAND flash cells can be a multiple of the logical write load — and it is the mechanism that makes this bug dangerous rather than merely noisy.

The only reliable way to detect the damage is to read the drive's own SMART data. On Linux with an NVMe drive, sudo smartctl -a /dev/nvme0 | grep "Data Units Written" returns the physical write total directly. On a SATA SSD, the Total_LBAs_Written SMART attribute serves the same purpose.

The SQLite Logging Bug Explained

The root cause is a single misconfigured default in Codex's internal logging architecture. The SQLite feedback log sink is configured with the line Targets::new().with_default(Level::TRACE), which sets every logging target to TRACE level — the most verbose setting available in the logging framework, typically reserved for deep debugging sessions, never for shipping production software.

At TRACE level, the logger captures everything: raw WebSocket and SSE payload bodies, mundane filesystem events such as opening passwd and ld.so.cache, internal state from dependency libraries including tokio-tungstenite and hyper_util, and mirrored OpenTelemetry events. Analysis of the logged data in Issue #28224 shows that TRACE-level entries alone account for approximately 70.7% of all retained write bytes, with OpenTelemetry mirror events adding another 25.3%. Dropping just those categories would eliminate roughly 96% of the write volume while preserving any genuine diagnostic utility.

Making matters worse, the logger completely bypasses RUST_LOG — the standard environment variable that Rust applications use to control logging verbosity. This bypass was first documented separately in GitHub Issue #17320, filed on April 10, 2026. Even when a user or developer sets RUST_LOG=warn in their environment — a setting that should restrict output to warning-level messages and above — the SQLite sink continues writing at full TRACE verbosity. The standard control mechanism does not work.

The result is a logger that writes at maximum verbosity, bypasses the tool a user would reach for to quiet it, hides its volume behind a self-pruning file that looks calm in any filesystem view, and commits all that data to flash through a WAL checkpoint cycle that amplifies the physical write load beyond what the logical data size implies. Any one of these properties is a bug. All four together make the damage both severe and nearly undetectable.

A Pattern OpenAI Has Known About Since April

Issue #28224 is not the first record of this problem. GitHub Issue #17320, titled "Excessive SQLite WAL writes during streaming due to TRACE logs ignoring RUST_LOG," was filed on April 10, 2026 — more than ten weeks before the current story. That issue documents write rates of approximately 5 MiB/s observed during streaming, with peaks reaching 16 MiB/s. At least eight separate GitHub issues across the Codex repository document different symptoms of the same underlying logging behavior. OpenAI's June 2026 Codex changelogs include SQLite reliability fixes addressing database corruption and initialization failures, but none address the TRACE-level write-rate problem that drives SSD degradation.

As of publication, Issue #28224 has been open for eight days. OpenAI has issued no public statement, no official workaround, and no patch. Developers on Hacker News who surfaced the thread on Monday called the lack of response "baffling," with one practitioner asking whether OpenAI had internal tools actively monitoring and addressing GitHub issues in real time.

Who Faces the Most Risk

Not all Codex users are equally exposed. The developer who filed Issue #28224 ran Codex on a machine with continuous uptime over 21 days — the highest-exposure scenario. But the risk scales with any persistent use pattern.

Individual developers on modern laptops face the most acute consequence. Current ultrabooks and thin-and-light laptops almost universally ship with soldered NVMe drives. When a soldered drive wears out, the component cannot be swapped for a $60 replacement — the entire machine must be replaced. Endurance loss from a runaway logging process is permanent and warranty-defining.

Windows users are in a more constrained position than Linux and macOS users. A GitHub Issue filed two weeks ago (#27020) documents that on Windows with WSL2, the same Codex process produces sustained high disk I/O, with Windows Task Manager reporting 100% disk usage during Codex sessions. No workaround equivalent to the /tmp/ symlink has been documented for Windows.

A secondary risk now emerges on top of SSD wear: a separate issue filed June 20, 2026, documents that once logs_2.sqlite grows beyond approximately 200 MB, the Codex CLI begins crashing mid-session within 30 to 105 minutes of active use. For developers who have been running Codex for weeks or months without applying any workaround, the tool may already be approaching this threshold.

Codex CLI Workaround: What You Can Do Right Now

Until OpenAI ships a patch, Linux and macOS users have a stopgap. Symlinking ~/.codex/logs_2.sqlite to /tmp/ redirects all SQLite log writes to RAM (tmpfs) rather than the physical SSD. Because /tmp/ is RAM-backed, the data does not reach flash storage and is lost on every reboot — which is acceptable, because the log file contains no conversation data or meaningful state.

The Hacker News community has also documented an alternative approach: creating a SQLite trigger that blocks all inserts to the logs table, preventing writes entirely without redirecting the file. A third option documented in the thread is running VACUUM on the existing logs_2.sqlite file, which in at least one user's case shrank the database from 27 GB to 73 MB, recovering storage space already consumed.

To check whether your drive has already accumulated damage from this bug, read its SMART data before applying any workaround. On Linux with NVMe: sudo smartctl -a /dev/nvme0 | grep "Data Units Written". On SATA SSDs: read the Total_LBAs_Written attribute. Record the baseline number, leave Codex running idle for one hour, then read the counter again. If the delta is gigabytes, the bug is active on your system.

Windows users currently have no documented workaround equivalent to the symlink approach.

The Larger Pattern: AI Developer Tools and Silent Hardware Risk

This incident surfaces a category of risk that has no direct analogy in traditional software: AI coding agents that run persistently in the background, with elevated local filesystem access, can damage physical hardware with no visible warning, no user-facing error, and no log entry that a standard monitoring tool would flag.

OpenAI has been expanding Codex's local access aggressively. In April 2026 the tool gained full desktop computer-use capabilities on macOS. The same period introduced Chronicle, which periodically captures screenshots of the developer's screen. An agent with that degree of local access, shipping with a logger that bypasses its own verbosity controls, represents a quality-control gap that users would not ordinarily think to audit.

The lesson from Issue #28224 is specific: check your drive's SMART write counter if you run Codex CLI. The lesson from the pattern — a confirmed bug visible since April 2026 with no fix shipped by June — is about what systematic quality assurance looks like when tools are shipped rapidly and hardware consequences are silent.

Frequently Asked Questions

Is my SSD damaged if I have been running OpenAI Codex CLI?

Possibly, if you have been running it persistently for days or weeks. The only reliable way to check is to read your drive's SMART data using smartctl on Linux (command: sudo smartctl -a /dev/nvme0 | grep "Data Units Written") or CrystalDiskInfo on Windows, which displays the drive's lifetime bytes written. Compare a reading taken before and after an hour of Codex running idle. If the counter climbs by gigabytes per hour, the bug is active on your system. SSD wear from flash over-writes is irreversible.

What is the Codex CLI SSD bug and what causes it?

The Codex CLI ships a SQLite feedback log sink configured at global TRACE level — the most verbose logging setting — which captures internal dependency events, raw WebSocket payloads, and telemetry data that has no diagnostic value for ordinary use. The logger also bypasses RUST_LOG, the standard Rust environment variable for controlling log verbosity, so users cannot turn it down through normal means. Combined with SQLite's WAL (Write-Ahead Logging) mode, the continuous insert-delete cycles generate physical flash writes through WAL checkpointing that are far higher than the logical file size suggests — a mechanism called write amplification that accelerates SSD endurance consumption.

What can I do right now to protect my drive?

On Linux or macOS, redirect the SQLite log file to RAM by symlinking ~/.codex/logs_2.sqlite to /tmp/logs_2.sqlite. Because /tmp/ is RAM-backed, writes never reach flash storage. The log file contains no conversation history or meaningful user data, so losing it on reboot is safe. Windows users currently have no fully equivalent workaround documented. All users should monitor GitHub Issue #28224 for official patch notifications from OpenAI.

Could a bug like this happen in other AI coding tools?

Any developer tool that runs persistently, writes diagnostic logs locally, and ships with insufficiently audited default logging verbosity carries a version of this risk — especially if the logging sink bypasses the standard verbosity controls for that programming language. The specific mechanism here (SQLite WAL write amplification driven by TRACE-level defaults that ignore RUST_LOG) is Codex-specific. But the broader pattern — AI coding agents silently consuming hardware resources with no user-facing warning — is a category concern for any tool that combines persistent background execution with elevated local filesystem access.