Claude Code Security Deep Dive: How Dual Sandboxing Prevents Prompt Injection at the OS Level

When an AI coding agent can read files, run shell commands, and make network calls, the security model matters as much as the model itself. Claude Code addresses this through a dual sandboxing design — two independent isolation layers that each block a different class of attack, and together contain even a successful prompt injection.

Two Isolation Layers Working Together

Filesystem Isolation

Claude Code restricts its read/write access to the current working directory. Attempts to access parent directories, home folder contents (SSH keys, shell configs, credential files), or system paths are blocked at the kernel level. Critically, this restriction covers not just Claude's direct actions but also any subprocesses or scripts it spawns — so a prompt-injected instruction to run a script that reads ~/.ssh/id_rsa is blocked at the OS level, not by the model's own judgment.

Network Isolation

All outbound network traffic is routed through a unix domain socket to a proxy server that runs outside the sandbox boundary. The proxy validates each connection request against a configurable domain allowlist. Claude Code cannot make direct internet calls — every request goes through the proxy, which enforces traffic rules and can be customized to allow or block specific hosts. This prevents a compromised agent from silently exfiltrating source code, credentials, or API keys.

Why Both Layers Are Required

Each isolation layer alone is insufficient. Network isolation without filesystem isolation: the agent cannot exfiltrate data over the network, but it can still modify shell scripts, inject malicious code into build artifacts, or tamper with files that run with elevated permissions later. Filesystem isolation without network isolation: the agent cannot touch sensitive files, but it can read credentials in the allowed working directory and exfiltrate them through HTTP calls. The dual design ensures that even a fully compromised agent — one that has successfully executed a prompt injection — cannot reach beyond the sandbox boundary.

OS-Level Implementation Details

On Linux, Claude Code uses bubblewrap — a lightweight sandboxing tool that applies user namespace isolation without requiring root privileges. On macOS, it uses the seatbelt security framework. Both operate at the kernel level, which means restrictions apply universally to everything Claude Code runs, including bash scripts, Node.js subprocesses, and compiled tools. The sandboxing is not a wrapper around specific actions — it is a constraint on the process itself.

Impact on Developer Experience

The design reduces permission prompts by approximately 84% during autonomous operation. Claude can execute Bash commands, write files, and run build tools inside the sandbox without prompting. It only surfaces a notification when it attempts an action that falls outside the sandbox boundary — at which point the developer decides whether to approve an exception. This makes autonomous workflows practical without requiring blanket trust.

Cloud Execution and Credential Proxying

The web version of Claude Code runs each session in isolated cloud infrastructure, extending the sandbox model to the server level. Sensitive credentials — Git tokens, signing keys, deployment secrets — are held outside the sandbox entirely, managed by a credential proxy. When Claude Code needs to push a commit, the request routes through the proxy, which validates the operation and handles authentication to the remote service. Claude never has direct access to the credentials themselves, even in the cloud model.