I give my agents a dedicated system user with their own home. It's not sandboxing - they can still read many of my files (which is actually convenient) and they could exploit local vulnerabilities to get root, of course. But I find it to be a good compromise. I'm not as concerned about the agent turning evil than I am about it doing harm on good will.

They have their own clone of the repo they're working on. And when they're done, I pull their commits from my own git working copy, with my system user, and then push it to my bare repos, which acts both as an easily backupable source and as my CI, with their post-update hooks. The whole "pull from codex, then push to bare repo" is so common that I made for myself a `meat_proxy` command that automates it. I'm some lazy meat.

I recently got very pessimistic about this when I realized that in order for the agent to make meaningful changes, it frequently needs to read all your config files / dotfiles.. even if this is a sandboxed project, it feels pretty bad this config is instantly stored in the cloud out of your grasp. My OpenCode one day was like "and now I'm signing into your local mysql instance with your (plaintext) pw that I picked up last week to make some schema updates... " and I was like, ok we're done here.

I'm now avoiding any cloud-agents until further notice.

"or is there something more tailored out there?"

They're just going to sell you Docker isolation and call it something else.

I mount only the project folders I want my AI to see, and it has no keys to anything otherwise. If can push and deploy using the same project files but from my host machine, manually.

I use it in a devcontainer. Protects me from most agent stupidity, though not malice. I give it read-only access to git origin and relevant AWS infra, so any remote changes are made by me from the host (manually or scripted), but it is still able to quickly get feedback on changes and look at logs.

I've found drop (https://github.com/wrr/drop) to be really simple and effective.

For full isolation, I also use a VM via Incus. Lets me run the dayjob's Tailscale within, as well.

I just documented my setup, and the reasoning for it. Covers repo-native tooling, sandboxing, request proxying etc.

Perhaps of interest?

https://epiq.sh/blog/repo-native-tooling-for-sandboxes

I use pi and bubblewrap (bwrap) to offer some sandboxing. I call it `pise` for "pi secure environment". - https://codeberg.org/dannyfritz/dotfiles/src/commit/f5d082d2...

Locally running Docker Sandboxes built with the --clone flag work pretty good for me so far. The naming is a bit confusing here: these are not containers, this is a completely separate product by Docker using MicroVM-s for sandboxing. Devex has been good and the isolation is pretty solid this way, the big downside is that it's not open source. If someone releases and maintains an open source implementation that provides similar devex I'll jump ship immediately.

I use Incus to manage disposable virtual machines on my Linux host with a couple of scripts to set up a fresh vm automatically for a given project from a base image. So I can run the agents inside in yolo mode without too much worry. They get access to one shared folder between them.

Claude code uses bubblewrap[1] to offer some isolation. I'd love to hear from others whether its a reasonable solution or not.

[1] https://github.com/containers/bubblewrap

Timeline in reverse:

- smolvm (what I currently use)

- tart (for macOS VM)

- nono

- Anthropic Sandbox Runtime (srt)

- Docker containers

I didn't love any of them, but nono/srt struck a nice balance of convenience + security. I found srt more intuitive than nono. I could basically share my srt with a colleage via a json, while the nono config is more complex. And also noisy with what gets blocked / asking for approval. Some would see that as a perk, I thought it was distracting since a big reason to use a sandbox is to avoid permissions fatigue.

I use Coder with one workspace per project. A workspace is an isolated VM and I let the agents loose there. They can do anything they want in the workspaces but once the code is pushed, it's reviewed by an external agent before being merged. It's not an elaborate setup. It started very straightforward and the basic setup still works for me, but I have been adding some features here and there over time.

Docker works but the part that bit me was not the filesystem, it was the agent needing real credentials and network access to be useful. What I ended up doing is running the CLI agent in a throwaway working copy with only the env vars that one task needs, and treating anything it writes as a patch to review rather than something that lands directly. Curious if anyone has found a lighter option than a container that still stops it from reaching things like ssh keys.