Skip to content

Claude Code

Claude Code’s sandbox ships as an open-source npm package

5 min read

Written by an AI model from the linked sources and checked against them by a second model. How we work

All about: Claude Code versions and changes →

The sandbox that Anthropic says cut permission prompts by 84% in its internal Claude Code use is now a standalone open-source tool: sandbox-runtime (srt) went up on npm under the Apache-2.0 license on October 25, and it can wrap any process, local MCP servers included, without a container. If you run MCP servers locally, putting one inside it takes a change to one field in .mcp.json, but with no settings file srt still leaves every file readable, and Anthropic’s repository calls the project a research preview whose APIs and configuration formats may evolve.

The README walks through the swap on the filesystem MCP server: the entry’s command changes from npx to srt, and npx moves to the front of the arguments. The limits then come from ~/.srt-settings.json. Without that file srt runs on built-in defaults: no network access, no writes outside the default write paths, unrestricted reads. A file that exists but is empty, unreadable or fails validation is an error, and srt exits instead of falling back, because falling back would drop the file’s denyRead, allowRead and credential rules along with everything else in it.

For Claude Code users the package fills a specific gap. The built-in sandbox covers shell commands only; Claude’s file tools, MCP servers and hooks run outside it, and the Claude Code docs say the way to put them behind one boundary is to run the Claude Code process itself in a container, a VM or this sandbox runtime. The same docs note that the built-in sandbox is off by default and is turned on with /sandbox or sandbox.enabled. srt’s restrictions apply to the whole process tree, so wrapping Claude Code also takes in the commands the harness runs on its own, the kind of unwrapped git call that let a poisoned repo out of the sandbox in September.

How the rules resolve

Reads and writes run on opposite logic. Reads are open by default: you deny a broad region such as /Users and re-allow paths inside it, and allowRead beats denyRead. The exception is a deny entry more specific than the allowed region around it, such as **/.env or ./secrets under an allowed ., which stays denied. Writes are closed by default, denyWrite beats allowWrite, and an empty allow list means no writes at all.

Network access is allow-only as well: an empty allowedDomains list means no network. On Linux srt uses bubblewrap and removes the sandboxed process’s network namespace entirely, so traffic can only reach proxies on the host through Unix sockets mounted into the sandbox. On macOS it generates Seatbelt profiles for sandbox-exec that permit just one localhost port, where the proxies listen. An HTTP proxy carries HTTP and HTTPS, a SOCKS5 proxy the rest of the TCP traffic, and both enforce the domain lists, wildcards included. Local IPC sockets get their own allowlist.

Harness builders can change the config while a command runs with --control-fd, which reads one complete JSON config per line from a descriptor the caller opened. Each line replaces the whole config, so a key it leaves out goes back to its default. Only part of it applies live: domain allow and deny lists take effect on the next connection, and SigV4 policies on the next request, while filesystem rules stay as they were when the command was wrapped. A rule the command must start under belongs in the settings file. On macOS and Linux srt points the descriptor’s slot at /dev/null for the sandboxed command, so nothing inside can read the updates or write a config of its own.

The rest of the feature list: experimental TLS termination for inspecting HTTPS traffic, masking of credentials in environment variables and files, AWS SigV4 request signing with masked keys, and, on macOS, real-time alerts from the system’s sandbox violation log. srt proxy runs only the HTTP proxy, with no sandboxed child, and forwards a request only when a separate decider process allows it.

Windows is alpha

The Windows build ships a bundled srt-win.exe for x64 and arm64 and needs a one-time elevated windows-install step, which creates a dedicated srt-sandbox local user account and a machine-wide set of Windows Filtering Platform filters. The sandboxed process runs as that account with a write-restricted token and explicit ACLs on the working tree, and its outbound connections are blocked except to the proxies on loopback.

Anthropic documents the holes. Tools built on Schannel, the system TLS stack, can’t be used inside the sandbox: System32\curl.exe, PowerShell’s Invoke-WebRequest, .NET HttpClient and winget. The filters don’t follow a process that puts a different token on a thread before creating a socket, and traffic a system service such as Windows Update carries on the process’s behalf escapes the fence. File-access changes sent over the control channel mid-run don’t apply on Windows either; the set applied at startup stays in force for the session.

Claude Code’s docs still list macOS, Linux and WSL2 for its own sandbox, and say that on native Windows Claude Code runs commands unsandboxed.

No comments yet. Be the first.

Join the conversation

Sign in to leave a comment. It appears after moderation.