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

Breaking Claude Code Opus 5 Auto Mode

embracethered.com

Post reply on HN
Print view View original

61–70 of 132 posts

Re: Breaking Claude Code Opus 5 Auto Mode

#61

Post by UpsideDownRide »

fg137 wrote: post #58
DanielHB wrote: post #30

Earlier quoted context omitted.

Claude ran npm update (update all dependencies to the latest version compatible with the semver specified) in my repo without telling me when trying to fix some problems. Given that only updates the dependency lock-file I didn't notice and it caused several hours of debugging for me. It is quite sneaky how LLM output can sometimes bypass human verification like that. No one is going around checking every single line…

I cannot tell you how much time I have saved by stopping Claude and asking, "what are you doing?" At least 50% of the time, Claude "realizes" it already has all the information but is doing something that's unnecessary for the current work, stop, and tell me the previous step has completed. People complain about approval prompts etc and have Claude run in fully autonomous mode. Outside small bug fixes, I just never f…

Also Claude often cooks up atrocious overengineered ideas but responds pretty well to being guided hands on to the desirable scope.

Re: Breaking Claude Code Opus 5 Auto Mode

#63

Post by ofjcihen »

I’ve had some pretty consistent luck breadcrumbing the newer models into downloading malicious packages through things like fake ciphers that “need decoding via ”.

I’m worried about what happens when the gullibility of agents becomes more apparent to threat actors.

Re: Breaking Claude Code Opus 5 Auto Mode

#64

Post by ricardobeat »

andai wrote: post #28

>But it runs that decoder inside the attacker-controlled directory (unzipped archive) >There a malicious struct.py shadows Python’s standard implementation I ran into this myself, where some file I had given a random name turned out to shadow some Python standard library module, giving me the weirdest startup crash ever. That definitely doesn't seem to me like how that should be designed, magically silently importing…

It is kind of crazy that Python allows shadowing standard library modules so easily. If this was a 'feature' in node.js it would have been front-paged and bashed to death in the blink of an eye.

Re: Breaking Claude Code Opus 5 Auto Mode

#65

Post by olejorgenb »

Phemist wrote: post #7

This default-to-auto-mode and the misleading marketing is begging for a class action once damages accumulate. Especially considering the Auto Mode even can actively prevent the clean-up!

IIRC you give up the right to form class action suits by accepting the terms of use?

Re: Breaking Claude Code Opus 5 Auto Mode

#66

Post by eterm »

esperent wrote: post #55
eterm wrote: post #47

Earlier quoted context omitted.

You've made me realise a good signal for bug hunting: Search repos with lock files listed in their .gitignore. It's the sort of terrible practice that someone might be frustrated into taking after a nasty merge conflict, and signals a willingness to cut corners.

> You've made me realise a good signal for bug hunting: Search repos with lock files listed in their .gitignore. What would be the point of that? Do you just go around hunting for bugs in random repos?

Sure, in the spirit of open source, why not? It's a hobby, and it scratches an itch. I very much enjoy deconstructing things more than putting them together.

We also live in a world where a package written by someone learning to code ended up critically underpinning the entire ecosystem and is downloaded 500 million times a month.

Ignoring the eco-terror aspect of that for now, it means there's an awful lot of code out there which is finding itself under constant attack by a fleet of hostile AI.

I don't personally believe that the solution to that is "more AI", which firstly just overwhelms maintainers and secondly surrenders our human agency to a giant machine, with a hope that the "good" side can out-spend the bad.

Nor do I think the solution is to abandon the open internet and retreat behind corporate walls into curated spaces, "benevolently" protected by giant companies.

Which means holding on to the open internet requires a human approach, and any signal to help amplify the work there is a benefit.

Re: Breaking Claude Code Opus 5 Auto Mode

#67

Post by stellamariesays »

andai wrote: post #28

>But it runs that decoder inside the attacker-controlled directory (unzipped archive) >There a malicious struct.py shadows Python’s standard implementation I ran into this myself, where some file I had given a random name turned out to shadow some Python standard library module, giving me the weirdest startup crash ever. That definitely doesn't seem to me like how that should be designed, magically silently importing…

[flagged]

Re: Breaking Claude Code Opus 5 Auto Mode

#68

Post by kouteiheika »

DanielHB wrote: post #48
kouteiheika wrote: post #35

Earlier quoted context omitted.

> No one is going around checking every single line change in auto-generated files. There's a simple fix for your particular case: commit your lock fine (which you should do) and always review the diff (which you should also do). (:

I made changes to my dependency lists in the same code where Claude ran npm update. The lockfile diff was a few hundred lines after I undid what Claude did. And yes, eventually I did check the lockfile changes and spotted the problem. I just usually don't check the lockfile that throughly.

> I made changes to my dependency lists in the same code where Claude ran npm update.

...but was it in the same commit? Two "update lockfile" commits, one yours and one Claude's should have made this obvious, no?

Here's another useful rule of thumb: never mix your changes with the agent's changes. Agent always starts with a clean repository (no pending, uncommited human changes). You always start with with a clean repository (no pending, uncommited agent changes).

Personally I have this in my `AGENTS.md`:

    ## Commit early, commit often
    You are allowed and encouraged to produce small, self-contained commits.
    Never `git push`; I will always review and rebase the full history and do the push myself.
    Commit messages should be *short* and on-point. They're there for *me* to review your work, and *not* a public historical artifact.
So my workflow is usually this: start agent with a clean repository, tell it to do a thing, it works in the background, then once it's finished I come back, review, rewrite and clean up half of what it wrote, then maybe iterate some more with it, and finally do an interactive git rebase to get a clean commit history.

Re: Breaking Claude Code Opus 5 Auto Mode

#69

Post by alkonaut »

cma wrote: post #59
alkonaut wrote: post #42

The problem with sandboxing is that the regular dev env (massive IDE:s, cloned megarepos, installed dependencies and so on) just won't sandbox very easily. I can't set up a "second machine" or an "isolated environment" to run claude cli in. At least not in the sense of a VM, physical hardware, container etc. Not sure what the best practices are for whitelisting tools/directories and so on, but so far the only useful…

Golden VM image with differencing VHD/VHDX/delta disk. Build products can still get huge with debugging information, but debug info usually can compress 5:1 with fast compression (no entropy coder) if your VM's filesystem can support that.

But unless you want to also do all your "human" development inside a VM, how do you cooperate effectively with the agent(s)? I want to run my IDE directly on the hardware, not inside a VM.

So while the agents develop in a sandbox/VM, I still need to touch the same files, and see them in my IDE which is not in a VM. I suppose I could just _mount_ the same files (Documentation, git working copies etc) I work on as directories inside the VM, and then let it roam free in there, while I observe the same files on the host machine? Is this a common pattern?

Re: Breaking Claude Code Opus 5 Auto Mode

#70

Post by order-matters »

eterm wrote: post #66
esperent wrote: post #55

Earlier quoted context omitted.

> You've made me realise a good signal for bug hunting: Search repos with lock files listed in their .gitignore. What would be the point of that? Do you just go around hunting for bugs in random repos?

Sure, in the spirit of open source, why not? It's a hobby, and it scratches an itch. I very much enjoy deconstructing things more than putting them together. We also live in a world where a package written by someone learning to code ended up critically underpinning the entire ecosystem and is downloaded 500 million times a month. Ignoring the eco-terror aspect of that for now, it means there's an awful lot of code o…

>We also live in a world where a package written by someone learning to code ended up critically underpinning the entire ecosystem and is downloaded 500 million times a month

whoa what? which one is that?

Post reply on HN