Live data from Hacker News

Running Claude Code dangerously (safely)

blog.emilburzo.com

41–50 of 265 posts

Re: Running Claude Code dangerously (safely)

#41
post #36

Does anyone have direct experience with Claude making damaging mistakes in dangerously skip permissions mode? It'd be great to have a sense of what the real world risk is.

At least one guy had their ~ rm -rf'ed.

https://old.reddit.com/r/ClaudeAI/comments/1pgxckk/claude_cl...

Re: Running Claude Code dangerously (safely)

#42
post #39
post #25

Earlier quoted context omitted.

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

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

All 1 of them?

Re: Running Claude Code dangerously (safely)

#43
post #17

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.

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...

Re: Running Claude Code dangerously (safely)

#44
post #36

Does anyone have direct experience with Claude making damaging mistakes in dangerously skip permissions mode? It'd be great to have a sense of what the real world risk is.

Claude has twice now thought that deleting the database is the right thing to do. It didn't matter as it was local and one created with fixtures in the Docker container (in anticipation of such a scenario), but it was an inappropriate way of handling Django migration issues.

Re: Running Claude Code dangerously (safely)

#45
post #36

Does anyone have direct experience with Claude making damaging mistakes in dangerously skip permissions mode? It'd be great to have a sense of what the real world risk is.

When approving actions "for this project" I actively monitor .claude\settings.local.json

as

"Bash(az resource:)",

is much more permissive than

"Bash(az resource show:)",

It mostly gets it right but I instantly fix the file with the "readonly" version when it gets it too open.

Re: Running Claude Code dangerously (safely)

#46

Here is what I do: run a container in a folder that has my entire dev environment installed. No VMs needed. The only access the container has are the folders that are bind mounted from the host’s filesystem. The container gets network access from a transparent proxy. https://github.com/dogestreet/dev-container Much more usable than setting up a VM and you can share the same desktop environment as the host.

I did this for a while, it's pretty good but I occasionally came across dependencies that were difficult to install in containers, and other minor inconveniences.

I ended up getting a mini-PC solely dedicated toward running agents in dangerous mode, it's refreshing to not have to think too much about sandboxing.

Re: Running Claude Code dangerously (safely)

#47

Here's what I do (shameless plug): https://blog.denv.it/posts/im-happy-engineer-now/ This allows you to use Claude Code from your mobile device, in a safe environment (restricted Kubernetes pod)

Here's what I do (shameless plug, not an employee, just a satisfied user): https://exe.dev

Yes, this approach also looked nice! Maybe you can pair both (happy + exe.dev) for best results

Re: Running Claude Code dangerously (safely)

#49
post #29

Earlier quoted context omitted.

If the folder is versioned and commited regularly there is no problem. It also allows you to open the files in your IDE, do some other tasks or fixes for claude. It prevents claude from accessing any other folder, which is the idea of the post.

I’ve seen Claude rm .git in rare occasions to “fix rebase hiccups” Version control ain’t a match for a good backup

So? if it removes .git, just clone the project again and you are ok

Re: Running Claude Code dangerously (safely)

#50
For deploying Claude Code as agent, Cloudflare is also an interesting option.

I needed a way to run Claude marketplace agents via Discord. Problem: agents can execute code, hit APIs, touch the filesystem—the dangerous stuff. Can't do that in a Worker's 30s timeout.

Solution: Worker handles Discord protocol (signature verification, deferred response) and queues the task. Cloudflare Sandbox picks it up with a 15min timeout and runs claude --agent plugin:agent in an isolated container. Discord threads store history, so everything stays stateless. Hono for routing.

This was surprisingly little glue. And the Cloudflare MCP made it a breeze do debug (instead of headbanging against the dashboard). Still working on getting E2E latency down.

Post reply on HN