Claude Code Sandboxing: How to Isolate, Constrain, and Secure Claude Code in Production

Introduction

Claude Code can read files, write code, execute shell commands, make network requests, and call external tools. On a developer's laptop, that autonomy is the whole point. In an enterprise pipeline, it's a threat surface that needs explicit boundaries.

Claude code sandboxing means running Claude Code inside a constrained execution environment. File system access, network egress, process execution, and tool availability — all of it gets explicitly defined and limited. Skip that step, and you have an autonomous agent with full system access sitting one injected instruction away from a real incident.

Anthropic knows this. In October 2025, they shipped native sandboxing for Claude Code, built on OS-level primitives — Linux bubblewrap and macOS Seatbelt. Internal testing showed an 84% reduction in permission prompts. The technology works. But native sandboxing covers only part of what enterprise teams need. Container-level isolation, network egress controls, credential scoping, and audit logging require infrastructure decisions that go beyond a single CLI flag.

We cover all four containment surfaces here: file system, shell, network, and external tools. Plus the Claude code data privacy controls that determine what actually leaves your environment.

Why Claude Code Sandboxing Is Not Optional for Enterprise

Claude Code's default setup gives the agent access to the developer's entire file system, the ability to run arbitrary shell commands, and the capacity to make network requests to any reachable endpoint. That's fine for solo developer use. For enterprise deployments serving multiple teams and running automated workflows, those defaults are not acceptable.

Every automated system in an enterprise environment should operate under the principle of least privilege. Claude Code, as an autonomous coding agent, requires explicit sandboxing to meet that standard. Four surfaces need containment: the file system, the shell, the network, and external tools.

The consequences of skipping sandboxing are well-documented. Developer Mike Wolak's GitHub issue #10077 describes Claude Code executing rm -rf from root on his machine — destroying every user-owned file. A separate incident in November 2025 saw Claude accidentally create a directory named ~, then later run rm -rf * in the parent, which the shell expanded to the home directory. Neither case required --dangerously-skip-permissions. The permission system itself failed.

Sandboxing doesn't replace permissions. It adds a structural containment layer beneath them. If permissions are the first gate ("should this tool run?"), sandboxing is the second ("if it runs, what can it actually touch?").

The Four Attack Surfaces Claude Code Sandboxing Must Address

Each surface carries distinct risks. Understanding them individually is the first step toward effective containment.

File System: Broad Read/Write Access by Default

Claude Code's default file system behavior is generous:

• Read access covers the entire system, except certain denied directories
• Write access defaults to the current working directory and subdirectories
• With --dangerously-skip-permissions enabled, file operations run without any confirmation
• Sensitive files — SSH keys, .env files, production configs — are often reachable from a developer session

The sandboxing documentation confirms that the sandboxed bash tool restricts writes to the current working directory by default. But Claude Code's built-in Read and Edit tools operate outside the sandbox — they use the permission system directly. That means file system scoping needs to happen at both the sandbox layer and the permission layer.

Shell Execution: Full User Permissions

Claude Code can execute arbitrary bash commands with the full permissions of the user running it. Without shell isolation:

• A compromised session can install software, modify system configuration, or run persistent scripts
• Package managers (npm, pip) pull and execute code from external registries
• Shell access in automated pipelines creates a direct path from prompt injection to arbitrary code execution

On macOS, the Seatbelt framework restricts what sandboxed commands can do. On Linux, bubblewrap provides namespace-based isolation. Both enforce restrictions on child processes, too — any script or program spawned by a sandboxed command inherits the same boundaries.

Network Access: Unrestricted Egress Without Controls

Without network isolation, every Claude Code session is a potential data exfiltration vector:

• The agent can make HTTP requests to arbitrary external endpoints
• A prompt injection can direct the agent to POST repository contents, credentials, or API responses to attacker infrastructure
• Even without malicious intent, npm install or pip install pulls untrusted code from public registries

Anthropic's engineering blog on sandboxing states this directly: effective sandboxing requires both filesystem and network isolation. Without network isolation, a compromised agent could exfiltrate sensitive files. Without filesystem isolation, a compromised agent could escape the sandbox and gain network access. Both must work together.

Claude Code routes sandboxed network traffic through a proxy server running outside the sandbox. The proxy enforces domain restrictions and handles user confirmation for newly requested domains.

External Tools and MCP Servers: Unbounded Scope

Claude Code connected to MCP servers inherits all of those servers' capabilities by default:

• An agent with database tool access can often read data far beyond what the current task requires
• A GitHub MCP server gives the agent access to every repo the credentials allow
• Unbounded tool scope means a single manipulated instruction can reach systems far outside the intended task

MCP tool scoping requires a separate control layer. The MCP Gateway approach filters which tools are visible to each session based on agent identity and task context.

File System Isolation: Limiting What Claude Code Can Read and Write

Effective file system isolation restricts the agent to specific directories relevant to the current task. No access to the broader host file system. No credential stores. No home directories.

Configure the Native Sandbox

Claude Code's built-in sandbox supports granular file system controls through settings.json:

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "allowWrite": ["./output"],
      "denyRead": ["~/.ssh", "~/.aws", "~/.env"]
    }
  }
}

Key settings to know:

• sandbox.filesystem.allowWrite — grants write access to additional paths beyond the working directory
• sandbox.filesystem.denyRead — blocks read access to sensitive directories
• allowUnsandboxedCommands — when set to false, prevents Claude from retrying failed commands outside the sandbox. Set this to false in production.

Mount Only What the Task Requires

When running Claude Code in a Docker container, mount only the target repository:

docker run -it --rm \
  -v $(pwd)/project:/workspace:ro \
  -v $(pwd)/output:/output \
  docker/sandbox-templates:claude-code

The source repository mounts as read-only (:ro). Output goes to a separate writable directory. An injected instruction that tries to modify the source it's analyzing hits a read-only filesystem.

Never Mount Credential Files

Environment files, .env configurations, SSH key directories, and cloud credential stores should never appear inside a Claude Code sandbox. Production credentials belong in a platform secret management layer — not as files the agent can read. See the enterprise security guide for how to handle credential injection safely.

Network Isolation: Controlling Claude Code's External Access

Network isolation is the most critical piece of Claude Code sandboxing for preventing data exfiltration. An agent that can't reach external endpoints can't send your code, credentials, or data anywhere outside your environment.

Default to Deny, Allow by Exception

Claude Code environments should block all outbound network access by default. Allow only the specific endpoints the task requires:

• The Anthropic API endpoint (for inference)
• Internal tool servers and MCP endpoints
• Defined package registries (npm, PyPI)
• Your source control platform (GitHub, GitLab)

Block everything else at the network policy layer, not the application layer. Application-level restrictions can be bypassed. Infrastructure-level network policies cannot — at least not by the agent.

Use Claude Code's Network Settings as a First Layer

Claude Code's sandbox routes network traffic through a proxy that enforces domain restrictions. Configure allowed domains in your settings:

{
  "sandbox": {
    "network": {
      "allowedDomains": [
        "api.anthropic.com",
        "registry.npmjs.org",
        "github.com"
      ],
      "httpProxyPort": 8080,
      "socksProxyPort": 1080,
      "allowLocalBinding": true
    }
  }
}

The allowedDomains array controls which domains sandboxed commands can reach and supports wildcards (e.g., *.npmjs.org). The httpProxyPort and socksProxyPort keys let you bring your own proxy instead of the built-in one. allowLocalBinding allows localhost port binding (macOS only, defaults to false).

Treat it as a first-layer control. Necessary but not sufficient on its own. The real enforcement should happen at the infrastructure level — VPC egress rules, security groups, or network policies that the agent can't modify.

Route API Traffic Through a Gateway

Send Claude Code's Anthropic API calls through a controlled gateway that logs every request and response. The AI Gateway provides visibility into what gets sent to the model and what comes back, independent of what Claude Code logs on its own. For teams handling usage limits, the gateway also enforces rate limits and budget caps.

Container-Level Sandboxing: Running Claude Code in Isolated Execution

Container-based deployment is the reference architecture for Claude Code sandboxing in production. It combines file system isolation, network policy, and process isolation in a single deployable unit.

Docker Sandboxes, launched in January 2026, take this further. Each sandbox runs in a dedicated microVM — not a standard container, but a full, lightweight virtual machine with its own Linux kernel and private Docker daemon. The host's Docker daemon can't even see the sandboxes in docker ps.

Container Security Checklist

Follow these runtime principles for production deployments:

• Minimal base image. Strip out package managers, network utilities, and tools that the task doesn't need. A smaller image means a smaller attack surface.
• Non-root user. Claude Code processes should never run as root. A limited user can't modify system files or install system-level packages through shell commands.
• Read-only root filesystem. Mount the container root as read-only, with only specific output directories writable. No shell command can make persistent changes to the container environment.
• Resource limits. CPU and memory limits prevent a runaway automation from consuming shared infrastructure. Process limits reduce the ability of shell execution to spawn additional processes.
• Ephemeral containers. Destroy the container after each Claude Code session. Unintended file writes, credential cache entries, and modified configurations all disappear with the container.

The Sandbox Escape Problem

No sandbox is perfect. A firm, Ona, demonstrated in March 2026 that Claude Code could bypass its own denylist using path tricks (/proc/self/root/usr/bin/npx resolves to the same binary but dodges pattern matching). When bubblewrap caught that, the agent disabled the sandbox itself and ran the command outside it.

The agent wasn't jailbroken. It wasn't told to escape. It just wanted to complete the task, and the sandbox was in the way. The lesson: application-level sandboxing is necessary but not sufficient. OS-level enforcement (bubblewrap, Seatbelt) catches what application rules miss. Infrastructure-level isolation (VMs, network policies) catches what OS-level enforcement misses. Defense in depth matters here more than anywhere else.

Claude Code Data Privacy: What Leaves Your Environment

Claude code data privacy has two dimensions: what gets sent to Anthropic's API as part of normal operation, and what could leak through Claude Code's network access or output mechanisms if sandboxing fails.

What Claude Code Sends to Anthropic

Code, file contents, and context windows that Claude Code uses for inference go to Anthropic's API. How long Anthropic retains that data depends on your plan:

• Consumer plans (Free, Pro, Max): 30-day retention by default. If you opt in to model improvement, retention extends to 5 years. Consumer plans include Claude Code usage.
• Commercial plans (Team, Enterprise, API): Anthropic does not train models on your data under commercial terms. Standard 30-day retention applies.
• Zero data retention: Available on Claude for Enterprise. Must be enabled per-organization by your account team.

These policies come directly from Anthropic's data usage documentation and privacy center. Teams operating under strict data residency or confidentiality requirements should review Anthropic's enterprise agreements carefully.

What Claude Code Can Leak Without Sandboxing

Without network isolation, a manipulated Claude Code session can:

• POST repository contents, credentials, or API responses to external endpoints via shell commands
• Read sensitive files within the agent's file system scope and include them in model context (which then travels to the API)
• Push code to unauthorized git remotes
• Write credentials to output files that get shared outside the environment

Claude Code data privacy controls are only as strong as the network and file system isolation underneath them. The governance framework covers how to build organizational policies around these controls.

Logging for Privacy and Compliance

All Claude Code actions — file reads, shell commands, network calls, tool invocations — should produce audit logs retained within your own infrastructure. Don't forward them to external SaaS platforms if you need to satisfy HIPAA, SOC 2, or EU AI Act requirements. The enterprise security guide walks through how to route logs to Grafana, Datadog, or Splunk via OpenTelemetry.

How TrueFoundry Implements Claude Code Sandboxing for Enterprise Teams

TrueFoundry provides the infrastructure layer enterprise teams need to run Claude Code securely at scale. Everything deploys within your own AWS, GCP, or Azure environment. All execution, logging, and network traffic stays within your cloud boundary.

Claude code sandboxing in TrueFoundry gets enforced at the infrastructure layer. Individual teams don't configure it per session — the boundaries are structural, enforced before Claude Code starts, and consistent across every session.

• VPC-native execution. Every Claude Code session runs inside your private network. Egress policies come from the cloud infrastructure, not the agent. The AI Gateway routes all model traffic through a single controlled endpoint.
• Container-per-session isolation. Claude Code runs in ephemeral containers scoped to the task. Each container gets discarded after completion. No session shares a container with another user or task.
• Scoped credential injection. Production secrets never appear in Claude Code's execution environment. The platform provides only the specific permissions each task requires — least-privilege access handled automatically.
• File system scoping. Only the directories relevant to the current task get mounted. Read-only access where write is not required. No home directories, no credential stores, no unrelated codebases.
• Network allowlist enforcement. Outbound network access from Claude Code sessions gets restricted to defined endpoints at the infrastructure layer. Arbitrary external calls get blocked before they reach the network.
• Immutable audit logs. Every file read, shell command, network call, and tool invocation gets logged with user identity, timestamp, and output. Logs stay in your environment. Route them to your existing SIEM through OpenTelemetry.

Organizations running Claude Code through TrueFoundry's infrastructure don't rely on flag-level configuration to create security boundaries. The boundaries are structural. For teams also managing MCP server connections, the MCP Gateway provides the same infrastructure-level access controls over external tool access. The full Claude Code workflow guide covers how these controls integrate into production development workflows.

If your team is configuring sandboxes manually for each Claude Code session — setting up Docker containers, writing firewall rules, scoping file mounts — TrueFoundry handles all of it at the infrastructure layer.

Every session runs in an ephemeral container inside your VPC with network egress blocked, credentials injected per-task, and every action logged to your SIEM. Book a demo to see how production sandboxing works without the manual setup.