Fact-check verdict (updated July 20, 2026): The viral warning is built around a real and unusually well-documented Codex logging bug. Excessive local SQLite writes did create a credible SSD-endurance risk for some heavy users, and OpenAI engineers merged three mitigations. But the post goes beyond the available evidence when it says multiple Mac SSDs were definitively “fried” by Codex and that a massive number of users are still experiencing the same hardware-damaging defect. Current reports prove ongoing performance complaints; they do not yet prove widespread physical SSD failures or a single shared cause.
That distinction matters. “Nothing happened” is wrong. “Codex is currently destroying every Mac SSD” is also wrong. The useful answer sits between those extremes: a real write-amplification incident, a partial remediation trail, unresolved post-fix reports, and a need to measure your own system before drawing a hardware conclusion.
What the viral X post actually says
On July 19, 2026, Jun Song published an X post warning about Codex on Mac. When I checked it, X showed a July 19 timestamp and roughly 125,000 views. The post alleged that the Codex app was overloading Macs, permanently damaging SSDs, and forcing multiple users to seek repairs. It also said the issue had supposedly been fixed weeks earlier but was still being reported.
The post is authentic and current. It is not an old screenshot recycled without context. Its attached image is a screenshot of a same-day r/codex post titled “Codex is wearing out our devices”, which in turn points to another same-day thread about severe app slowdowns.
The sourcing chain is therefore real but weaker than it first appears:
- The X post makes a hardware-damage claim.
- Its screenshot cites a Reddit post asking whether Codex is safe.
- That Reddit post cites a second thread reporting lag, freezes, battery drain, heat, RAM use and restarts.
- Most of those fresh reports do not include disk-write measurements, SSD health data, repair invoices or a technical causal analysis.
In other words, the post points toward a genuine historical incident, but its fresh evidence mainly documents performance symptoms. It does not establish that all those symptoms are the old SQLite logging bug, much less that they caused physical SSD failure.
Claim-by-claim authenticity check
| Claim | Verdict | What the evidence supports |
|---|---|---|
| The X post is genuine and recent. | True | It was published by @jun_song on July 19, 2026 and linked a same-day Reddit discussion. |
| Codex produced excessive SSD writes. | True | Multiple GitHub reports include process-level, SQLite and macOS diagnostic evidence. The strongest report measured 37 TB written in 21 days. |
| The root cause was identified. | Substantially true | Evidence points to high-volume TRACE logging, repeated protocol/telemetry events and SQLite insert-prune/WAL churn. |
| OpenAI fixed the bug. | Partly true | Three fixes were merged and released. The original reporter saw about an 85% reduction, not zero writes, and newer reports remained open. |
| A massive number of users are seeing the exact same defect now. | Unproven | Many users report lag and resource problems, but most do not provide I/O evidence tying their symptoms to the same logging path. |
| Multiple SSDs were definitively fried by Codex. | Unverified | There are anecdotal failure claims, but no public multi-case dataset or diagnostic chain proving Codex caused those drive failures. |
The incident timeline: from quiet reports to a public fix
April 10: TRACE logging ignores the expected filter
The trail begins before the viral posts. In GitHub issue #17320, a Linux user reported that the Codex app server wrote about 5 MiB per second—and at times substantially more—to ~/.codex/logs_2.sqlite-wal while responses streamed. The reporter verified that RUST_LOG=warn was set, yet TRACE events were still being persisted to SQLite. One short response generated roughly 5,000 inserted log rows.
This was important because it ruled out a simple “the user enabled verbose logs” explanation. The persistent SQLite sink followed its own high-volume behaviour.
May 4: macOS records sustained writes during UI lag
A separate macOS issue, #21007, connected visible app sluggishness with an operating-system diagnostic. macOS recorded about 2.1 GB of file-backed writes over 648 seconds from the Codex process—an average of roughly 3.3 MB per second—even though memory pressure was low, swap was inactive and free storage was available.
That issue remains useful because it links the Mac experience in the viral post—slow scrolling, typing and image pasting—to concrete disk activity. It still does not prove permanent damage, but it does show that the concern was not invented after the fact.
May 23 to June 4: WAL growth and unbounded retention
In issue #24275, a Mac user watched the SQLite write-ahead log grow from about 63 MB to 147 MB in roughly two minutes during normal activity. The retained logical content was far smaller than the files on disk, a clue that write churn—not simply stored log size—was the problem.
Then issue #26374 described a continuously operated app-server whose feedback log reached 9.8 GB in about ten days. Full WebSocket payloads and mirrored telemetry entries dominated the database. These independent reports converged on the same subsystem.
June 14: the 37 TB report explains the amplification
The decisive report was GitHub issue #28224. Its author attributed about 37 TB of host writes over 21 days to the Codex feedback-log path. Extrapolated without change, that would be roughly 640 TB per year.
The most revealing number was not the database’s visible size. The SQLite table retained about half a million rows, while its autoincrement counter had passed 5.5 billion. In a 15-second sample, more than 36,000 rows were inserted even though the retained row count stayed flat. Codex was repeatedly inserting, indexing, writing to the WAL and pruning entries. A small-looking database could therefore generate a large amount of physical write activity.
The retained log sample was dominated by TRACE data and duplicated telemetry. High-frequency WebSocket events, network-library details, filesystem events and OpenTelemetry mirror records were being written far more aggressively than a production troubleshooting log needed.
June 22–23: three targeted fixes land
OpenAI contributor jif-oai merged three changes:
- PR #29432 stopped persisting every successful Responses WebSocket payload and removed duplicate per-event telemetry records while retaining counters, timing and error handling.
- PR #29457 filtered noisy bridged logs and duplicated OpenTelemetry targets from the SQLite sink.
- PR #29599 closed a filtering gap that still allowed bridged TRACE events to reach SQLite.
The first two changes shipped in Codex CLI 0.142.0 on June 22. The third shipped in 0.143.0 on July 8. The original issue author closed #28224 after observing roughly 85% fewer logs.
That is a real remediation, but “85% fewer” is not the same as a complete incident closure across every Codex surface, operating system and desktop build.
A practical postmortem: what failed and why
OpenAI has not published a formal incident postmortem that covers customer impact, affected versions, fleet-wide prevalence and hardware outcomes. The public GitHub trail is detailed enough to reconstruct a technical postmortem, but it should be labelled as an evidence-based reconstruction rather than an official company report.
1. An observability component became the workload
Feedback logs are supposed to help diagnose the product. Here, the logger captured events at a volume high enough to affect the product and the host machine. That reverses the intended relationship: instrumentation designed to observe work became a significant source of work.
2. TRACE was too broad for persistent production logging
The SQLite sink used a global TRACE default. That is appropriate only when carefully scoped and bounded. In a streaming agent, each response can contain many protocol events. Persisting raw successful payloads and low-level dependency activity multiplied a normal chat into thousands of database operations.
3. The same event could be represented more than once
A successful WebSocket event could generate a raw TRACE record plus telemetry log and trace records. The data was useful in aggregate, but persisting multiple rich representations of each success event created duplication without proportionate diagnostic value.
4. SQLite’s retained size hid lifetime writes
SQLite itself was not the villain. The combination of frequent inserts, indexes, write-ahead logging, checkpoints and pruning caused write amplification. Looking only at logs_2.sqlite in Finder could make the incident look smaller than it was. A database can remain near a fixed logical size while continuously rewriting pages underneath.
5. The first fix needed a follow-up
The 0.142.0 filter blocked obvious noisy targets, but bridged logs were evaluated under their original dependency target before being emitted as target=log. PR #29599 moved the rejection to the sink boundary. This is a familiar reliability lesson: filtering at one producer is less robust than enforcing a budget at the final persistence layer.
6. A global resource budget was missing
The original report recommended a global database size or write cap. The public fixes removed major sources of churn, but the larger design lesson remains: a long-running desktop agent needs visible budgets for disk writes, retained state, CPU, memory and background processes—not only token usage. My broader Codex workflow guide for marketers makes the same operational point from a productivity angle: automation needs boundaries you can inspect.
Did Codex actually “kill” SSDs?
Excessive writes do consume NAND endurance. SSD warranties commonly use total bytes written (TBW) as one limit. For comparison, Samsung’s official warranty lists 600 TBW for the 1 TB 990 PRO. At that reference point, 37 TB represents about 6.2% of the warranty-write allowance, and a sustained 640 TB per year would exceed it.
But three caveats are essential:
- TBW is not a self-destruct counter. Crossing a warranty endurance rating does not mean a drive instantly fails. It is a manufacturer’s coverage and endurance threshold, not an exact death date.
- The 37 TB figure came from one measured environment. Workload, uptime, version, background processes, drive capacity, controller behaviour and operating system all affect the outcome.
- A failed SSD does not prove Codex caused it. Causation requires a before-and-after health record, attributable write data, failure diagnostics and exclusion of competing causes. Public anecdotes rarely include that chain.
My conclusion is that “Codex could materially shorten SSD life under the documented high-write condition” is defensible. “Codex has been proven to fry multiple Mac SSDs” is not yet defensible from the public evidence.
What Reddit and Hacker News are saying
The forum discussion falls into four camps.
Measured concern
Several users supplied actual database sizes, WAL growth, row counts, process traces or host-write totals. These reports created the technical case and led to the fixes. A Hacker News discussion drew hundreds of comments and helped push the issue into wider view.
Post-fix scepticism
A July 3 Windows Desktop report, issue #31034, said high-volume TRACE records continued after upgrading the CLI to 0.142.0 and Desktop to build 26.623.13972. A 60-second sample recorded more than 5,000 inserted IDs and a WAL increase of roughly 23 MB. A related issue #29674 also remained open.
Those reports justify saying that the first remediation did not settle every environment. They do not prove that current Mac builds are writing at the original 37-TB pace.
Fresh performance complaints
The Reddit thread linked from the viral post includes users describing system-wide lag, freezes, heat, battery drain, memory spikes and the need to restart. Some report that switching from Desktop to the CLI avoids the slowdown; others report no problem on comparable hardware.
That pattern suggests a current Desktop regression may exist, but the thread mixes Mac and Windows systems, active tasks and idle behaviour, thermal theories, RAM complaints, graphics/rendering theories and disk suspicions. Without measurements, those symptoms should not all be collapsed into one SSD diagnosis.
Anecdotal hardware failures
A few commenters say an SSD failed or required replacement. Those reports deserve attention, not ridicule. They also remain anecdotes without sufficient public diagnostics to attribute the failure to Codex. The viral X post converts that uncertainty into certainty; the evidence does not.
How to check your Mac without panicking
If you use Codex Desktop heavily, take a measurement-first approach.
1. Update both the app and the core tooling
Install the newest Codex Desktop update available to you, fully quit the app, reopen it and confirm the app build. If you also use the CLI, run codex --version. The three public logging mitigations were present across CLI 0.142.0 and 0.143.0, so anything older should be treated as outdated for this incident.
Desktop and CLI version numbers are not always identical. Do not assume updating a global CLI package automatically replaces the core bundled inside a desktop build.
2. Use Activity Monitor to measure the process
Apple’s Activity Monitor disk view shows per-process data read and written. Establish a baseline with Codex closed, then open it and run a representative task for 15 to 30 minutes. Watch Codex and related app-server/helper processes. Record the app version, duration and bytes written.
3. Inspect the log files, but understand the limitation
ls -lh ~/.codex/logs_2.sqlite*Run that once before a test and again afterward. Rapid growth of the database or WAL is a warning signal. Stable file size does not prove zero churn because SQLite can insert and prune while reusing space; Activity Monitor or process-level I/O is the better check.
4. Do not delete a live WAL file
Do not blindly remove logs_2.sqlite-wal while Codex is running. A WAL is part of a live database transaction system. If you need to preserve evidence or free space, quit all Codex processes first, back up the relevant files, and follow an official or issue-specific procedure you understand.
Community members have used SQLite triggers to suppress TRACE inserts, but that is a workaround, not a neutral preference toggle. It can reduce diagnostic data, may be removed by an update and could complicate support. I would measure first, update second, and use a workaround only when current high write activity is reproducible.
5. Back up and check health warnings
If macOS reports that the storage needs service, Apple advises backing up data and arranging service. A good backup is worthwhile regardless of whether Codex is involved. Do not wait for a hardware warning before protecting irreplaceable work.
6. File a reproducible report
A useful GitHub report should include:
- Codex Desktop build and CLI version, if installed;
- Mac model, macOS version and available storage;
- whether the app was active or idle;
- bytes written over a fixed test period;
- before-and-after sizes for
logs_2.sqliteand its WAL; - whether the issue stops after fully quitting Desktop or when using the CLI;
- a minimal reproduction that does not expose private conversation data.
This evidence is more valuable than asking Codex itself to diagnose the machine and treating its answer as proof. A model-generated explanation can suggest hypotheses; operating-system measurements establish what actually happened.
What this incident means for AI tool buyers
For marketers and small teams, this is not merely an engineering curiosity. Local AI agents increasingly run for hours, open many files, start helper processes and maintain extensive state. Subscription price and token limits are only part of their operational cost.
When I evaluate a coding or marketing agent now, I would add five questions:
- Where does it store local state and logs?
- What retention, rotation and write caps exist?
- Can background activity be inspected and disabled?
- Does the vendor publish affected versions and remediation details?
- Can the workflow be moved to a safer surface if the desktop client regresses?
That last question is practical. Some current Reddit users say the Codex CLI avoids the Desktop slowdown. If you make that switch, use a disciplined workflow rather than treating the terminal as magic. My evidence-based Codex usage guide covers context and usage management, while the GPT-5.6 Sol, Terra and Luna workflow guide explains how to route different tasks without leaving long sessions running unnecessarily.
The broader lesson also applies beyond OpenAI. My analysis of the Claude Code quality incident reached a similar conclusion: treat vendor status labels as one input, and validate the behaviour that matters in your own workload. If you are building an AI adoption plan, connect those checks to a wider AI-in-digital-marketing operating model rather than choosing tools on launch-day claims alone.
Final verdict
The July 19 X post is authentic, highly recent and directionally right that Codex had a serious disk-write problem. The 37 TB incident was not a meme: it had technical evidence, a plausible root cause, merged fixes and release-note confirmation.
Where the post becomes misleading is certainty and scale. Its linked same-day evidence shows a cluster of real performance complaints, but it does not demonstrate that all those users are hitting the same SQLite bug. Nor does it prove that multiple Mac SSDs were physically destroyed by Codex.
The honest status as of July 20, 2026 is:
- Confirmed: Codex’s persistent logging caused excessive writes in documented environments.
- Confirmed: OpenAI merged and released three mitigations.
- Confirmed: some post-fix write and Desktop performance reports remain open.
- Not confirmed: widespread current Mac SSD destruction.
- Best response: update, measure, back up, and report reproducible evidence.
Frequently asked questions
Can Codex wear out an SSD?
Yes, any software that writes unusually large volumes can consume SSD endurance faster. Codex had a documented logging condition capable of generating excessive writes. That does not mean normal use of every current version will destroy a drive.
Was the 37 TB figure real?
It was a measurement reported by one GitHub user over 21 days and supported by process/file analysis and SQLite evidence. It should be treated as a credible case report, not a universal rate for every Codex installation.
Which Codex version fixed the logging bug?
Two major mitigations shipped in CLI 0.142.0, and a follow-up bridged-log fix shipped in 0.143.0. Desktop apps bundle their own components, so update Desktop separately and test the actual build you run.
Should I uninstall Codex?
Not automatically. First update it and measure disk activity during a controlled task. If high writes or severe system lag remain reproducible, quit Desktop and use another surface while you preserve diagnostics and report the issue.
Should I delete logs_2.sqlite?
Do not delete it or its WAL while Codex is running. If cleanup is necessary, fully quit related processes, back up the files and use a procedure you understand. The public issue contains community workarounds, but they can remove diagnostic data.
Has OpenAI published a formal postmortem?
I found detailed public issues, merged pull requests and release notes, but not a standalone official incident postmortem covering prevalence, affected builds, customer hardware impact and follow-up monitoring. The analysis above reconstructs the incident from those primary artifacts.
Editorial note: This fact-check was researched from the original X post, OpenAI’s public Codex repository, official release notes, Apple and SSD-manufacturer documentation, and current Reddit/Hacker News discussions. Community hardware-failure claims are labelled anecdotal unless supported by diagnostics. Facts were last checked on July 20, 2026.
