Coding agents can execute shell commands, read files, install packages, and make network requests. By default they'll ask for permission first, but let's be honest: we all --dangerously-skip-permissions.
We instinctively reach for a sandbox to fix that, but “sandbox” means different things depending on what you're actually scared of. Most people skip the part where they figure that out. We'll do that part first. There are three things worth protecting against.
The first is the agent breaking your computer. Deleting something it shouldn't, clobbering a config file, installing a package that conflicts with something else. This is the one most people think about and it's actually the least serious. Accidents are recoverable.
The second is your confidential information leaving your machine. An agent reads your .aws/credentials or your .env file and exfiltrates it. Your secrets are now somewhere else. This happened in February with Clinejection, and all it took was a malicious GitHub issue title.
The third is not knowing what happened. Most sandboxing solutions give you the first two to varying degrees. Almost none of them give you the third, and it’s the one that matters most when something actually goes wrong.
There are five realistic ways to sandbox a coding agent. They are not all the same.
Option 1: Built-In Kernel Policy
Claude Code's native sandboxing. Agent-safehouse.
Claude Code (and Codex too, for that matter) ships with a sandbox. On macOS it uses Seatbelt, the sandbox-exec framework Apple uses for its own apps. On Linux it uses bubblewrap. You configure which paths the agent can read and write, and the kernel enforces it. The agent process cannot read a blocked path.
Agent Safehouse is the same primitive. It generates deny-first sandbox-exec policies tuned specifically for coding agents. It knows Claude Code needs your git config but not your SSH keys. Install with Homebrew, wrap your agent invocation, done. You now have a sandbox.
This is fast, free, and meaningfully better than nothing. It's also not a VM boundary, as Agent Safehouse's own docs say plainly. A kernel exploit reachable from the agent process is a host compromise. And neither tool touches network egress. The agent can still make arbitrary outbound requests. If it can read a file, it can exfiltrate it. The kernel policy doesn't stop that.
Option 2: Docker
Docker Sandboxes. Devcontainers. Half the tutorials on the internet.
Everyone reaches for Docker. Standard containers share the host kernel and give you namespace isolation: the agent can't see your home directory unless you mount it. That's real. It's also not a VM boundary, and container escapes are a documented vulnerability class. If you're running untrusted code in Docker and calling it sandboxed, you're betting no exploitable bug exists between the container and the host kernel.
Docker Sandboxes, Docker's official AI sandboxing product, recently moved to a microVM backend. Each sandbox now gets its own kernel, and network allow/deny lists are available. This is meaningfully stronger than a plain devcontainer. If you're going the Docker route, use Docker Sandboxes. The gaps that remain: you're still running the hypervisor on your laptop, secrets land in the VM as environment variables, and there's no persistent audit trail.
Option 3: Local VM
Gondolin.
Gondolin is an open-source TypeScript control plane over QEMU/KVM microVMs. It gives you a real VM boundary on your local machine. Guest kernel compromise doesn't mean host compromise. That's a significantly stronger security posture than anything in options 1 or 2.
It also ships egress policy as a first-class feature. You write JavaScript that defines what outbound connections are allowed; everything else is denied. It includes snapshot/restore, too: checkpoint before a risky operation, roll back in under a second.
Most importantly, though, it ships a proxy that hides secrets from the guest. The agent can't exfiltrate secrets it never sees. Gondolin is the only local-first solution that does this, which makes it a great choice for secure, local sandboxing.
What Gondolin doesn't give you: persistent audit logging or multi-session management. Your VM also stops when you close your laptop. Those aren't criticisms, they're just outside its scope.
Option 4: DIY Remote VM
Hetzner bare metal. A Mac Mini. Anything with real hardware virtualization.
Put your agent on a machine that isn't your laptop. A reasonable Hetzner bare metal box runs €30-50/month. The VM is just there: your session survives closing your laptop, you can reconnect from anywhere, and a multi-hour autonomous task doesn't require you to babysit it. If the agent does something catastrophic, it does it to the remote machine.
This is where the isolation story gets serious. Bare metal gives you full root access. You can use robust tools like nftables to control egress, and configure auditd for syscall logging. You can build exactly the control plane you want on hardware you control.
You can also spend the rest of your life maintaining it. Host provisioning, OS updates, SSH hardening, egress rules, session management, snapshot pipelines, observability. None of it is hard in isolation. All of it together is a meaningful commitment for something that's supposed to be making you more productive. And egress policy deserves honesty: writing nftables rules that correctly handle DNS-based exfiltration and protocol tunneling, while logging violations such that you can query them, is a project.
Option 5: Managed Remote VM
iron.sh.
Same isolation primitive as option 4: dedicated bare metal, full KVM, with the control plane already built. Egress enforcement via nftables, secrets proxying so credentials aren't sitting in plaintext in the VM, persistent audit logging of what the agent actually did, snapshot/restore, SSH routing for concurrent sessions. And the same persistence benefit as option 4. You get a long-running VM that's available whenever you are, from wherever you are, without keeping a Hetzner box provisioned and patched yourself.
If you've read this far and want the strongest possible security posture, this is it. No maintenance, no compromises on the isolation layer, no control plane to build.
Which One
If you're a solo developer running agents on your own codebase with your own credentials, start with option 1. Agent Safehouse takes ten minutes to set up and covers the common failure modes.
If you want the strongest local isolation available and are willing to write some config, Gondolin is the right tool. Budget a weekend.
If you're running agents against production credentials, sensitive codebases, or untrusted inputs, local isn't the right answer regardless of what you put around it. The question is whether you want to build and operate the remote infrastructure yourself or not.
The threat model your agent operates in should determine your choice. Not what was easiest to set up on a Saturday afternoon.