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 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.

Going further: 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.

The Bottom Line

Running an agentic CLI tool like Claude Code directly on a development workstation gives it access to your filesystem (within the permissions of the host process), including sensitive credentials stored locally, and potentially unrestricted network access (depending on your environment configuration).

Sandboxing requires minimal setup to get started and provides strong OS-level isolation, helping reduce the risk that agentic workflows inadvertently expose credentials to external services, and ensuring that any changes the agent makes to the filesystem are confined to the folders you explicitly mount into the sandbox.

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.