Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Running Claude Code dangerously (safely)

blog.emilburzo.com

Post reply on HN
Print view View original

51–60 of 265 posts

Re: Running Claude Code dangerously (safely)

#51

Post by prodigycorp »

shakna wrote: post #31
crabmusket wrote: post #21

What is the consensus on Claude Code's built-in sandboxing? https://code.claude.com/docs/en/sandboxing#sandboxing > Claude Code includes an intentional escape hatch mechanism that allows commands to run outside the sandbox when necessary. When a command fails due to sandbox restrictions (such as network connectivity issues or incompatible tools), Claude is prompted to analyze the failure and may retry the command wit…

Afraid that it regularly bypasses requests for confirmation... [0] https://github.com/anthropics/claude-code/issues/14268 [1] https://github.com/anthropics/claude-code/issues/13583 [2] https://github.com/anthropics/claude-code/issues/10089

It's trivially easy to get Claude Code to go out of its sandbox using prompting alone.

Side note: I wish Anthropic would open source claude code. filing an issue is like tossing toilet paper into the wind.

Re: Running Claude Code dangerously (safely)

#52

Post by [deleted] »

sampullman wrote: post #46
samlinnfer wrote: post #24

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.

[deleted]

Re: Running Claude Code dangerously (safely)

#53

Post by phrotoma »

samlinnfer wrote: post #24

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.

This works great for naked code, but it kinda becomes a PITA if you want to develop a containerized application. As soon as you ask your agent to start hacking on a dockerfile or some compose files you start needing a bunch of cockeyed hacks to do containers-in-containers. I found it to be much less complicated to just stuff the agent in a full fledged VM with nerdctl and let it rip.

Re: Running Claude Code dangerously (safely)

#54

Post by gregoriol »

progval wrote: post #18
gregoriol wrote: post #8

Earlier quoted context omitted.

This breaks the non-interactive mode the post want to achieve. Claude will not be able to install some things and will require user action, which is not desired here.

Like what? It can already use npm/pip/etc. And if it needs a new APT package or config in /etc/ then you would want to know because you need to document it.

If you make claude work with c/c++, it may need apt for libraries or build tools.

Even with npm/pip, these may not be available on a base linux box.

Even then, some complex projects may need other tools that are not part of a base system (command line tools, redis, ...).

Re: Running Claude Code dangerously (safely)

#55

Post by prodigycorp »

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.

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) control another instance of Claude Code (Agent B) within a tmux session using tmux's scripting. Within that session, I messed around with Agent B to make it output text that made Agent A think Agent B rm -rf'd entire codebase. It was such a stupid "prank", but seeing Agent A's frantic and worried reaction to Agent B's mistake was the loudest and only time I've laughed because of an LLM.

Re: Running Claude Code dangerously (safely)

#56

Post by raesene9 »

frankc wrote: post #37

I think this makes sense but I wonder if firecracker would work better than vagrant for this? I haven't used it before, though. I guess it might if you are trying to run gas town level orchestration.

Firecracker can solve the kind of problems where you want more isolation than Docker provides, and it's pretty performant.

There's not a tonne of tooling for that use case now, although it's not too hard to put together I vibe-coded something that works for my use case fairly quickly (CC + Opus 4.5 seemed to understand what's needed)

Re: Running Claude Code dangerously (safely)

#57

Post by Retr0id »

> VirtualBox 7.2.4 shipped with a regression that causes high CPU usage on idle guests. What are the odds.

I have such a love/hate relationship with VirtualBox. It's so useful but so buggy. My current installation has a bug that causes high network latency, but I'm afraid to upgrade in case it introduces new, worse bugs.

VMware is a million times better, but it is also Proprietary™

Re: Running Claude Code dangerously (safely)

#58

Post by raesene9 »

Of course it depends on exactly what you're using Claude Code for, but if your use-case involves cloning repos and then running Claude Code on that repo. I would definitely recommend isolating it (same with other similar tools).

There's a load of ways that a repository owner can get an LLM agent to execute code on user's machines so not a good plan to let them run on your main laptop/desktop.

Personally my approach has been put all my agents in a dedicated VM and then provide them a scratch test server with nothing on it, when they need to do something that requires bare metal.

Re: Running Claude Code dangerously (safely)

#59

Post by gregoriol »

prodigycorp wrote: post #55
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.

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.

Re: Running Claude Code dangerously (safely)

#60

Post by loloquwowndueo »

gcr wrote: post #28
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.

What about API calls? What about GitHub trusted CI deploys? One frustrating thing about these solutions is that they’re great to prevent Claude from breaking a machine, but there’s no pervasive sandbox for third party services

What about them?
Post reply on HN