Claude Tried to Nuke My Home Directory
old.reddit.com54 points by anthropodie 2 months ago
54 points by anthropodie 2 months ago
Is this really that surprising? It used to, still is?, be considered a bad idea to follow those install suggestion where it’s `/bin/bash -c $(curl example.com/install.sh)`. These tools are basically that but even more risky because the code they generate is semi-random.
Of course you can evaluate everything it does before it does it. But no one reads the homebrew install script to make sure it’s safe when setting up a new Mac so who’s going to read the Claude code scripts?
That's what I don't get about the current LLM coding/agent hype. The supposed gain is completely negated unless you can trust the output completely. If I have to inspect everything, generating a bunch of code/scripts or doing a lot of things/running a lot of commands quickly on my computer doesn't really help at all. The more things it does the more of a reasoning burden I have.
What I think is completely missed is that the bottleneck in knowledge work is understanding and making sure about what is built and done.
Well actually now you could build a Gen Ai service that explains those scripts and link it from the download page so anyone can inspect it.
It's a bit funny that between trolling and innocent "screw it, burn everything and start over" that every beginner has been through, this is obviously going part of the learning experience... whether you're human or machine.
(No, I wouldn't seriously rm -rf ~/ intentionally in most cases but it's not so insane when you imagine creating a new user for project separation. For those reasons it's probably good to keep the agents separate too...)
Claude wrote a Python file earlier to delete/clean up some folders. It was about to run, so I canceled the run. It then tried to write a bash script to delete the files. I canceled it and then tried to write the command to delete them. I was amazed by all the ways it was finding.
I didn’t read the word “directory” initially, and I was imagining a scenario where the author gave Claude access to an API, and was like “this endpoint will set off a nuke” and then Claude was like “Ok! :3” and triggered it.
I've had situations where Cursor just starts to do some really bizarre behavior after long running cycles of tasks unsuccessfully like the death loop I've seen described in other threads.
Best way to deal with this is to just clear the embedding index from the cursor settings and rebuild it.
I've never had it go to a point where it will want to rf home, but now I'm a bit fearful that one day it will go and do it as I have it on auto run currently.
Last week I nuked my home directory by running `rm -rf *` mistakenly from the wrong directory. Lost around 2-3 hours to re-install and re-clone.
Accidents will happen, disaster recovery is needed notwithstanding misaligned AI.
IMO once you're really ready for the worst, productivity from yolo mode AI assistance surpasses the downsides.
I have `rm` aliased:
alias rm="rm --interactive"
(On Mac and other systems with BSD versions of tools, `--interactive` is `-i` and `--force` is `-f`.)
'--force' does more than undoing '--interactive'. '--force' will remove a file even if the permissions of that file are set to read only (if you own the file or directory):
> touch foo
> ls -l
-rw-r--r--. 1 foo foo 0 Mar 24 05:54 foo
> chmod a-w foo
> ls -l
-r--r--r--. 1 foo foo 0 Mar 24 05:54 foo
> rm foo
rm: remove write-protected regular empty file 'foo'? n
> rm -i foo
rm: remove write-protected regular empty file 'foo'? n
> rm -i -f foo
>
This is true, but as you note, `rm -i` shows the same warning for write-protected files.
My alias is intended to provide the same protection against accidental deletions of non-write-protected files. I only pass the `-f` when I'm certain I know what I'm doing.
If I still want the raw behavior as you called out, I can use the full path to `rm`. But for me, I've unintentionally lost more files that I have write permissions on through bad rm commands than any lost from my alias with `-f`, which I can't recall having lost any with.
`rm -i` shows the same warning for write-protected files'
because for write-protected files '-i' is a no-op.
you are probably right that the risk of accidentally deleting a write protected file is very small, simply because using those permissions is very rare.
but there is another problem i have with using an alias, this may not apply to you, but i work on multiple machines and in containers, and i keep creating new ones for projects, that there is a high risk that i forget to set the alias. so every time i use rm i can't be sure, did i set the alias, or did i not. and if i rely on 'rm' always asking me, then it makes me complacent. ah, i don't have to pay attention because rm will ask me anyways.
writing 'rm -i' explicitly every time makes it much easier to see that '-i' is indeed being invoked. it makes me pay attention and i know that i am running the command that i want. it's three extra characters to type each time, but it has become muscle memory. i don't think about it anymore, except when verifying what i typed. the '-i' just has to be there.
> because for write-protected files '-i' is a no-op.
On my machine, `rm -i` with a yes to a read-only file does delete that file. But maybe I'm misunderstanding what you mean by it being a no-op.
> touch foo
> chmod 400 foo
> ls -l
total 0
-r-------- 1 joshua joshua 0 Mar 26 00:06 foo
> rm -i foo
rm: remove write-protected regular empty file 'foo'? y
> ls -l
total 0
Oh yea. I've definitely run into this. Luckily, a large percentage of my stuff off my dev machine is backed by code, so I can usually just throw things away and bring them all the way back up.
> writing 'rm -i' explicitly every time makes it much easier to see that '-i' is indeed being invoked. it makes me pay attention and i know that i am running the command that i want. it's three extra characters to type each time, but it has become muscle memory. i don't think about it anymore, except when verifying what i typed. the '-i' just has to be there.
Ha. I know that feeling, and this is probably something I should've let happen to me with these dangerous commands. Would definitely make my experience with cp a lot better. I have so many aliases I've made to make my life easier, but I just end up typing in the full command every time. :D
`rm -i` with a yes to a read-only file does delete that file. But maybe I'm misunderstanding what you mean by it being a no-op.
'rm' (without '-i') does exactly the same. so for read-only files, '-i' changes nothing.
whereas '-f' does change the behavior of 'rm' on read-only files. it doesn't just override '-i'.
Ah. I totally see what you meant now. Thank you for clarifying!
I had thought you mean that `rm -i` would do nothing to read-only files. Not that the flag itself was a no-op.
For context, according to the rules of the subreddit you must provide the full sequence of prompts used to generate the output, but no such sequence is given.
Also Claude didn't "try" to do anything of course. Such a title is nonsense at best.
What is the full sequence of prompts when using agent mode?
It just continues to do things... That's the value prop.