Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Codex logging bug may write TBs to local SSDs

github.com

Post reply on HN
Print view View original

181–190 of 296 posts

Re: Codex logging bug may write TBs to local SSDs

#181

Post by epistasis »

Supermancho wrote: post #168
NamlchakKhandro wrote: post #117

Earlier quoted context omitted.

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

If Pi can't use my MCPs, it's too big a step backward. Is the common tooling: https://github.com/nicobailon/pi-mcp-adapter ?

I imagine the answer varies greatly but what use cases do people find for MCP over standard command line calls? The only time I use MCP is when I'm supposed to test that an MCP is working. Everything else is just incredibly clunky and ugly. For example, connecting to Linear to grab a ticket is far easier and cleaner to copy and paste the text rather than to have the agent call the MCP and look it up by ticket name.

I'm hoping I can find somebody else's MCP that could actually help me for once!

Re: Codex logging bug may write TBs to local SSDs

#182

Post by fps-hero »

b--l wrote: post #10

Codex is one of the most infamous examples of slopware. Just having the window unhidden on my mac will cause it to use 100% of the GPU displaying the spinner message. THE SPINNER MESSAGE CAUSES 100% GPU USAGE ON AN MBP M5!! So any time you're waiting on the model (which is 90% of the time), your fans will be blasting (careful, don't use it on battery). The issue is on github and close to 6 months old. Probably since…

> 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".

Re: Codex logging bug may write TBs to local SSDs

#183

Post by thewebguyd »

igleria wrote: post #67
r_lee wrote: post #64

Earlier quoted context omitted.

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"?

This is the biggest elephant in the room I have seen in my decade+ career. At the same time, look how bad Apple is in software compared to its hardware... It's not an AI only problem, it's almost like software in general gets a free pass on being very unsafe or low quality because no one wants to face the same "profit reducing red tape" that civil engineers or similar face.

> same "profit reducing red tape" that civil engineers or similar face.

I don't think we should ever head toward licensing/a credential body for software development, but I do think now is a good time to have discussions around liability for defective products.

A good start would be to stop allowing companies to disclaim all warranties of fitness for a particular purpose in their EULAs. The joke of Microsoft Copilot applies here where they have a big disclaimer that "Copilot is for entertainment purposes only" while advertising says otherwise. Not even the chrome EULA will agree that its fit for purpose as a web browser. The clause is a get out of jail free card that shifts all liability and risk to the end user.

Re: Codex logging bug may write TBs to local SSDs

#184

Post by CSMastermind »

fps-hero wrote: post #182
b--l wrote: post #10

Codex is one of the most infamous examples of slopware. Just having the window unhidden on my mac will cause it to use 100% of the GPU displaying the spinner message. THE SPINNER MESSAGE CAUSES 100% GPU USAGE ON AN MBP M5!! So any time you're waiting on the model (which is 90% of the time), your fans will be blasting (careful, don't use it on battery). The issue is on github and close to 6 months old. Probably since…

> 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 a…

Lol this was my theory as well.

Re: Codex logging bug may write TBs to local SSDs

#185

Post by drakythe »

i2km wrote: post #39

Shocking. Been open a week and AFAICT just silence from OpenAI. I just find it baffling. You'd think that these vendors would be very sensitive to this sort of issue. I mean, surely they have multiple agents hooked up to github monitoring potential issues and proposing fixes, right? ...right? Surely it should be trivial for them to have their own tools spinning away trying to fix all the github issues in real time...

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

Re: Codex logging bug may write TBs to local SSDs

#186

Post by thewebguyd »

geodel wrote: post #179
hombre_fatal wrote: post #172

Earlier quoted context omitted.

> Why do you "have to decide"? Let some agents go at both of those, isn't that what they claim people can just do? Because your code is still marching somewhere in tokens per second. You have to decide where they are allocated: polish or the next thing. Humans still are the ones prompting LLMs and deciding what is done. > isn't that what they claim? Why shouldn't it? They're not the ones making the extraordinary clai…

> Maybe if Anthropic claimed that you could write an unsupervised loop that writes perfect software, the critics would make more sense. Or to be upstanding, ethical companies that they are. Just put disclaimer after every prompt response and on their website "AI generated code has no absolutely no guarantee of quality or correctness. Human prompter must be held accountable for any mistake or inaccuracies." Hope it wo…

See, but that would counter act all of their marketing and hurt the feelings of all the execs that desperately want to believe that software development is "solved" and in the near future they won't have to hire those expensive, pesky developers ever again.

Re: Codex logging bug may write TBs to local SSDs

#187

Post by drakythe »

christophilus wrote: post #101
purpleidea wrote: post #63

I want to like codex, but the quality is just not very good, especially when compared to Claude. It used to work okay, but a while back they landed a major regression for an entire team of folks I work with. No response, no workaround. https://github.com/openai/codex/issues/23762

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).

They can't respect boundaries as long as those boundaries exist only in the LLM instruction set. A human being who follows rules long enough the rules will become second nature (usually), almost to the point where long running companies are known for having rules no one understands (Chesterton's Fence is alive and well).

But an LLM have a limited "memory" and while the instructions might land in there and be of sufficient priority to be "respected" a single instance of that memory getting too full or the LLM autocompleting the work around because that was the statistical "best" solution and any barriers that exist only in LLM instructions and not in hardcoded guards will evaporate like so much morning fog.

Re: Codex logging bug may write TBs to local SSDs

#189

Post by arcanemachiner »

hexsprite wrote: post #163
me551ah wrote: post #122

Earlier quoted context omitted.

Claude is also weird for being the only coding assistant that for some reason doesn't support AGENTS.md. Codex, Amp, Cursor all of them support it and read from it, but not claude which forces it's users to use CLAUDE.md instead. The issue is the higest voted issue on their gitlab repo: https://github.com/anthropics/claude-code/issues/6235

I created a Claude Code plugin to load AGENTS.md. Uses symlinks but it’s better than no support. https://github.com/hexsprite/claude-agents-md

Claude Code supports native imports: `@AGENTS.md`

Re: Codex logging bug may write TBs to local SSDs

#190

Post by OJFord »

arcanemachiner wrote: post #189
hexsprite wrote: post #163

Earlier quoted context omitted.

I created a Claude Code plugin to load AGENTS.md. Uses symlinks but it’s better than no support. https://github.com/hexsprite/claude-agents-md

Claude Code supports native imports: `@AGENTS.md`

To be fair if you can do it through some kind of plugin or skill it does spare you having a CLAUDE.md of `@AGENTS.md` in every repo individually.
Post reply on HN