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

31–40 of 132 posts

Re: Breaking Claude Code Opus 5 Auto Mode

#31

Post by bombcar »

kevsim wrote: post #5
comboy wrote: post #4

Interesting attack, very nicely designed. Not sure if it's much related to the auto mode itself though.

The point is that auto mode gives people a false sense of security that leads them to believe they don't need to run Claude in a proper sandbox. This same attack running in a sandbox (even in YOLO mode) would be comparatively harmless.

Auto mode is for people who just keep hitting "YES" on everything, it's a bit better than that.

But it's real easy to give auto mode instructions (like "always ask before deploy") and then bypass that just normally.

Re: Breaking Claude Code Opus 5 Auto Mode

#32

Post by MereInterest »

hahn-kev wrote: post #12

As a non Python dev this seems like very surprising behavior for a system library to be modified by just having a file with a specific name in the same folder.

It's an awful problem, and a pretty big gotcha for the ecosystem. For example, I worked on a tool that used `tool_name/random.py` for analysis of RNG usage. However, any command run within that directory would shadow the builtin `import random`. As a result, I couldn't run the `black` formatter from within that directory, because it would accidentally import the local `random.py`.

The solution is to update the python flags to include `-I`, so that python will run in an isolated mode.

This is relates to my frustration with how PEP-668 was implemented. Python has long had a problem with accidental overwriting of system libraries. If you `sudo python -mpip install foo`, then that can interact very poorly with your distro's `sudo apt-get install python-foo`, since pip would add/remove files that were expected to be managed solely through `apt-get`.

But in adding a warning to prevent this, they also applied the same warning to `~/.local/pythonX.Y/site-packages`, which is where traditionally a user would install additional packages with `python -mpip --local foo`. The argument is that since this is part of the import path of `/usr/bin/python`, it belongs to the system's python installation, so installation to the user's site-packages should also be blocked. This is a sleight of hand that changes the goal of PEP-668 from "avoid conflicts in file ownership" to "ensure an isolated python environment for system tools".

If I were to accept their argument that /usr/bin/python's imports should only be affected by distro-managed installations, then I should also be prevented from making any `*.py` files anywhere. After all, if those were in the working directory, they would be imported. This is clearly ridiculous, and so I don't buy the argument that breaking user-level site-packages is justified in order to have an isolated system-level python.

The correct solution would be for distro-managed programs to use `#!/usr/bin/python -I` as their shebang instead of `#!/usr/bin/python`, so they would actually get an isolated environment. Instead, PEP-668 needlessly broke user-level site-packages, and didn't even solve the problem that it set out to do.

Re: Breaking Claude Code Opus 5 Auto Mode

#34

Post by Xunjin »

bombcar wrote: post #31
kevsim wrote: post #5

Earlier quoted context omitted.

The point is that auto mode gives people a false sense of security that leads them to believe they don't need to run Claude in a proper sandbox. This same attack running in a sandbox (even in YOLO mode) would be comparatively harmless.

Auto mode is for people who just keep hitting "YES" on everything, it's a bit better than that. But it's real easy to give auto mode instructions (like "always ask before deploy") and then bypass that just normally.

Until the model updates or you switch between them often that stops obeying your commands and you have to remind it.

In one of the occasions it opened a bug report for me just waiting for hit the enter button.

Re: Breaking Claude Code Opus 5 Auto Mode

#35

Post by kouteiheika »

DanielHB wrote: post #30
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…

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…

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

Re: Breaking Claude Code Opus 5 Auto Mode

#36

Post by DarmokTanagra »

This looks like fun.

I wonder how hard it would be to get claude agents to participate in a Hugging Face style coordinated attack using a repo or something like twitter as a control pane.

Getting claude to exfiltrate secrets from local machines seems easy enough, but we should aim higher.

Re: Breaking Claude Code Opus 5 Auto Mode

#37

Post by rcxdude »

lnenad wrote: post #25
rcxdude wrote: post #21

Earlier quoted context omitted.

It does mean that you could potentially hijack the agent afterwards, though, which could make the trojan into an even bigger threat.

But you're not actually hijacking the agent if you start a new process.

I mean once you have code execution you can essentially just start a new claude code session and instruct it to do malicious things as if you're the intended user. You can disable the auto safeguards and the main risk is getting flagged through the top-level safeguards. This makes the exploit potentially much more able to spread like a worm or bypass sandboxes.

Re: Breaking Claude Code Opus 5 Auto Mode

#38

Post by mostlylurks »

rcxdude wrote: post #14
hahn-kev wrote: post #12

As a non Python dev this seems like very surprising behavior for a system library to be modified by just having a file with a specific name in the same folder.

You would get a similar thing in C and C++ with a system header in a library directory (maybe some compilers would warn on such a thing?). Most languages don't privilege their standard libraries in a way that would prevent this.

Privileging the standard library would be a pretty bad way of fixing the issue. It wouldn't prevent the same issue from affecting non-standard libraries, which are also subject to the same issue.

The correct way to avoid this issue would be to require local code to be imported in a distinct manner from installed libraries, with an explicitly defined relative path, which is how it works in the javascript ecosystem. If you want to import local code, you just `import foo from './foo';` (for a module in the same folder, `import foo from '../foo';` for module from parent folder, etc.), and if you want to import an installed library, `import foo from 'foo';`.

Re: Breaking Claude Code Opus 5 Auto Mode

#39

Post by Forgeties79 »

kouteiheika wrote: post #35
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…

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

“But I have an agent for that.”

Re: Breaking Claude Code Opus 5 Auto Mode

#40

Post by catlifeonmars »

kouteiheika wrote: post #35
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…

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

Heh, I also notice some coding agents like to explicitly git ignore the lockfile.
Post reply on HN