Weeks after OpenAI declared victory over a logging bug that was chewing through developers' SSDs, Mac users say the Codex desktop app is still punishing their hardware — and this time, the symptoms go beyond disk writes.
A post on r/codex that climbed past 100 upvotes over the weekend reports that running the Codex app causes system-wide lag on Macs that persists even after the app is closed, with a full restart being the only reliable fix. Crucially, the poster says the slowdown isn't explained by ordinary CPU or memory pressure — and when they asked Codex itself to diagnose the problem, the agent blamed its own "excessive I/O" and graphics work.
A second thread on the subreddit corroborates the pattern across multiple users, though the severity appears to vary from machine to machine.
The bug OpenAI said it fixed
The frustration traces back to June, when GitHub issue #28224 revealed that Codex's local diagnostic logger was writing at TRACE level (the noisiest possible verbosity) to a SQLite database at ~/.codex/logs_2.sqlite, ignoring the RUST_LOG environment variable entirely.
Apache Flink PMC member Rui Fan measured the damage: "after about 21 days of uptime, the main SSD has written about 37 TB" — an extrapolated 640 TB per year, enough to burn through a typical consumer SSD's entire write-endurance warranty in under twelve months.
OpenAI shipped two fixes in the 0.142.0 release on June 22, cutting log volume by roughly 85% by the reporter's own measurement, with a third patch targeted at 0.143.0.
The issue was closed. Case apparently not closed: a follow-up report (issue #29876) filed just two days later documented a MacBook Air M4 still sustaining roughly 207 MB per minute of writes while Codex sat mostly idle, with a code_sign_clone cache folder ballooning to 12 GB. On machines with soldered storage — which is every modern MacBook — that wear is permanent.
Why Macs lag even after Codex closes
The persistent slowdown may have a separate culprit. GitHub issue #25719, still open since June 1, shows the Codex desktop app repeatedly triggering a runaway in macOS's own Gatekeeper daemon: syspolicyd spiking to 125–200% CPU and swelling past 8 GB of RAM the moment Codex launches.
Because syspolicyd is a system process that validates every app you open, a wedged instance keeps dragging the whole machine — even after Codex and its helper processes exit. That matches the Reddit reports almost exactly: lag that outlives the app and only clears on reboot.
The reporter verified that Codex's bundled "Computer Use" helper is properly signed and notarized, suggesting the fault lies in how the app repeatedly launches or re-validates its components — reportedly even when users disable those features in the config.
What Codex users should do now
There are no confirmed cases of drives failing outright, but the wear is real and cumulative. Mac and Linux users can check lifetime writes with smartctl -a /dev/nvme0n1 (via Homebrew); Windows users can read "Total Host Writes" in CrystalDiskInfo.
Update to the latest Codex build to pick up the 0.142.x logging fixes, and if writes remain high, the community workaround still applies: symlink ~/.codex/logs_2.sqlite to a RAM-backed path so the churn never touches flash. Until OpenAI addresses the syspolicyd interaction, users seeing post-Codex lag can quit the app and restart rather than fighting a wedged Gatekeeper.
OpenAI has not publicly commented on the renewed reports.