Top
Best
New

Posted by emilburzo 21 hours ago

Running Claude Code dangerously (safely)(blog.emilburzo.com)
309 points | 238 commentspage 8
athrowaway3z 19 hours ago|
`useradd claude`
netcoyote 17 hours ago|
This is the solution I chose for sandvault [0], which works well on my Mac since agents can run OSX-specific tools.

It just got added to Homebrew:

    brew install sandvault
Or clodpod [1] for a VM-based solution

0: https://github.com/webcoyote/sandvault

1: https://github.com/webcoyote/clodpod

supermatt 18 hours ago||
> now you need Docker-in-Docker

Or you can just mount the socket and call docker from within docker.

emilburzo 18 hours ago|
Correct, which I wanted to avoid because:

> Mounting the Docker socket grants the agent full access to your Docker daemon, which has root-level privileges on your system. The agent can start or stop any container, access volumes, and potentially escape the sandbox. Only use this option when you fully trust the code the agent is working with.

https://docs.docker.com/ai/sandboxes/advanced-config/#giving...

ejia 17 hours ago||
PM for Docker Sandboxes here.

We have an updated version of Sandboxes coming out soon that uses MicroVM isolation to solve this exact problem. This next version will let your agent access a Docker instance within the MicroVM, therefore allowing you to do this securely.

nailer 16 hours ago||
Don't all modern OS's have sandboxing? We don't need a full VM (eg, kernel running on virtualized hardware) and the complexity that entails, we just need Claude Code running in the sandbox.

(Maybe I should be asking Claude this)

Edit: someone already built this: https://github.com/neko-kai/claude-code-sandbox

guluarte 15 hours ago||
docker has sandboxes for this https://docs.docker.com/ai/sandboxes/

docker sandbox run claude

oofbey 17 hours ago||
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.

emilburzo 17 hours ago|
Hmm, perhaps I'm missing something, so let's go through it step by step and see where the disconnect is:

- There's a cloned 'my-project' git repo on the base OS

- The 'Vagrantfile' is added to the project

- 'vagrant up', 'vagrant ssh' and claude login is run inside the VM

At this stage, besides the source code and the Claude Code token (after logging in), there are no other credentials on the VM: no SSH keys, no DB credentials, no API tokens, nothing.

There is also no need to add:

- SSH keys or GitHub tokens: because git push/pull is handled outside the VM

- DB credentials: because Claude can just install a DB inside the VM and run the project migrations against that isolated instance, not any shared/production database

API tokens can definitely be a problem if you need external service integration. But that's an explicit opt-in decision, you'd have to deliberately add those credentials to the Vagrantfile or sync them in. At that point, yes, you need proper token scoping and permissions.

MORPHOICES 10 hours ago||
[dead]
Lucasjohntee 20 hours ago||
[dead]
nirdiamant 19 hours ago|
[flagged]