This reddit thread is devoid of any useful information. Just fear and speculation.

A Github issue with actual data instead of just someone reposting info: https://github.com/openai/codex/issues/28224

Previously discussed: https://news.ycombinator.com/item?id=48626930

Looks like the issue was closed?

There’s a number of comments and linked threads suggesting it is not, but easier to just link the biggest thread than try to track all the subthreads.

Just like 99% of reddit threads these days unfortunately, lol

This comment should be updated or put lower on the list because it is factually incorrect.

Vibe code giveth, vibe code taketh.

Seems to be the GUI only? Meaning no one on Linux is affected, or any of the people just using the TUI, as far as I can tell. I've used codex for a some time, and my current drive is ~1 year old (7624 hours on), only 86TB written so far, ~1% of lifetime writes.

its gui only and i dont think it happen for everyone.i dont see it on my machine, but its good to check. didnt notice anything on cli nor gui, but i started gui only on last 2 versions

The GUI app does run the fan very hard and heat the laptop for something supposedly running on the cloud. If it is using my computer to cache things and assist with tasks, okay, but if it’s just revving the motor I don’t want it to.

Mine too, on windows. It seems to be some very aggressive and poorly planned rg (ripgrep) calls mostly, when running parallel sessions. Multiple simultanous Claude code sessions don't have same problem.

A related GitHub issue: https://github.com/openai/codex/issues/25719

Does writing to an SSD often really 'wear out' the device?

Yes, they have a finite number of writes. The controller keeps track of this so you can even see what % of your SSD life is remaining in that sense.

Interesting, thanks, had no idea

There are also some cases where this can be magnified by certain write patterns or system behaviours.

I think there was a case of Teslas having these sorts of failures at one point due to them writing logs quite aggressively.

Another example was MacOS causing rapid wear due to virtual memory swaps if I recall on devices with smaller amounts of RAM.

Those Teslas were controller-less SSDs IIRC, common in the cheap embedded world.

Modern proper SSDs for computers do their best to spread out the writes (TRIM, and other features). They still wear out of course, nothing can beat physics. But if you buy a 2TB drive, there's a lot of room to spread out the write cycles that a normal user probably never has to worry about (no normal user is going to hit 500TBs of writes that breaks a modern 2TB SSD write balancing algorithm)

But it probably should be noted that embedded controller-free SSDs have significant write amplification issues. Embedded systems assumed you were trying to save money and/or compute... and also assumed you didn't do too many writes. So they really weren't designed for the write cycles that Teslas logging system did.

Yes. Flash cells in SSDs are rated for a particular number of write cycles.

Yes. NAND cells can only be erased and rewritten a finite number of times.

OpenAI's first related fix was in 0.142.x on June 22 but apparently it wasn't sufficient and user have continued to complain. Seems like a thread with decent additional context: https://x.com/0x_kaize/status/2078872972245225586

A Github issue with actual data instead of just someone reposting info: https://github.com/openai/codex/issues/28224

Previously discussed: https://news.ycombinator.com/item?id=48626930

> Codex Desktop for macOS triggers a persistent macOS Gatekeeper/SystemPolicy loop after launch.

As a Linux guy, I recently did some macOS development and was incredibly annoyed by the "security" features, which seem designed to shift blame for security issues from Apple to users.

macOS is constantly throwing up security screens and warnings about completely normal programs the user knowingly installed and trusted.

If a developer pays for an Apple Developer account, signs their software, and a user knowingly downloads and installs it, that software should be allowed to run and do what the user wants.

I’ve been developing on MacOS for years and don’t think I’m familiar with what you’re talking about. I’m familiar with the warnings, but hardly ever see them.

I meant distributing software for macOS.

That’s fair. What’s the Apple-recommended way to avoid this? I interact with a lot of software and tend not to hit it but I also don’t really interact with downloaded executables

I assume Apple would prefer everyone use the Mac App Store exclusively? I'm not even sure if that solves the problem but it's a non-starter for me anyway.

You don't interact with downloaded executables? How do you procure your executables? From USB drives? Every single executable that didn't ship with the computer from the factory was downloaded. Even the ones built into the OS if you ever let it update.

When you download an unsigned program and try to launch it, you get a warning and refusal to run until you go to system settings / privacy and security, and allow the program to run from there.

It is super annoying when you first set up a Mac and is really over the top. Definitely geared more towards the average user rather than developers. But, once you get through the barrage of approvals during initial use you're basically good to go for the lifetime of that machine. That said, I really wish there was a "I know what I'm doing" checkbox to avoid a lot of that BS...

> That said, I really wish there was a "I know what I'm doing" checkbox to avoid a lot of that BS...

The "I know what I'm doing" approach is the absence of the checkbox. Each of these decisions matters, and gives you insight into what the programs you're installing are trying to do today, independent of what they did when you last installed them (and maybe audited them) five years ago. Neither default behavior of "disallow all" (which would prevent correct operation of many programs) or "allow all" (which would likely violate your trust assumptions) is safe -- thought and human decision-making based on your own risk model and your own intended use of the installed software is needed.

Fully disagree. I actively want to know when a program tries to access my hard drive and stuff…

I understand the motivation, but the implementation results in little more than security theater in practice.

If you say "yes", the program can do almost anything and you'll have no idea what it's actually doing. If you say "no", you often can't use it for its intended purpose.

They took the iOS model and applied it to their desktop OS and it's just lazy and broken.

At least 50% of the time I see these warnings, the application is attempting to access something I wouldn’t have expected to access. I’m very happy to have the option to say “no” in those cases, so I can either validate that it’s legitimate or delete the sloppy software before it messes things up.

It might be a lazy model, I imagine Apple could’ve done something better if they still gave a damn about desktop, but I’ll take this over nothing. It actively provides value to me.

Maybe Apple could have done better, but I’m not sure how. There is an option to ask for access to a given folder only (if the dev does its job right) in addition to either full access or not. At some point there has to be some kind of trust to be given.

Use "TUI"