You Should Run Claude Code in a Sandbox

Claude Code operates as a local terminal agent with broad execution capabilities: it can read local files, modify source code, execute shell commands, and install system packages. While these capabilities are necessary for autonomous software development, they also present a significant security risk if the agent is executed directly on a production workstation.

The primary security threat does not stem from malicious intent by the underlying model, but rather from the adversarial nature of untrusted inputs. For example, a repository's README.md may contain an embedded prompt injection designed to hijack the agent's behavior. Similarly, an automated dependency installation might triggers unverified package lifecycle scripts, or a generated test file could execute unauthorized system commands. Ultimately, local coding agents inherit the security risks of every repository, dependency, script, and container image they touch.

While built-in guardrails offer basic protection, they cannot entirely eliminate the attack surface without rendering the agent ineffective. The most reliable security boundary must therefore be implemented at the runtime layer.

The Unsandboxed Workstation Surface

Executing claude natively on a development machine exposes highly sensitive configuration directories and environment variables directly to the runtime process:

- ~/.ssh/           (SSH keys and credentials)
- ~/.aws/           (Cloud provider credentials)
- ~/.kube/config    (Kubernetes cluster access configuration)
- ~/.npmrc          (Private registry authentication tokens)
- ~/.gitconfig      (Git commit signing identities)
- Environment variables containing session tokens and API keys
- The full local filesystem accessible to the user account
- Unrestricted local network and internet access

An attacker does not need direct access to the workstation to exploit these resources. If a persuasive prompt injection causes the agent to read and exfiltrate sensitive files, the breach occurs entirely through code the agent was instructed to parse. Security boundaries are determined by what the execution environment exposes, making host isolation critical.

Standard Isolation: Docker Containers

A standard Docker container restricts the agent's visibility by enforcing a scoped filesystem. The agent can only interact with files explicitly mounted into the container and resources permitted by the runtime configuration.

docker run --rm -it \
  --memory=4g \
  --cpus=2 \
  --mount type=bind,src="$(pwd)",dst=/workspace \
  --workdir /workspace \
  --env ANTHROPIC_API_KEY \
  node:20-slim \
  sh -lc 'npm install -g @anthropic-ai/claude-code && exec claude'

This runtime configuration isolates the agent using standard Docker flags:

• --rm Destroys the container upon exit, ensuring no temporary files, dependencies, or modified tooling persist across sessions.
• --mount type=bind,src="$(pwd)",dst=/workspace Limits filesystem visibility strictly to the active project directory, blocking access to home directories or adjacent code repositories.
• --memory=4g --cpus=2 Imposes resource constraints to prevent runaway test execution or dependency compilation from exhausting host system resources.
• --env ANTHROPIC_API_KEY Explicitly passes the single environment variable required for agent authentication, keeping unrelated host tokens hidden.
• sh -lc 'npm install -g @anthropic-ai/claude-code && exec claude' Dynamically provisions Claude Code within an isolated node runtime, maintaining a clean host system.

Hardware-Level Isolation: Dedicated Sandboxes

Docker provides a dedicated agent sandboxing platform via the sbx CLI tool, which simplifies configuration while tightening the security boundary:

brew install docker/tap/sbx

With this utility installed, Claude Code can be initialized inside an isolated sandbox with a single command:

sbx run claude

Rather than spinning up a standard container, Docker provisions a microVM—a lightweight virtual machine backed by a dedicated kernel and hardware virtualization extensions. This introduces a fundamentally stronger security boundary than standard containers, which share the underlying host kernel.

# Launch Claude within a microVM sandbox
sbx run claude

# Run with automated execution permissions
sbx run --dangerously-skip-permissions claude

The --dangerously-skip-permissions flag suppresses interactive approval prompts for agent operations. While executing unverified agent actions without approval introduces extreme risk on a native host, the blast radius inside a microVM is securely contained within the virtualized environment. However, proper care must still be taken, as the agent maintains access to any credentials or network pathways explicitly exposed to the sandbox.

Containers vs. MicroVMs: Architectural Trade-Offs

Manual Docker configurations are most applicable when:

• You require precise control over custom base images and pre-installed developer tooling.
• Your workflow is already integrated into an existing Docker environment with minimal overhead.
• You prefer to manage shell aliases and explicit container lifecycles manually.

Docker Sandboxes (sbx) are the preferred approach when:

• Your security architecture requires a strict hardware-virtualized isolation layer.
• You want a zero-configuration, standardized command across an entire engineering team.
• The workspace requires running nested container workloads inside the agent sandbox.

The structural distinction between these approaches is meaningful for security compliance. Standard containers share the host kernel; a kernel vulnerability or container escape can directly expose the host system. MicroVMs mitigate this risk by maintaining an independent virtualization layer and unique kernel, making breakout attempts significantly more complex.

The Bottom Line

Running an execution agent like Claude Code directly on a development workstation places an untrusted automation engine within the same blast radius as your infrastructure credentials and core source code repositories.

Sandboxing shifts the focus from hoping an LLM never makes a mistake to ensuring that mistakes remain safely contained. For minimal setup overhead and robust hardware isolation, implement sbx. For tailored control over the underlying runtime environment, isolate workloads using standard Docker configurations.

Further Reading

• Docker Sandboxes — Getting started guide.
• Anthropic Documentation — Claude Code security model and threat mitigations.
• OWASP Top 10 for LLMs — Detailed breakdown of prompt injection vectors.