Bubblewrap + nixos, much easier: https://github.com/7mind/nix-config/blob/main/modules/hm/dev...
Running Claude Code dangerously (safely)
131–140 of 265 posts
Re: Running Claude Code dangerously (safely)
#132There 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…
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.
Re: Running Claude Code dangerously (safely)
#133> 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…
> A malicious AI could just add arbitrary code to your Vagrantfile
> [...]
> Claude could decide to fix/improve something by adding a commit hook.
repository/
├── sandbox Re: Running Claude Code dangerously (safely)
#134PM for Docker Sandboxes here.
Our next version of Docker Sandboxes will have MicroVM isolation and a Docker instance within for this exact reason. It'll let you use Claude Code + Containers without Docker-in-Docker.
Re: Running Claude Code dangerously (safely)
#135i've low-key been running claude in dangerously skip permissions mode for at least like 4 months now and have yet to be bitten by a truly destructive action. YMMV but i think as long as you're guiding/prompting correctly, and don't just allow write access to your prod account DBs willy nilly, it's mostly fine. just keep an eye on it :shrug:
This has mostly been my experience as well although I don’t tend to run yolo mode outside of an isolated VM (I’m setting them up manually still, need to try vagrant for it). That said, it seems like some of the people who are more concerned about isolation are working with more untrusted inputs than I’ve been dealing with on my projects. It’s rare for me to ask an agent to e.g. read text from a random webpage that could bring its own prompt injection, but there are a lot of things one might ask an agent to do that risk exposure to “attack text”.
Re: Running Claude Code dangerously (safely)
#136Bit of a wider discussion, but how do you all feel about the fact that you're letting a program use your computer to do whatever it wants without you knowing? I know right now LLMs aren't overly capable, but if you'd apply this same mindset to an AGI, you'd probably very quickly have some paperclip-maximizing issues where it starts hacking into other systems or similar. It's sort of akin to running experiments on con…
Don't you have the same issue when you hire an employee and give them access to your systems? If the AI seems capable of avoiding harm and motivated to avoid harm, then the risk of giving it access is probably not greater than the expected benefit. Employees are also trying to maximize paperclips in a sense, they want to make as much money as possible. So in that sense it seems that AI is actually more aligned with m…
I do not believe that LLMs fear punishment like human employees do.
Re: Running Claude Code dangerously (safely)
#137I'm currently using a qemu vm for the codex with the --yolo flag but same thing. I've been also looking at using lima for automating the creation of vms. But it does a few weird/dangerous things like mounting the entire user directory read/write. Which kind of defeats the point. There are ways of turning that off probably but it does a few dangerous/annoying things wrong by default.
But a simple vm and some automation to install developer tools using ansible, nix or whatever you prefer isn't that hard to (vibe) code together. I like Lima but it feels slightly sub-optimal for the job currently.
Some useful things to consider:
- Ssh agent forwarding for authenticating against e.g. git is useful. But maybe don't use the same key that authenticates to your production machines as well ...
- How do you authenticate without a browser? Most AI tools have ways to deal with that but it's slightly tedious to automate during provisioning.
- Making sure all your development tools are there; I use things like sdkman, nvm, bun, etc. And I have my shell preferences and some other tools I like to have around.
- Minimizing time provisioning these vms over and over again. This gets tedious really quickly.
- Keeping the VMs fast is important too. In my projects, build tool performance adds up and AI tools like to call them a lot. So assign enough memory and CPU.
- It would be nice to switch between local and remote/cloud based vms easily.
- Software flexibility; developers are picky about their tools. There is no one size fits all here. Even just deciding on the base image to use for your vm is likely to escalate. I picked debian for what it is worth.
In short, I think there's enough out there that you can pull something together but it still involves quite a bit of DIY. It would be nice if this got easier. And AI tools asking for permission for everything is not a good security model. Because people just turn that off. Sandboxing those things is the way to go. But AI tools need to be able to do enough to work with your software.
Re: Running Claude Code dangerously (safely)
#138Earlier quoted context omitted.
I'm struggling to see how this resolves the problem the author has. I still think there's value in this approach, but it feels to be in the same thrust as the built in controls that already exist in claude code. The problem with this approach (unless I'm misunderstanding - entirely possible!) is that it still blocks the agent on the first need for approval. What I think most folks actually want (or at least what I wa…
You're right that blocking on every operation would defeat the purpose! Shannot is able to auto-approve safe operations for this reason (e.g. read-only, immutable) So the agent can freely explore, check logs, list files, inspect service status. It only blocks when it wants to change something (install a package, write a config, restart a service). Also worth noting: Shannot operates on entire scripts, not individual…
yeah, I think the combo approach definitely has the most appeal:
- Spin up a vm with an image of the real target device.
- Let the agent act freely in the vm until the task is resolved, but capture and record all dangerous actions
- Review & replay those actions on the real machine
My issue is that for any real task, an agent without feedback mechanisms is essentially worthless. You have to have some sort of structured "this is what success looks like, here's how you check" target for it. A human in the loop can act as that feedback, which is in line with how claude code works by default (you define success by approving actions and giving feedback on status), but requiring a human in the loop also slows it down a bunch - you can end up ping-ponging between terminals trying to approve actions and review the current status.
Re: Running Claude Code dangerously (safely)
#139I just gave it its own user and dir. So I can read and write /agent, but agents can't read or write my homedir.
So I just run agents as the agent user.
I don't need it to have root though. It just installs everything locally.
If I did need root I'd probably just buy a used NUC for $100, and let Claude have the whole box.
I did something similar by just renting a $3 VPS, and getting Claude root there. It sounds bad but I couldn't see any downside. If it blows it up, I can just reset it. And it's really nice having "my own sysadmin." :)
Re: Running Claude Code dangerously (safely)
#140Earlier quoted context omitted.
> 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).
I happen to use a Mac, even when targeting Linux so I'd have to use a container or VM anyways. It's nice how lightweight bubblewrap would be however. Consider one wanted to replicate the human-approval workflow that most agent harnesses offer. It's not obvious to me how that could be accomplished by dropping privileges without an escape hatch.
It being deprecated and all, didn't feel like wrapping it, but macOS supposedly has a similar `sandbox-exec` command ...