Running Claude Code dangerously (safely) • Hacker News Board

Re: Running Claude Code dangerously (safely)

#111

Post by AndroidKitKat » Tue, Jan 20, 2026, 3:19 PM UTC

jackcarter wrote: post #107

"At some point I realized that rather than do something else until it finishes, I would constantly check on it to see if it was asking for yet another permission, which felt like it was missing the point of having an agent do stuff" Why don't Claude Code & other AI agents offer an option to make a sound or trigger a system notification whenever they prompt for approval? I've looked into setting this up, and it seems…

When using Claude Code in Ghostty on macOS, I get notifications if it is waiting on my input (accept changes, questionnaire, run bash command). Dunno what combination (if any) of my setup is needed for this to happen, but I certainly didn't configure anything special. Maybe I'm giving CC too much free reign to do things.

Re: Running Claude Code dangerously (safely)

#112

Post by thruflo » Tue, Jan 20, 2026, 3:20 PM UTC

loloquwowndueo wrote: post #13

Shellbox.dev and sprites.dev were discussed recently on hacker news, they give you a sandbox machine where it’s likely safe to run coding agents in dangerous mode. Filesystem checkpoint and restore make it easy to recover from even catastrophic mistakes.

I made a little tool for Ralphing on Sprites: https://github.com/thruflo/wisp

I’ve found the sprites just work for claude. Pull how a repo (or repos) and run dangerously.

Re: Running Claude Code dangerously (safely)

#113

Post by kaydub » Tue, Jan 20, 2026, 3:28 PM UTC

RobinL wrote: 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.

It feels like most people are exposing how wild west their environments are.

Re: Running Claude Code dangerously (safely)

#114

Post by kaydub » Tue, Jan 20, 2026, 3:30 PM UTC

gregoriol wrote: post #59

prodigycorp wrote: post #55

Earlier quoted context omitted.

Claude is very happy to wipe remote dbs, particularly if you're using something like supabase's mcp server. Sometimes it goes down rabbitholes and tries to clean itself up with `rm -rf`. There is definitely a real world risk. You should browse the ai coding subreddits. The regularity of `rm -rf` disasters is, sadly, a great source of entertainment for me. I once was playing around, having Claude Code (Agent A) contro…

Why in the hell would it be able to access a _remote_ database?! In no acceptable dev environment would someone be able to access that.

I think LLMs are exposing how slapdash many people work when building software.

Re: Running Claude Code dangerously (safely)

#115

Post by giancarlostoro » Tue, Jan 20, 2026, 3:31 PM UTC

mythical_39 wrote: post #109

giancarlostoro wrote: post #78

Earlier quoted context omitted.

If you're not using .claude/instructions.md yet, I highly recommend it, for moments like this one you can tell it where to shove scripts. Trickery with the instructions file is Claude only reads it during a new prompt, so any time you update it, or Claude "forgets" instructions, ask it to re-read it, usually does the trick for me.

Claude, I noticed you rm -rf my entire system. Your .instructions.md file specifically prohibits this. Please re-read your .instructions.md file and comply with it for all further work

IMHO a combination of trash CLI and a smarter shell program that prevents deleting critical paths would do it.

https://github.com/andreafrancia/trash-cli

Re: Running Claude Code dangerously (safely)

#116

Post by kernc » Tue, Jan 20, 2026, 3:31 PM UTC

corv wrote: post #108

kernc wrote: post #103

Since everyone tends to present their own solution, I bid you mine: sandbox-run npx @anthropic-ai/claude-code This runs npx (...) transparently inside a Bubblewrap sandbox, exposing only the $PWD. Contrary to many other solutions, it is a few lines of pure POSIX shell. https://github.com/sandbox-utils/sandbox-run

I like the bubblewrap approach, it just happens to be Linux-only unfortunately. And once privileges are dropped for a process it doesn't appear to be possible to reinstate them.

> Linux-only

What other dev OSs are there?

> once privileges are dropped [...] it doesn't appear to be possible to reinstate them

I don't understand. If unprivileged code could easily re-elevate itself, privilege dropping would be meaningless ... If you need to communicate with the outside, you can do so via sockets (such as the bind-mounted X11 socket in one of the readme Examples).

Re: Running Claude Code dangerously (safely)

#117

Post by nunez » Tue, Jan 20, 2026, 3:31 PM UTC

Vagrant is great for Claude!

You can also use Lima, a lightweight VM control plane, as it natively works with qemu and Virtualization.Framework. (I think Vagrant does too; it's been a minute since I've tried.) This has traditionally been used for running container engines, but it's great for narrowly-scoped use cases like this.

Just need to be careful about how the directory Claude is working with is shared. I copy my Git repo to a container volume to use with Claude (DinD is an issue unless you do something like what Kind did) and rsync my changes back and verify before pushing. This way, I don't have to worry if Claude decides to rewind the reflog or something.

Re: Running Claude Code dangerously (safely)

#118

Post by lucasluitjes » Tue, Jan 20, 2026, 3:33 PM UTC

> What you’re NOT protecting against:

> a malicious AI trying to escape the VM (VM escape vulnerabilities exist, but they’re rare and require deliberate exploitation)

No VM escape vulns necessary. A malicious AI could just add arbitrary code to your Vagrantfile and get host access the first time you run a vagrant command.

If you're only worried about mistakes, Claude could decide to fix/improve something by adding a commit hook. If that contains a mistake, the mistake gets executed on your host the first time you git commit/push.

(Yes, it's unpleasantly difficult to truly isolate dev environments without inconveniencing yourself.)

Re: Running Claude Code dangerously (safely)

#119

Post by bonsai_spool » Tue, Jan 20, 2026, 3:33 PM UTC

nunez wrote: post #117

Vagrant is great for Claude! You can also use Lima, a lightweight VM control plane, as it natively works with qemu and Virtualization.Framework. (I think Vagrant does too; it's been a minute since I've tried.) This has traditionally been used for running container engines, but it's great for narrowly-scoped use cases like this. Just need to be careful about how the directory Claude is working with is shared. I copy m…

How are you configuring Lima? Do you have any scripts you use to set up the environments or is this done ad hoc?

Re: Running Claude Code dangerously (safely)

#120

Post by oofbey » Tue, Jan 20, 2026, 3:39 PM UTC

There are two spheres of influence you need to consider. The local machine/vm/container that the agent is running in. But also the effect the agent can have on the outside world - using auth tokens or ssh keys or apis that is has access to. This article largely deals with the first problem and ignores the second.

You can have the local environment completely isolated with vagrant. But if you’re not careful with auth tokens it can (and eventually will when it gets confused）go wipe the shared dev database or the GitHub repo. The author kinda acknowledges this, but it’s glossing over a big chunk of the problem. If it can pus to GitHub, unless you’ve set up your tokens carefully it can delete things too. Having a local isolated test database separate from the shared infrastructure is a matter of a mature dev environment, which is a completely separate thing from how you run Claude. Two of the three examples cited as “no, no, no” are not protected by vagrant or docker or even EC2. It’s what tokens the agent has and needs.