{"id":81462,"date":"2026-06-22T08:51:08","date_gmt":"2026-06-22T08:51:08","guid":{"rendered":"https:\/\/www.europesays.com\/ai\/81462\/"},"modified":"2026-06-22T08:51:08","modified_gmt":"2026-06-22T08:51:08","slug":"openai-codex-has-a-bug-that-could-kill-your-ssd-in-under-a-year","status":"publish","type":"post","link":"https:\/\/www.europesays.com\/ai\/81462\/","title":{"rendered":"OpenAI Codex has a bug that could kill your SSD in under a year"},"content":{"rendered":"

\t\t\"OpenAI<\/p>\n

\u24d8 Zac Wolff on Unsplash<\/p>\n

<\/a>This OpenAI Codex bug, if left unchecked, could burn through your drive’s entire warranted endurance in less than a year.<\/p>\n

OpenAI’s Codex CLI is quietly destroying SSDs. A misconfigured logging sink writes up to 640 TB\/year to a local database, which is way more than a typical drive’s lifetime endurance. The bug is still open on GitHub.<\/p>\n

If you use OpenAI’s Codex CLI<\/a> and leave it running for long periods of time, your SSD may be getting hammered. <\/p>\n

A GitHub user named 1996fanrui documented the issue on June 14<\/a> after noticing unusually high disk activity on their machine. After digging around, they found Codex was continuously hammering a local SQLite database (stored at ~\/.codex\/logs_2.sqlite) with diagnostic log writes. Over 21 days of uptime, the drive had absorbed around 37 TB of writes. Annualized, that’s roughly 640 terabytes per year. A typical 1 TB consumer SSD is rated for about 600 TBW lifetime \u2014 so this bug, if left unchecked, could burn through your drive’s entire warranted endurance in less than a year. <\/p>\n

The culprit is a logging configuration that probably nobody meant to ship to end users. Codex’s SQLite feedback sink runs at global TRACE level by default \u2014 the noisiest possible setting. It logs everything from raw WebSocket payloads to mundane filesystem events like opening ‘passwd’ and ‘ld.so.cache’. It also ignores the standard RUST_LOG environment variable, so there’s no obvious way to turn it down. Around 71% of the logged data is TRACE-level noise that has no real diagnostic purpose, for the average user at least. <\/p>\n

What makes it worse is write amplification. The database isn’t just growing, but also cycling through tens of thousands of insert-and-delete operations per minute. It is physically writing far more to the drive than the file size implies. <\/p>\n

This has actually been a known issue in various forms since at least April, with multiple related reports filed across the year. OpenAI’s recent changelog touched some SQLite reliability fixes but hasn’t addressed the write rate problem. The issue is still wide open. <\/p>\n

In the meantime, Linux<\/a> and macOS<\/a> users can symlink ‘~\/.codex\/logs_2.sqlite’ to ‘\/tmp\/’ to redirect writes to RAM. The file holds no conversation data, so losing it on reboot is fine.<\/p>\n

\t\"Anubhav<\/a>Anubhav Sharma<\/a> – Senior Tech Writer – 1698 articles published on Notebookcheck since 2024<\/p>\n

Most of my time goes into writing – and somehow it hasn\u2019t stopped being fun yet.
\nMy work mainly revolves around everyday tech, gaming, watches, DIY modding, and the occasional piece on tech-policy chaos when companies and governments clash. I try to keep things simple and honest, without sounding like a product brochure.
\nI have a Bachelor\u2019s degree in Computer Science Engineering and an Associate Degree in English Studies from the College of New Caledonia in British Columbia, Canada.
\nAway from articles and deadlines, life usually shifts to making music, taking photos, or trying to finish games that should have been completed months ago.<\/p>\n","protected":false},"excerpt":{"rendered":"\u24d8 Zac Wolff on Unsplash This OpenAI Codex bug, if left unchecked, could burn through your drive’s entire…\n","protected":false},"author":2,"featured_media":81463,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[23677,44423,34463,2317,1789,32145,44425,44428,3282,23678,4114,333,20758,8345,23676,4117,157,1635,3597,39644,6843,735,6342,44424,44422,763,44426,23675,23674,642,44427],"class_list":["post-81462","post","type-post","status-publish","format-standard","has-post-thumbnail","category-openai","tag-benchmarks","tag-bug","tag-cli","tag-codex","tag-database","tag-diagnostics","tag-endurance","tag-firmware","tag-github","tag-graphics-card","tag-laptop","tag-linux","tag-logging","tag-macos","tag-netbook","tag-notebook","tag-openai","tag-performance","tag-processor","tag-reliability","tag-reports","tag-review","tag-reviews","tag-sqlite","tag-ssd","tag-storage","tag-tbw","tag-test","tag-tests","tag-websocket","tag-writes"],"_links":{"self":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts\/81462","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/comments?post=81462"}],"version-history":[{"count":0,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts\/81462\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/media\/81463"}],"wp:attachment":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/media?parent=81462"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/categories?post=81462"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/tags?post=81462"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}