alt Hacker News> 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). (:
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.
Heh, I also notice some coding agents like to explicitly git ignore the lockfile.
“But I have an agent for that.”
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.