HACKER Q&A
📣 m-hodges

How are you sandboxing coding agents?


I've seen people rely on built-in sandboxes, use git worktrees (sometimes inside devcontainers), or run the whole agent inside a Linux VM with minimal host mounts. On Linux, I’ve also seen firejail/bubblewrap mentioned.

For folks actually using these tools day-to-day:

What’s your default setup?

Have you had any "learned the hard way" moments?

What tradeoff (safety vs convenience vs parallelism) has mattered most in practice?

I'm less interested in theoretical best practices than what's actually holding up under real use.


  👤 netcoyote Accepted Answer ✓
I use a Mac, and wanted to be able to run MacOS programs like Xcode and iOS simulator, so I wrote a couple of different sandbox projects:

- SandVault (https://github.com/webcoyote/sandvault) runs the AI agent in a low-privilege account

- ClodPod (https://github.com/webcoyote/clodpod) runs the AI agent inside a MacOS VM

In both cases I map my code directories using shares/mounts.

I find that I use the low-privilege account solution more because it's easier to setup and doesn't require the overhead of a full VM


👤 sixhobbits
I have time machine and just let them fly with --dangerously-skip-permissions on my Mac. Worst thing it's done is back up a database, delete the database, and then run git clean locally which also wiped out the backup, so I'm not saying there are no dangers but honestly I've made worse mistakes and probably more frequently so I generally trust Claude with about the same level of access as me now.

Most common is deleting files etc but if you're using git and have backups it's barely noticeable


👤 gl-prod
I spin a Firecracker VM with a custom image that has all the things I need.

👤 jomcgi
I have a web ui for managing / interacting with opencode sessions. Everything runs as a pod in my homelab cluster so I can let them "bypass" permissions and just restrict the pods.

I wanted something like Claude code web with access to more models / local LLMs / my monorepo tooling, so far it's been great.

The output is a PR so it's hard for it to break anything.

The biggest benefit is probably that it makes it easier to start stuff when I'm out - feels like a much better use of downtime like I'm not waiting to get home to start a session after I have an idea.

The monorepo tooling is a bit win too, for a bunch of things I just have 1 way to do it and clear instructions for them to use the binaries that get bundled into new sessions so it gets things "right" more often.


👤 stavros
I wrote a small utility that wraps commands in Docker: https://github.com/skorokithakis/dox

👤 aussieguy1234
I run vscode based agents in Linux, mostly Kilo Code

After a bit of tinkering I was able to get it to all run fine in Firejail, I wrote a guide here https://softwareengineeringstandard.com/2025/12/15/ai-agents...

Fairly basic, limits the agents write access to my projects, all of which are backed up in git.


👤 foreigner
I'm using Catnip (https://github.com/wandb/catnip). It runs Claude Code in YOLO mode inside a Docker container, and also manages multiple Claude instances running in Git worktrees. I'm pretty happy with it but would be happier if it addressed limiting network access to guard against exfiltration.

👤 yomismoaqui
Using Claude Code and Amp (free mode) with no sandbox.

I don't run Claude Code in YOLO mode, I just approve commands the first time I'm asked about them.

Using them since July I haven't found any problem with data loss and the clanker have not tried to delete my $HOME.


👤 Havoc
For CC - unprivileged LXC on a proxmox server. That's enough to catch mishaps like deleting all your sht while still being a reasonable transparent isolation layer. Plus my entire homesetup is geared towards LXC anyway.

Keen to give firecracker another go though. Last I explored that it still felt pretty rough. (on UX not tech quality)


👤 solresol
I create a separate Linux user (which doesn't have sudo rights) for each project. I have to log each user in to Claude code or codex, but then I can use ordinary Unix permissions to keep the bots under control and isolated.

👤 languid-photic
> Have you had any "learned the hard way" moments?

A big lesson for us is that you still need to be careful even in a sandbox.

We've been running Claude/Codex/Gemini in sandboxed YOLO mode and have seen some interesting bypass attempts. [1]

A few examples:

- created fake npm tarballs and forged SHA‑512s in our package‑lock.json

- masked failures with `|| true`, making blocked operations look successful

- cloned a workspace, edited the clone, then replaced the workspace w the clone to bypass file‑path deny rules

So, we’ve learned to default to verbose logging, patch bypasses as we see them, and try to keep iteration loops short.

[1] https://voratiq.com/blog/yolo-in-the-sandbox/


👤 zmj
devcontainers, without credentials to the git remote.

👤 scuff3d
I feel like a crazy person reading these comments, "oh it tries to bypass limitations, delete files, and generally nuke my system... But it's cool, I trust it"

👤 gverrilla
is firejail safe to use for this purpose? any tips?

👤 jq-r
Claude Code in yolo mode with Docker Sandboxes https://docs.docker.com/ai/sandboxes/