No container needed: what Anthropic's sandbox-runtime actually cages, and what it doesn't

First, a correction: this is not a tool that appeared out of nowhere on October 24

On October 24, 2026, several tech outlets covered Anthropic's sandbox-runtime (the command is called srt) on the same day. Read only the headlines and you would think Anthropic had just released a brand-new sandbox. The repository tells a longer story: anthropics/sandbox-runtime was created on GitHub on October 20, 2025, and now has 886 commits and 44 releases, with the npm package @anthropic-ai/sandbox-runtime at version 0.0.81. It began as the implementation behind Claude Code's sandboxed bash tool, and Anthropic described its approach in its October 2025 post "Beyond permission prompts." The accurate framing is that an internal component that had been running inside Claude Code for a year stepped into the spotlight on October 24 as a standalone tool anyone can wrap around their own agents and MCP servers. This article's news peg is that October 24 wave of coverage and the current state of the package, not a first-release day. In agent security, mistaking "got covered" for "got verified" is exactly the kind of error worth avoiding.

One boundary is worth drawing early. This site previously covered Vercel's durable-harness, which keeps agents running across crashes without re-burning tokens. That solves "staying alive." srt solves "staying inside the lines." One is about continuity, the other about permission boundaries, and they complement rather than overlap.

What srt is: a cage built from the operating system's own parts

The repository README defines srt in one line: a lightweight sandboxing tool for enforcing filesystem and network restrictions on arbitrary processes at the OS level, without requiring a container. Install it globally with npm (it needs Node.js 22.12 or newer, unpacks to about 11.4 MB, and is Apache-2.0 licensed), then prefix any command with srt: srt npm install, srt node server.js. It also works as a TypeScript library through a SandboxManager you can wrap around a spawned command. And it can cage an MCP server with a one-word change: in .mcp.json, swap a server's command from npx to srt, pass the original command as arguments, and put the rules in ~/.srt-settings.json.

"Without a container" is its biggest selling point and its easiest point to misunderstand. It does not claim containers are useless. It uses each operating system's native isolation primitives: sandbox-exec with dynamically generated Seatbelt profiles on macOS, bubblewrap on Linux (plus socat and ripgrep), and on Windows — still alpha — a dedicated srt-sandbox local account, a Windows Filtering Platform egress fence, and explicit file ACLs. The same rules are enforced by different mechanisms per platform, so a configuration proven on a macOS laptop is not proven on a Linux CI box. Cross-platform teams need to test per platform, not just on the developer machine.

The dual isolation model: read, write, and network follow three different defaults

The part of srt most worth reading carefully is its three default rules, because they are not symmetric, and copying one wrong leaves a hole:

• Read is deny-then-allow: reads are allowed everywhere by default. You deny broad regions (say, the whole home directory) and re-allow specific paths inside them. A more specific deny still wins over a broader allow: denyRead of **/.env keeps .env files unreadable even when the working directory is allowed.
• Write is allow-only: writes are denied everywhere by default. You must explicitly allow paths such as the working directory or /tmp. An empty allow list means no writes at all.
• Network is allow-only: all network access is denied by default. You must explicitly allow domains, with wildcard and port support, for example *.npmjs.org or api.example.com:443. An empty allowed-domains list means no network.

These rules apply to the whole process tree: the command, the scripts it launches, and the subprocesses those scripts launch. That matters because an agent's typical path to mischief is rarely the main process itself. It is a script run mid-task, an install step, or a subcommand steered off course by an injected prompt. A sandbox that only constrains the main process constrains almost nothing in an agent workflow.

The network side deserves a closer look. A sandboxed process has no network path of its own. Its traffic must go through HTTP and SOCKS5 proxies running on the host. On Linux the sandboxed process's network namespace is removed entirely, and the proxies are reached through Unix sockets bind-mounted into the sandbox. On macOS the Seatbelt profile permits only one localhost port, where the proxies listen. The proxies check every request against your domain allowlist and denylist, and they also check resolved addresses: an allowed domain that resolves to a loopback address or a cloud metadata address is still blocked. That check targets the "the domain is legitimate, the resolution is not" bypass, which is precisely the trick an agent would use to reach instance metadata and steal credentials.

The hole hiding in the defaults: reads are open unless you close them

Run srt with no configuration file and the README's defaults are: no network, no writes outside the default write paths, and unrestricted reads. In other words, a "default" srt sandbox still lets an agent read sensitive files on your machine. Claude Code's own sandboxing documentation says the same thing plainly: a sandboxed command can read most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials, until you deny them. So the first rule for adopting srt is that the denyRead list matters as much as allowWrite and allowedDomains: ~/.ssh, ~/.aws, **/.env, and cloud credential directories belong in the configuration from day one. Treating the default configuration as a secure configuration is the easiest mistake to make with srt.

The companion rule is to manage the configuration file like code. Commit srt-settings.json to version control, review changes to it, and keep a history. Do not put real secrets in it — its job is to draw boundaries, not to store credentials. The README also documents mandatory deny paths (.bashrc, .zshrc, .gitconfig, .mcp.json, .git/hooks, and others) that cannot be written regardless of allowWrite. That stops an agent from editing your shell startup files or git hooks to persist itself, a sensible floor for the case where you misconfigure everything else. It is a floor, not a substitute for your own deny list.

What the 84% figure actually means

The most quoted number in the coverage is that sandboxing cut Claude Code permission prompts by 84% in Anthropic's internal usage. That number comes from Anthropic itself. It is not an independent benchmark, and no controlled experiment behind it has been published, so it cannot be read as "84% safer." It measures prompt count, not interception success. What it really describes is approval fatigue. A developer who clicks "allow" hundreds of times a day eventually stops reading what they approve, and approval becomes theater. A fixed boundary changes the pattern to "work freely inside, ask only at the edge," so human attention is spent only on genuine boundary crossings. That logic is sound, but only if the boundary is drawn correctly. A wrong boundary with fewer prompts is more dangerous, not less. The 84% is a usability number, not a security guarantee, and it should always carry its attribution: Anthropic's internal, self-reported figure.

The real trade-off is the width of the allowlist

Coding agents do more than edit files. They install dependencies, fetch documentation, and call APIs. An allowlist that is too strict breaks npm install first, and the agent starts routing around it. One that is too loose protects nothing. srt provides several dials for that middle ground, and each is worth knowing: wildcards and ports; an ask callback that decides on uncovered hosts and can return a reason the model can read, pointing it at a sanctioned alternative; per-command allowlists that open a registry for a single invocation; --control-fd, which swaps the whole network configuration while a command runs (note: it replaces the whole config, it does not patch it, so a key left out of a line reverts to its default); and the resolved-address check described above. The practical combination is a base allowlist limited to package registries, code hosting, and APIs you actually call, with one-off needs handled by per-command grants or the ask callback — not by adding a top-level wildcard for convenience. The day a top-level wildcard appears in an allowlist is the day that sandbox stops meaning anything.

A rollout checklist for vibe projects

If you want to adopt srt in a vibe project now, this order is steadier than wrapping everything at once. First, cage the riskiest external piece: MCP servers whose code you have not reviewed. Swap the command to srt, denyRead ~/.ssh, ~/.aws, and **/.env, allowWrite only the project directory, allow network only to the domains that server genuinely needs, run it for a week, and widen only where the errors justify it. Second, cage the agent's own long sessions, prioritizing write and network restrictions over a perfect read list: first make sure it cannot damage the system or exfiltrate data, then tighten reads gradually. Third, commit srt-settings.json to the repository so the whole team runs the same boundary; a private, per-machine configuration is no configuration. Fourth, Windows teams should wait: the alpha backend plus its documented limitations (Schannel-based tools such as System32 curl, PowerShell's Invoke-WebRequest, .NET HttpClient, and winget do not work, and traffic carried by system services escapes the fence) argue against production paths for now. Fifth, run a jailbreak drill on a schedule: deliberately send the agent at denied paths, unlisted domains, and system directories, and confirm it is actually blocked. A sandbox that is never tested is a sandbox that is merely installed.

What it cannot solve for you

Three cold showers to close. First, srt is still a Beta Research Preview, and the README says its APIs and configuration formats may evolve. Binding a lot of automation to its configuration format today creates a migration bill later. Second, it prevents going out of bounds, not misbehaving inside them: an agent steered by an injected prompt that deletes data through an allowed write path, or calls a delete endpoint on an allowed API domain, will not be stopped, because both actions are inside what you permitted. Correctness inside the boundary still needs review, tests, and guardrails beyond this tool. Third, TLS termination is still experimental: terminating HTTPS at the proxy lets you inspect encrypted content, but it carries privacy and compliance questions to settle before enabling it. srt's value is not that it is a perfect cage. It is that it turns "what can this agent touch?" from a verbal promise into a version-controlled, testable, auditable configuration file. As agents get more capable, that file itself becomes part of the security work.

Three tiers of configuration: grade the cage to the server's risk

The skeleton configuration above is a starting point. The next step is not to use the same rules for every MCP server. Servers differ in risk, so the cage should differ in tightness, in three tiers. Tier one is read-only tooling: servers that only look up documentation or read repository files. Their network access can extend to the domains they genuinely query, but write access should be tightest — a single dedicated output directory, or no write access at all, since they do not need to write. Tier two is writable tooling: servers that edit files or run tests. Write access goes only to the current project directory, the full denyRead list applies, and network access is limited to package registries and code hosting. This is the most common tier in vibe projects and the easiest to loosen "for convenience." The rule here is that every loosening gets a written reason, in a configuration comment or a commit message, so that three months later you can still tell why it was loosened. Tier three is networked tooling: servers that call external APIs or cloud services. Their network allowlist should be registered domain by domain with a purpose attached, and denied-domain reasons should be configured so that when the agent is refused, it reads which sanctioned alternative to use instead of a bare rejection. This tier also needs violation-log collection switched on, because boundary crossings by networked tools are the hardest to reconstruct after the fact.

Grading has a side benefit: faster diagnosis. When a server starts failing, check its tier first, then check which rule in that tier changed most recently, and you will usually land on whether the problem is configuration or the server itself. With an ungraded configuration, a failure means reading the whole rule set from the top. Keep the tier assignments alongside the team's server inventory: when a new MCP server is connected, assign its tier, write its rules, and run the jailbreak test, in that order. A server connected by skipping the tier assignment and copying a generic configuration is usually the first one to cause trouble.

Caption: A real photograph of a data-center machine room, standing in for the infrastructure and isolation boundary behind agent execution — a generic machine-room photo, not a screenshot of srt itself.