In my experience, a simple bubblewrap (Linux) or sandbox-exec (macOS) is probably enough and also much less overhead. LLMs agents are not exploiting kernels to get out of the sandbox. The most common issues are them trying to open PRs, or changing files where they shouldn't.

- https://github.com/numtide/claudebox

Can i plug my solution here too?

https://github.com/EstebanForge/construct-cli

For Linux, WSL also of course, and macOS.

Any coding agent (from the supported ones, our you can install your own).

Podman, Docker or even Apple's container.

In case anyone is interested.

If you're on a Linux or Unix OS, a chroot jail might be a more lightweight solution. the chroot command essentially makes the chrooted directory look like the root dir. You need to set up all the directories claude can access (like /usr/bin or whatever). I haven't tried this yet, but I don't see any reason it wouldn't work. This solution would protect files outside your project from getting trashed, but not malicious data exfiltration.

What is the equivalent of this, for Claude Cowork? Can anyone point me to a guide on how to safely use that?

Bubblewrap + nixos, much easier: https://github.com/7mind/nix-config/blob/main/modules/hm/dev...

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.

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

I'm using devcontainers for this, and I'm finding that a very good solution (coupled with VSCode).

I'm currently building a Docker dev environment for VSCode (github.com/dg1001/xaresaicoder) usable in a browser and hit the same issue. Without docker-in-docker it works well - I even was able to add transparent proxy in the Docker network to restrict outbound traffic and log all LLM calls (pretty nice in order to document your project). For docker-in-docker development and better security isolation, I'm considering Kata Containers instead of Vagrant. Which gives me real VM-level isolation with minimum perf overhead, while still be able to use my docker stuff. Still on my TODO list though. Has anyone actually run Kata with vs code server? Curious about real-world quirks - I've read that storage snapshot performance can be rough.

I have been running dangerously, but I always make sure to start a new session, have claude read the docs (I have already generated) related to the project in question, and then scope the work to just those things in the current sandbox. It can technically go outside of the sandbox in this mode, but I've never had it happen.

IMO, if you are not running in the dangerous mode then you are really missing out on one of the best aspects of claude code- its ability to iterate. If you have to confirm each iteration then it's just not practical.