Hacker News

> Codex is one of the most infamous examples of slopware

Woah, let's not forget Claude code is right there

if we are at 10x with AI and near AGI or ASI, then how is it possible that these products (Codex, Claude Code CLI) are still such garbage?

shouldn't this "agentic AI revolution" have long solved this already?

no way they're over there saying "we are on it plz wait" or that "it's too much effort"?

Not only Codex, but I can't leave ChatGPT app in macOS open for few hours, because it will consume 60 gigabytes of RAM over time and crashes all the apps.

Mindboggling. Or can't use Google's AI Studio in browser because it takes 100% CPU.

Need to write own app for everything???

> It's a tragedy. The world needs competition to anthropic.

I agree, though Sam Altman's company is the last option I'd want to replace Claude with. I would sooner exhaust every open model.

> THE SPINNER MESSAGE CAUSES 100% GPU USAGE ON AN MBP M5!!

This seems to be a common Chromium problem across tons of software. GitHub has the same issue with its spinners, VSCode as well.

Well thank you for your service. I thought about trying out Codex after the disaster that is Claude Code. I'll be fine without either one on my machine

This software has been terrible for me. Burns tokens like crazy, and fails. Most times I try to use the browser plugin, it just says it can't use the plugin. When it does work, it takes minutes to click a button. Unusable workflow.

I ask to generate a png with an alpha channel. It can't. Instead, it outputs a chroma-keyed image, then generates a python script to remove chroma key (fails), then a js script (which also fails). Then my 5h allotment is up.

It's frustrating because if it worked as they advertise, it'd be an amazing tool.

> THE SPINNER MESSAGE CAUSES 100% GPU USAGE ON AN MBP M5!!

One conspiratorial idea I had was that this isn't a bug, and that Codex was actually doing computation on users' hardware under the guise of "thinking". Like Folding@home, or bitcoin mining malware, involuntarily on paying customers. Your usage is being subsidized by your personal compute hardware that you can't take advantage of unless it was being applied at massive scale.

This would make even more sense when you consider that thinking and response time metrics aren't publicly being tracked. There is an assumption that LLM interaction is being processed as fast as possible, but this doesn't align with the reality of fixed hardware and oversubscription. Of course throttling is occurring. So, if you can take advantage of local compute, delay the responses and you have even more access compute!

I find it difficult to believe that given the scale, number of users, and money involved, that someone hasn't fixed this "bug".

This was fixed long ago, if I'm thinking of the same bug. It was stuck in an inf loop all the time the codex window was open.

To be fair with Codex, you can use any harness you want with it. Access is not gatekeeper by a crappy full of slop electron app.

So just move to PI, or whatever.

Claude on the contrary, forces all plan users to use their horrible app, which, if you ever dared to use cowork, only once, will run a 2GB VM on app start, no f's given. at all.

Not justifying it. But if you use the official Codex app, thats on you. If you use the official Claude app, it's because you are forced to.

Sidenote unrelated to the post: since the Fable thing, and after serious thinking, I moved to open source models. I still have the basic OpenAI sub, but then easy lifting is now done elsewhere.

I have exactly the same problem with Time Machine spinner on macOS. It even doesn't rotate.

Somewhere should be rare specialists with diploma who are capable of fixing such problems with waiting lists for years ahead.

Building an open source native swift version that doesn’t have that bug: https://github.com/Lore-Hex/Quillcode

I had the exact same frustration and switched to Pi and have had zero complaints

is it closed source ? i can see the rust code in repo contrary to the JS in claude code repo, are you mixing them up ?

Pi mono is the only true harness. Everything else is crap

Claude code (desktop) and Codex (desktop) are both absolutely dogshit pieces of software. I can't pick which one is worse. I'd be sort of ashamed to say I actively worked on them, regardless of how they can empower people. Cursor's new UI is similarly terrible. They're all slowly getting better, but too slow for my taste.

They are incredibly slow in unpredictable ways, eat up memory at an insane rate, and just feel like they were built with no regards for UX. Like they crammed together all the engineers with no idea of how to build a coherent and predictable UI and let them loose on the product without proper designers.

The other day Codex (desktop) was eating up 70GB of RAM on my machine. What had I done? Literally nothing. I opened it and let it update once.

Another one with Codex was when I had a specific conversation where no activity was happening and which would make the app spin up all of my CPU cores, rendering it barely usable. It would take seconds to react to anything or update the UI. The conversation wasn't even in focus!!! Restarting the app wouldn't help. After I archived it, it suddenly got better

Claude Code Desktop used to be so, soo, soo slow and eat up so much RAM. It was unusable for anything other than playing around when I first tried it. It also didn't communicate any of what it would do. Using it was like living in a world with no affordances, constantly afraid of interacting with them and being faced with some sort of destructive action. Still, it has definitely been improving in terms of the UI experience.

Cursor's new agents mode suffers from similar issues. Obscenely slow, hogging CPU without anything going on, breaking with existing UX patterns (some of them already well implemented in their other, more polished, previous version), confusing buttons and labels which don't explain what to do and that sometimes do destructive operations on your code.

My favorite cursor absurdity is that if you use their workflow to create a worktree and the worktree setup script fails, the following happens:

1. The agent has no idea that it failed, let alone have any logs of the failure

2. Often you yourself don't get access to the logs of what failed in that script. Don't ask me, half the time it just says it failed with no further logs.

3. When you do get the logs, you cannot copy them in ANY way. You can't even select them. I have had to resort to taking a screenshot to do OCR on it

I've also had cursor repeatedly have concurrency/race condition bugs when creating multiple worktrees in parallel. I have 5 tasks, I spin them up all together so they can create 5 worktrees and they crash with random internal cursor errors. Wasn't the point of this abhorrent new UI you've stuffed me with to enable parallelism?

It's like people aren't even testing the shit they ship. Which I guess they aren't.

I'm a big believer in AI and think it is changing the world and will continue to do so, but I almost get offended at how bad these products for which I am paying (sometimes quite a lot!) are. There's "move fast and break stuff" and then there's "build crap to call stuff".

Let me guess, there's also a bug where they train on all our data?

DB-level rules saving the day once again.

The real solution is to stop using it and switch to Pi

That's the CLI, not the codex app which is proprietary.

Yeah. Here I am sitting on a major incident at our company because someone’s vibe coded shit went seriously wrong.

We are running out of things to break.

as long as you don't have technical debt, vibe coding is mostly useful for prototyping. For a real product, true SWE will never be replaced

They're pretty bad about fixing issues it seems. My favorite is #2472 which they demonstrated "fixing" on stage on the release of GPT 5, but the ticket is still open and the "fix" hasn't been merged. The original blog that flagged this fact https://blog.tymscar.com/posts/openaiunmergeddemo/ and the issue: https://github.com/openai/openai-python/issues/2472

There have been Issues on Github about the same problem since April. I'm using Codex a lot and I'm very happy with its performance (UX and output), but it's baffling they haven't fixed this problem.

Fwiw I have the exact opposite experience.

I find Claude Code nearly unusable. I always have to type in neovim if I’m typing anything more than a few words.

It helps too that agent work is done server side so you can hog all the local resources for your thin client.

It's because they use gpt-5.5-xhigh (the money making* model) to build it.

(*for them)

Decent sandbox + sandbox override experience with pi coding agent... pi-sandbox uses the same sandbox tech that claude code uses, although it uses a fork that's a little behind, and I'm not sure exactly why it uses a fork.

You can install pi, then install pi-sandbox locked to the current version. Here it is described how pi-sandbox plus an additional extension allow you to have the experience where a sandbox is used, but you can fall back to unsandboxed with approval required. https://github.com/carderne/pi-sandbox/issues/50

I don’t trust any agent to respect any boundaries. They might today. But tomorrow’s vibe coded slip update might break it in subtle ways.

My solution to this is to only run agents in a sandbox of my own making (a locked down Podman container).

what QA?

Every time you write a test that handles some data, you write an assertion about how much data is handled?

Come on, this is such an easy thing to forget to test. Don't act like there is some magical testing strategy that would have caught this

Then they can apply a clean solve, the cleanest solution.

It's fascinating how offensive some of this verbiage becomes to you when you see it attached to LLM output too much.

At least they could call someone who’s is absolutely right so that the tool can see its mistakes now

I don't see this. According to their docs, logs are no longer written: https://code.claude.com/docs/en/claude-directory

Using a RAM backed tmpfs would be a work-around as to not trash your SSD. It's doesn't fix underlying problem. It's incredibly poor design on OpenAIs part.

I've been bitten by this bug for several days, to the point where I had had to write a script to delete the WAL so that my server would stop getting locked up from a lack of disk space from codex logging.

You can find it here: https://github.com/openai/codex/issues/28224#issuecomment-47...

I have been making noise about this bug for a week, so I'm glad to see this is blowing up on HN.

We've gone from "you're holding it wrong" to "the training data was bad because humans suck too". Difference is, humans learn from their mistakes.

Lack of accountability is the cause here. People don't think before hitting the 'Publish' button. Their managers let them off the hook because the culture still allows making egregious mistakes, as long as there's an LLM to blame.

1. I bet that developer only made that mistake one time in their life. Humans learn from their mistakes, LLMs don't. If you rely on LLMs to generate all of your code, you can expect to run into the same issues again and again.

2. "One developer somewhere in the world made a bad mistake one time, so this represents the quality of all software devs everywhere". Maybe they were just a bad developer? Bad developers exist. I have never written a bug that has destroyed my users' hardware, and I think that writing such a bug is completely inexcusable in an enterprise environment with software that will be shipped to millions of users, as Codex is.

What are your thoughts on the SNR of the linked GitHub issue threads? Consider the volume of comments posted and the substance of each comment.

There are going to be sooooo many consulting opportunities after this wave.

> The operating system has historically trusted the applications not to do dumb things too much.

The OS is a thin layer providing an abstract and consistent interface regardless of the hardware configuration. Policing applications is mostly related to security and resources utilization, not moronic errors.

Moreover why isn't the bug fixed already? I thought programmers were obsolete now. Surely one of the leading AI labs has figured out full automation of software development end-to-end by now if that's so.

Because it's not an error. The software is working as the creators intended. The diagnostic data (trace logs) are intentionally being saved for debug purposes.

> I don't understand how Codex can blunder so badly. I imagine that even if they would be using vibe-coding, surely they must have some good engineers. So why is there such severe bugs?

I'd say this is also partly a problem of working under intense pressure and the demand to work faster and faster - even faster now with "AI". All these companies are competing with each other very aggressively and are driving their employees like horses in order to win the "AI" race.

> I don't understand how Codex can blunder so badly.

because they trust the AI too much (and seem to be fin with acting knowingly negligent)

the problem is

- AI tends to produces very convincing looking code, even if fully wrong

- AI does mistakes of kinds no human would do, at least no human who is also able to write convincing looking code

- code reviews are hard, a lot of devs, including senior devs, put a lot of implicit trust into the co-worker behaving "sane and non malicious". But AIs behave sometimes not so sane and in a way (wrt. trying to be convincing). In the worst case in ways which if it where a human you might consider to be them trying malicious sabotage the product

Like a "dump" example from work:

- AI randomly removes a HTML element id while doing other changes in jsx/react

- the PR has a lot of changes, the id removal line looks innocent, like some on the fly cleanup

- human reviewers have the bad tendency to often not look too much at deleted lines, only if they need reference to how a new line was before (but it's only a deleted line and no new line)

- you don't expect humans to randomly without reason delete important properties of components when changing other things

- you maybe would still have found it, but it's a emergency fix for a production issue

- it happens to miss integration tests, but happens to still matter a lot for one specific important for complicated reasons not properly tested flow (similar people tend to not test logging too much, at best the presence of needed info but hardly ever the absence of noise)

"Vibe coding" implies minimal to no human involvement. It doesn't matter how good of an engineer the person who typed the prompt was, they were not involved in writing or reviewing the code, so the end result will not reflect their skill. The whole point of vibe coding is making software engineers irrelevant.

People like to go on about how "good engineers review their AI code" but that's just not what's happening in reality. Not only is reviewing large amounts of AI generated code unpleasant and mentally taxing, it also negates most of the perceived productivity boost, so people are simply not doing it.

> Proper testing

There is no formal testing that would be expected to catch an issue like this. It can barely be classified as a bug, the logging is working as intended, just with negative side effects that weren't accounted for.

The only real way to proactively prevent an issue like this is for a human programmer to stop and think about this code as they're writing it and go "hmm, we're logging large amounts of data to disk at a fast pace here, this may be a bad idea". Without human involvement, this is just going to keep happening. All vibe coded software is bloated and unstable, I have yet to see a single counter-example.

> I don't understand how Codex can blunder so badly. I imagine that even if they would be using vibe-coding, surely they must have some good engineers. So why is there such severe bugs?

Because it was deemed not Hard Enough task for real engineer to look at, so AI was sent to do it with no supervision, just checking the effects.

Also overly excessive logging is probably useful to them in chasing some of the edge cases, the cost to users doesn't matter in the slightest to them

The truth of the matter is that any time that has been saved in writing the code must be spent on ensuring proper system design, reviewing the code, and most importantly of all, QA, which is an uncomfortable discussion for AI techbros who are peddling complete automation of the software profession.