Anthropic open-source srt: Claude Code's sandbox enforces its restrictions at the OS level, without containers, under Apache 2.0

Anthropic open-sources srt: Claude Code's sandbox imposes its restrictions at the OS level, without containers, under Apache 2.0

🔎 The security component Anthropic was keeping to itself has just changed hands

On October 24, 2026, Anthropic opened the vault. Sandbox-runtime (srt), the sandboxing engine developed for Claude Code, is now public under the Apache 2.0 license, installable via the npm @anthropic-ai/sandbox-runtime package. The announcement circulated the same day via AIWeekly, and the GitHub repository carries an unambiguous label: Beta Research Preview.

The timing is no coincidence. Code agents have a shell and network access. Without a perimeter, every permission prompt is a brake, and every "allow" clicked out of habit is a risk. While NVIDIA pushes enforcement at the kernel level and Google isolates each agent in a hardware microVM, Anthropic is choosing a third path: restricting filesystem, network, and UNIX sockets directly via OS primitives, without a single container.

My take is simple: with the npm distribution, a permissive license, and Claude Code's user base, Anthropic just played its ace on THE question that will matter for developers in 2027 — can the OS sandbox become the de facto standard for autonomous agents, in place of Docker?

The essentials

• Anthropic open-sourced sandbox-runtime (srt) on October 24, 2026 under Apache 2.0 (MarkTechPost analysis). It's a research preview, not a generally available product.
• srt restricts files, network, and UNIX sockets at the OS level: sandbox-exec on macOS, bubblewrap on Linux, with network filtering via a proxy. Zero containers.
• Any attempt at a restricted access returns EPERM and is logged, with real-time violation logs on macOS.
• Windows (alpha): a dedicated local account srt-sandbox, Windows Filtering Platform filters, a write-restricted token, and NTFS ACLs.
• Internally, Claude Code's sandboxed bash tool reduced permission prompts by 84% (Anthropic).
• Use case documented by Anthropic: sandboxing an MCP server as a drop-in.
• The race is already on: forkd (100 microVMs in ~200 ms), NVIDIA OpenShell, Google Agent Compute Engine.

Recommended tools

What Anthropic Actually Open Sourced (and Why It's Not Trivial)

Anthropic isn't publishing a demo: it's the complete runtime that runs in production in Claude Code, distributed as a Beta Research Preview. The repo's README states it was developed for Claude Code, but the Apache 2.0 license and the standalone npm package say otherwise: this code no longer belongs to a single product.

The most interesting point comes from MarkTechPost's analysis: srt is not tied to Claude Code. You can sandbox any process, agent, or MCP server with it. It's a generic building block, not a feature.

This isn't an isolated move either. The same month, Alphabet open-sourced its entire robotics stack under Apache 2.0 at ROSCon 2026. The strategy of the major labs is converging: give away the infrastructure layer to set the standard, rather than keeping it closed and losing distribution.

My take: the Apache 2.0 license is the real signal. It's not "look at our code", it's "plug in ours". The difference between the two is an ecosystem.

The mechanics: restricting files, network, and sockets without a single container

srt relies on what your OS already knows how to do. On macOS, it uses sandbox-exec, Apple's native confinement mechanism. On Linux, bubblewrap. In both cases, no image to build, no daemon to launch, no container to start.

The network follows a different logic: all traffic goes through a proxy that enforces the allowed hosts list and terminates TLS. UNIX sockets, often overlooked by homegrown sandboxes, are restricted as well. A sandboxed process can only reach what the allowlist explicitly permits.

And the behavior on violation is unambiguous: the system returns EPERM to the offending process and logs the incident. No silent failure, no silent exception — a traceable refusal.

Anthropic notes on its engineering blog that this runtime can sandbox processes, agents, and MCP servers "without the overhead of a container". That's the core of the proposition.

Why not Docker, exactly?

Docker isolates well, but it adds friction: images to maintain, volumes to mount, network to configure. For the dominant use case — one process, one policy, on the dev's machine — that's heavy artillery. srt bets on the opposite: a declarative policy, enforced by the kernel, instantaneous.

Windows (alpha): a srt-sandbox account, WFP filters, and NTFS ACLs

On Windows, srt takes a completely different approach, since there's no native equivalent to sandbox-exec or bubblewrap. The sandboxed process runs under a dedicated local account, srt-sandbox, created at installation time.

The implementation details, documented on the npm package and by Ry Walker, are worth a look:

• A random password, encrypted via DPAPI — nobody knows it, not even you.
• A Windows Filtering Platform filter keyed on the account's SID, which filters the network by process identity, not by port.
• A write-restricted token, supplemented with explicit ACEs on the working tree.
• All of it in a single elevated installation step, which is remarkably clean for Windows.

My take: Windows has historically been the poor cousin of dev tooling. Here, the engineering is real and the per-user account model is solid. But let's stay clear-eyed: it's an alpha. Don't build anything critical on it before it stabilizes.

-84% permission prompts: what secure-by-default changes

The number that will catch teams' attention: the sandboxed bash tool removes permission prompts, and Anthropic measures -84% of prompts internally (source). Concretely, your agent powered by Claude Sonnet 4.6 or Claude Opus 4.7 no longer interrupts the workflow for every command.

The philosophy is unapologetic secure-by-default: by default, you only grant the holes that are explicitly requested. Nothing is open out of the box. The allowlist precisely describes what the agent is allowed to touch — files, network hosts — and everything else is denied with logging.

Two mechanisms complete the setup. Credential masking, which prevents secrets from leaking into the agent's context. And real-time violation logs on macOS, which turn every EPERM denial into an actionable signal for tuning the policy.

Why this matters: permission fatigue is what kills real agent adoption. Every mechanical "allow" click is a security decision that is no longer one. Removing 84% of prompts while keeping a strict perimeter means attacking the real problem, not the symptom. Every coding agent — from Cursor to Cline, see our selection of the best AI tools for code — will have to answer this same question.

The underrated use case: sandboxing MCP servers

The documentation for the npm package cites a specific use case: sandboxing an MCP server. This may be the most important part of the announcement, and nobody is talking about it.

An MCP server typically holds API tokens, accesses the filesystem, and talks to the network. It's exactly the component that everyone plugs in without confining it — a third-party binary, often open source, with your credentials and a network attack surface. With srt, confinement becomes a drop-in: you launch the server under sandbox, you restrict its files and hosts, and you get logged EPERM errors at the slightest attempt to go outside the perimeter.

My prediction: by 2027, running an unsandboxed MCP server will be seen the way running an unknown binary as root is seen today. The building block now exists, free and under a permissive license. All that's missing are the conventions — and those get established quickly when a dominant player distributes the tool via npm.

forkd, OpenShell, Agent Compute Engine: the race to sandbox agents

srt doesn't arrive in a technological vacuum. It arrives in a race, and the competitors deserve to be named with their numbers.

forkd plays the microVM card: a sandbox runtime built on Firecracker, designed for agent fan-out, which forks 100 microVMs in about 200 ms and runs a live BRANCH at 56 ms p50, with KVM isolation per child, under Apache 2.0. We did the full analysis.

NVIDIA OpenShell moves up a level with an open runtime for fleets of autonomous agents: kernel-level enforcement (file access, system calls, network connections), formal verification of policy changes before they are applied, and credentials injected only toward approved endpoints. It supports Docker, Podman, Kubernetes, and MicroVM.

Google Agent Compute Engine plays the managed card: each agent gets its own hardware-isolated microVM, with zero durable credentials in the sandbox, all traffic passing through an isolated IPC boundary (virtio-vsock) and then an external proxy, and the orchestration harness living entirely outside the sandbox. Our deep dive is here.

And the open source ecosystem is pushing in the same direction. OpenCode, the open source coding agent with 8 million devs and 172K GitHub stars, like the self-hostable agents powered by Qwen3-Coder-Next, the 80B MoE with 3B active parameters that rivals Claude Sonnet locally via Ollama, will all need a sandbox. srt just provided one, for free.

My take: these projects aren't competing with each other, they're stacking layers. srt for the dev workstation, forkd and OpenShell for fleets, ACE for managed. But all of them converge on the same principle: never again an agent with raw access to the kernel, the network, and credentials.

Sandbox OS or containers: which standard for autonomous agents?

Direct answer: for the code agent on your machine, the OS sandbox is already winning. For the production fleet, microVMs remain king. Docker isn't disappearing — it's retreating on one specific segment.

Jensen Huang wants to lock AI agents into containers, like browsers. The analogy is appealing, but it backfires on him: the browser won with a process-level sandbox and site isolation, not with containers. srt is structurally closer to that model than to Docker — and that's precisely what makes it viable for the workstation.

So, de facto standard? I think yes, for a mundane reason: distribution wins standards. npm install -g, Apache 2.0 license, Claude Code user base — srt is the option devs will try first, and the one you try first becomes the one you keep.

One important caveat, raised by MarkTechPost: the breadth of the allowlist is the real security variable. An allowlist that's too broad can leak data. The de facto standard is only worth as much as the policies you write on top of it.

Getting started with srt: one npm line and an allowlist to size

Installation comes down to a single command:

npm install -g @anthropic-ai/sandbox-runtime

Then, three tips that come directly from reading the source code.

Start with a minimal allowlist, then widen it only when an EPERM shows up. On macOS, violation logs are available in real time: every denial tells you exactly what the agent needs. It's a feedback loop, not a wall.

Treat the logs as a spec. Every logged violation is a decision to make explicitly: allow it, or confirm the denial. Within a week, you have a policy that reflects your agent's actual behavior, not a guess.

Keep the research preview in its place. For a dev workstation, srt is already useful. For a production fleet with sensitive data, look toward microVMs — forkd or ACE — while waiting for the beta release.

❌ Common Mistakes

Mistake 1: confusing research preview with production scope

The GitHub repository is explicit: Beta Research Preview. Treating srt as a definitive production barrier, without an additional layer, means taking an unnecessary risk. The solution: layer up. srt on the front line for daily use, microVM or container for sensitive workloads, and a regular review of the policies.

Mistake 2: copying an overly broad allowlist

MarkTechPost says it bluntly: an overly broad allowlist can leak data. Copying another project's config is the most dangerous shortcut. The solution: start empty, expand based on observed EPERMs, and review with every new MCP server integrated.

Mistake 3: sandboxing the process but leaving credentials within reach

srt's credential masking is no substitute for hygiene. Compare with the state of the art: OpenShell only injects credentials toward approved endpoints, and Google ACE maintains zero durable credentials inside the sandbox. The solution: short-lived secrets, injected on demand, never persisted within the perimeter.

Mistake 4: ignoring violation logs

Logged EPERMs are not noise, they are free tuning data. Ignoring them means leaving an approximate policy in place. The solution: a weekly log review during the first few weeks, then at every major change to the agent or its tools.

❓ Frequently Asked Questions

Does srt work without Claude Code?

Yes. According to MarkTechPost, srt is not tied to Claude Code: it's a generic runtime that sandboxes any process, agent, or MCP server. The npm package installs independently, and the Apache 2.0 license allows integration into your own tools, both commercially and internally.

Which platforms are supported?

macOS via sandbox-exec and Linux via bubblewrap form the stable base, with network filtering through a proxy. Windows is in alpha: a dedicated local account srt-sandbox, Windows Filtering Platform filters indexed by SID, a write-restricted token, and NTFS ACLs, all installed in a single elevated step.

Is a sandbox without a container really isolated?

It relies on native kernel primitives — sandbox-exec, bubblewrap, WFP — with EPERM denials and logging. For a dev workstation, that's a solid level. For multi-tenant hardware isolation, microVMs like forkd or Agent Compute Engine remain the right answer.

Can you sandbox an MCP server with srt?

Yes, that's the use case documented in the npm package. The server runs under the sandbox with its files and network hosts restricted, UNIX sockets included. Attempts outside the perimeter return EPERM and are logged, which lets you adjust the allowlist progressively.

Does srt replace Docker for agents?

No, it's a complement. Docker and Kubernetes remain relevant for reproducible environments and deployment. srt addresses the "one process, one policy" case on the developer's machine, without container overhead. Fleets requiring strong isolation will go through Firecracker microVMs.

How much does srt cost?

Free and open source under Apache 2.0, like forkd and OpenShell. The real cost lies elsewhere: sizing the allowlists correctly, monitoring violation logs, and maintaining the policies over time. Agent security becomes an ongoing engineering effort, not a purchase.

✅ Conclusion

By open-sourcing srt under Apache 2.0, Anthropic isn't giving the community a gift: it's installing its standard, one npm line at a time, in the sandboxing race that already pits forkd, OpenShell, and Agent Compute Engine against each other. Test it on an MCP server this week, and follow the evolution of the ecosystem in our AI news — the question is no longer whether agents will be sandboxed, but by what.