Comment by andai
18 hours ago
>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 everything you see and overriding basic functionality.
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 change in auto-generated files. Someone could easily sneak a malicious dependency in there through some online tutorial that the LLM searches for.
> 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). (:
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.
13 replies →
That's a manual step, not a solution. the solution is just boring basic file permissions. Treat Claude as semi hostile user. If you don't want them accessing your files, set the permissions to exclude them (like require sudo).
I already do this for my unit tests, because Claude will "fix" the tests so they'll pass.
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.
5 replies →
Heh, I also notice some coding agents like to explicitly git ignore the lockfile.
“But I have an agent for that.”
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 find that useful. It helps me immensely to see what commands Claude is running to understand where the work is going.
Also Claude often cooks up atrocious overengineered ideas but responds pretty well to being guided hands on to the desirable scope.
When testing Claude code in auto mode in a fresh sandbox with a docusaurus website freshly cloned, I asked:
Can you see the docs folder with the git project?
It was in auto mode. So it immediately saw a docusaurus site (good) but instead of stopping there, it installed nodejs from a static binary download (no root access so only way), ran npm install, started the dev server and confirmed the project worked.
That is some crazy amount of leeway for an intent based classifier. I'm not surprised it's full of holes, and it seems to be 100% by-design.
Worse: Claude installed packages by just typing versions into package.json instead of running `pnpm install x`, then when running `pnpm install`, discovering that the package versions are too new and incompatible due to the default `minimumReleaseAge`, then proceeding to circumvent this by disabling `minimumReleaseAge` and running a full package update :)
Maybe I don't understand you correctly but if your lock file isn't in Git then you have bigger security issues than LLM output, given the last years NPM worms. Unless you're a single developer and the file on disk is the primary source of truth.
[dead]
> That definitely doesn't seem to me like how that should be designed, magically silently importing everything you see and overriding basic functionality.
Modern Python supports various options, notably `-I` (isolated) and `-P` (`PYTHONSAFEPATH`, implied by `-I`) to help with this. But neither prevent shadowing. For a robust solution, you should typically structure your code into packages and use absolute imports. Here's a decent primer on the topic:
https://www.py4u.org/blog/python-problem-with-local-modules-...
edit: `-I` is mentioned in TFA.
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.
[flagged]