Your Coding Agent Needs a Sandbox: Docker Sandbox vs Native vs DevContainers

Coding agents like Claude Code, Codex, and Gemini CLI run shell commands, edit files, and make network requests. As models get stronger, we let them decide what to run: that’s the whole point. But a prompt injection or compromised dependency can turn that autonomy against you. OpenClaw showed what happens when capable agents run without containment.

Not everyone using these tools thinks about this, and agent capabilities grow faster than the guardrails around them.

Why Containment Needs to Be by Design

Permission prompts are the default safety mechanism in most coding agents. The agent wants to run a command, you approve or deny. In practice, this breaks down:

• Approval fatigue. After the 20th prompt you start clicking “yes” without reading.
• Knowledge gap. Most users can’t evaluate whether curl -s https://example.com | sh is safe.
• Speed vs. safety. The whole point of an agent is autonomous work. Prompting for every action defeats the purpose.

The answer isn’t better prompts. It’s containment: restricting what the agent can do, regardless of what it tries to do. If the agent can’t access files outside the project and can’t reach unauthorized network endpoints, a prompt injection or malicious dependency is limited to the sandbox. The damage is contained by architecture, not by user vigilance.

What a Sandbox Actually Does

A sandbox wraps the agent’s execution environment in two boundaries:

• Filesystem isolation limits what the agent can access and modify on your device. Typically: write access to the project directory, read-only or denied everywhere else.
• Network isolation prevents the agent from pulling in malicious payloads and leaking data out. Typically: all outbound traffic denied by default, with specific domains allowlisted.

You need both. Filesystem isolation without network control still lets the agent exfiltrate anything it can read. Network isolation without filesystem control lets it tamper with system files or read secrets, even if it can’t send them anywhere.

The question is: where do you draw the boundary?

Native Sandboxing: What the Agents Ship With

Claude Code, Codex, and Gemini CLI all have built-in sandbox modes that use OS-level primitives to restrict filesystem and network access for every command they run. Not all agents have caught up: OpenCode’s sandboxing is, at time of writing, still an open issue, with maintainers acknowledging that working directory restrictions can be bypassed through bash.

The approach is similar across all three: wrap every command in OS restrictions so the agent can’t reach beyond its workspace. Each provides filesystem isolation (write to the project directory only) and some form of network isolation (deny by default, allowlist specific domains). All run on your host, using your kernel.

This is practical and effective. But they share a fundamental limitation: the malicious code runs on your host OS, sharing your kernel.

The isolation is only as strong as the OS sandbox implementation.

Docker Sandbox: A Different Isolation Boundary

Docker recently released sandbox support for coding agents in Docker Desktop. It takes a fundamentally different approach: instead of restricting a process on your host, it puts the agent in a dedicated microVM with its own Linux kernel, running on native virtualization (macOS Virtualization.framework, Windows Hyper-V).

Put your agents in a real box [...] the current things out there are largely built on either deprecated technologies or compromise on the isolation.

— Mark Cavage, President & COO, Docker

Your Mac / PC
├── Docker Desktop
│   └── MicroVM (separate kernel)
│       ├── Private Docker daemon
│       ├── Coding agent (Claude, Codex, Gemini, ...)
│       ├── File sync (copy-based) ↔ host project
│       └── Network proxy (host.docker.internal:3128) → filtered outbound
└── Your other apps (isolated)

Each sandbox is fully self-contained:

• Private Docker daemon. The agent can build images and run containers inside the sandbox. It cannot see or touch your host’s Docker environment.
• Copy-based file sync. Your workspace is copied into the VM at the same absolute path, not volume-mounted. Changes sync back to the host, but the agent only sees your project files. This is key: even if the agent is fully compromised, there’s nothing else on the filesystem to reach.
• Network filtering proxy. All outbound traffic flows through an HTTP/HTTPS proxy that enforces domain allowlists. Sandboxes can’t reach host localhost or talk to each other.
• Persistence. Sandboxes persist across runs (installed packages, Docker images, config) until you explicitly remove them with docker sandbox rm.

Inside the Docker sandbox, agents run without permission prompts: the VM itself is the safety boundary. The agent can do whatever it wants inside the box, and none of it reaches your host.

DevContainers are also an option: standard Docker containers with iptables firewall rules. They offer more customization but share the host kernel (namespace isolation only, not hypervisor) and require more setup. Anthropic’s docs cover the setup.

Comparing the Isolation

To make this concrete, consider what happens when a coding agent installs a compromised npm package that tries to read your private keys (~/.ssh/id_rsa) and exfiltrate them:

• No sandbox: If the user approves the command (or has granted broad permissions), it succeeds. The agent runs as you. Your private keys are gone.
• Native sandbox (Claude/Codex): The filesystem restriction blocks the read. Even if it got through, the network proxy blocks the exfiltration. But the malicious code is running on your host OS, sharing your kernel. A sandbox escape (Seatbelt bypass, Landlock privilege escalation) gives it everything.
• DevContainer: The file doesn’t exist inside the container. Network firewall blocks the outbound request. But the container shares your kernel. A container escape reaches the host.
• Docker sandbox: The file doesn’t exist inside the microVM. Network proxy blocks the exfiltration. And even if the malicious code achieves a full breakout from its environment, it’s still inside a VM with its own kernel. To reach your host, it would need to escape through the hypervisor: the same boundary that separates tenants on AWS and Azure.

Native sandboxing restricts what a process can do. Docker sandboxes restrict where the process exists.

Getting Started

For Claude Code:

docker sandbox run claude ~/my-project

Support for Codex, Gemini CLI, Copilot, Kiro, and Cagent is in development. Prerequisites: a recent Docker Desktop, macOS or Windows.

A few things to know upfront:

• The first boot is slow. The initial microVM setup adds noticeable startup latency. Subsequent runs are faster, but expect the first one to take a while. This is the main UX friction point.
• File sync between host and VM introduces slight lag on file changes.
• Some tools (watchman, Docker-in-Docker) may need configuration adjustments inside the sandbox.
• Network domain allowlisting requires manual approval: the agent will prompt you when it needs to reach a new domain.

None of these are dealbreakers, and they’re improving fast.

Mapping to OWASP’s Top 10 for Agentic Applications

OWASP released the Top 10 for Agentic Applications in late 2025. It’s a useful framework for thinking about what sandboxing does and doesn’t cover.

Five of ten risks get strong or partial mitigation from sandboxing. But it doesn’t address goal hijacking, context poisoning, or trust exploitation. Those are model-level or organizational problems. An agent can still be tricked into acting against you inside a perfectly isolated sandbox: it just can’t reach as far when it does.

The Bigger Picture

Sandboxing is execution-layer defense: it contains the blast radius. One layer among many. Identity, authorization, audit, cross-domain trust, and more are needed to complete the picture. The infrastructure for trusted agents involves all of these layers working together.

The people most at risk from unsandboxed agents aren’t the ones reading OWASP frameworks. They’re the ones who just want to get work done. Whether it’s a built-in /sandbox command or docker sandbox run, the bar is low enough that there’s no reason not to use one.

As a best practice: run your coding agents in a Docker sandbox. It’s the strongest isolation available today, and because the VM is the safety boundary, you can let agents run non-interactively without permission prompts. That’s where the real productivity gain is: agents that work while you don’t watch.

Resources

I publish explainers on the protocols shaping agent trust, and write about the gaps between where we are and where we need to be. Follow along if this matters to you.