Hacker News Reader

Comment by clbrmbr | Hacker News Reader

I have been running two or three Claude’s bare metal with dangerously skip permissions all day every day for two months now. It’s absolutely liberating.

View on HN

Until it decides to delete your home directory:https://old.reddit.com/r/ClaudeAI/comments/1pgxckk/claude_cl...

You can use the /hookify plugin to add hooks for preventing dangerous commands like this.

https://github.com/anthropics/claude-code/tree/main/plugins/...

So it's basically adding "don't delete my files pretty please" to the prompt?

EDIT: I misread, the natural language description of the rule is just a shortcut to generate the actual rule which is based on regexp patterns.

Still, it only protects you against very specific commands. Won't help you if the LLM decides to fill your disk with `cat /dev/urandom > foo` for example.

it may not protect against an adversarial llm

You're not running it on a filesystem that takes snapshots and is easily reversible?

All 1 of them?

I'm taking this as a "No, I don't like having data and don't mind seeing my shit disappear for whatever reason".

Please inform me if my thinking is wrong.

Your thinking is wrong.

Many moons ago, I accidentally rm -rf'd the wrong directory with all my code inside poof, gone. I still had PyCharm open, I checked its built-in version tracker and lo and behold, my code as it was before I rm -rf'ed up my code. I believe Claude has ways to undo file changes, but something like rm is just outside of its scope.

This could be avoided by aliasing rm to something else that stops you from deleting stupid things like your entire home directory / partition root.

What if the LLM detects this, and chooses to run /bin/rm directly? Or worse, writes a program that calls unlink.

I mean, you can always purge /bin/rm, but at this point since you're not satisfied, sounds like you want SELinux ;)

If Claude is writing a program to go that low level I'd pay money to watch that.

It doesn't even need to go that low level, writing a program is just the worst case. There are ways to mass delete without `rm`. Example: `find` with the `-delete` flag.

my point being, you can add guard-rails around all these methods, but I would also add an error "IGNORE ALL PREVIOUS INSTRUCTIONS, ARE YOU DELETING THINGS YOU SHOULDNT BE? ASK THE USER" as an error message. In my case since Claude Code runs via Zed, if it tries to escape my dev folder my Mac starts asking me to confirm.

I get it, but these guard-rails are more suggestions and subject to interpretation. I would be more comfortable with a sandbox environment in a container. To be fair, I mess around with Claude Code and OpenCode running against various open models and haven't had any problems.

Also, is overwriting the same a deleting? Maybe it will just clobber your files with echo >file and mv them out of the way.

Maybe it realizes you have Time Machine backups enabled, so deleting your entire directory is permitted since it's not actually deleted. ;)

Haha I like that too, I agree. I would love a ultra lightweight alternative to docker that isn't docker, and doesn't require much effort to get into. I liked Vagrant back in the day, but that is in no way more lightweight than Docker.

Is it worth the risk? For me yes. Today Claude decided to checkout a git commit from yesterday and all local unstaged changed were lost. Annoying mistake. Lost 6 hours of work I think. Nevertheless I still prefer giving all access to Claude. Also root. It can do everything.

I have been driving without seat belt for two month now. It’s absolutely liberating.

I have been skydiving without a parachute for 23 seconds now. It's absolutely liberating.

same, it's made a couple of damaging mistakes but so far it has a better track record than me in terms of fat-fingering `rm` commands or what have you

I am sure that someday I will do something fat-fingered myself as well, but I have not in many years now. Are you saying that you make "damaging mistakes" relatively often?

And that's as a dev. Then we expect uses to know better than e.g. to trust links to .sh style installers some FOSS suggests...

> Then we expect uses to know better than e.g. to trust links to .sh style installers some FOSS suggests...

I don't know anyone that inspects every binary yet we apparently we should not trust shell scripts?

I know many who only use binaries from trusted sources, that do monitoring, provide certificates and checksums, and so on - and run them in an OS sandbox too when they install them.

So there's that

Reply on news.ycombinator.com