I've been working on a TUI to make bubblewrap more convenient to use: https://github.com/reubenfirmin/bubblewrap-tui

I'm working on targeting both the curl|bash pattern and coding agents with this (via smart out of the box profiles). Early stages but functional. Feedback and bug reports would be appreciated.

I use https://github.com/rcarmo/agentbox inside a Proxmox VM. My setup syncs the workspaces back to my Mac via SyncThing, so I can work directly in the sandbox or literally step away.

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.

I 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." :)

For a similar but lighter weight (and less isolated) tool that uses the OS's sandboxing functionality (bubblewrap on linux, Seatbelt/sandbox-exec on macos) or docker check out cco [1] (note: I built it). It's primarily useful now because it can also sandbox other agents like opencode or codex since Anthropic has added native sandboxing functionality to Claude Code itself now. Their sandbox works similarly, also using bubblewrap and seatbelt, and can be accessed via the /sandbox slash command inside Claude Code [2].

[1]: https://github.com/nikvdp/cco [2]: https://code.claude.com/docs/en/sandboxing

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

Koyeb has great resources about running Claude Code in sandboxes: https://www.koyeb.com/tutorials/use-claude-agent-sdk-with-ko...

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.

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

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.