Canonical: https://botbento.com/blog/anthropic-sandbox-runtime-for-bot-shell-tools/ Format: Markdown representation of the public HTML page. [Home](/) / [Blog](/blog/) FIELD NOTES / 4 MIN READ # Anthropic Open-Sourced Its Sandbox. Should Your Bot's Shell Tool Use It? Anthropic's sandbox-runtime, the OS-level isolation layer behind Claude Code's /sandbox command, now ships as a standalone open-source package that any bot's shell or code tool can wrap. This piece sets out when to install it locally versus when to reach for Anthropic's hosted code execution tool instead, and where the boundary it draws still has gaps. By BotBento Editorial · Published 2026-10-24 · Updated 2026-10-24 AI-assisted editorial: researched and drafted with AI using the primary sources linked below. Examples are illustrative; they are not measured product results. [Editorial policy](/editorial/). ## In this article - [The decision in one paragraph](#the-decision) - [What srt actually restricts](#what-srt-is) - [Worked example: a research bot with a shell tool (illustrative)](#worked-example) - [When to use the hosted code execution tool instead](#hosted-alternative) - [Where the boundary doesn't cover you](#where-it-breaks) - [A checklist before you wire either one in](#checklist)[Read as Markdown ](/text/blog/anthropic-sandbox-runtime-for-bot-shell-tools/index.md) ## Key takeaways - If your bot runs shell commands or generated code on a machine you control, wrap the tool call in sandbox-runtime (srt) rather than trusting the model's own restraint. - If your bot calls Claude through the API and doesn't manage its own host, use Anthropic's hosted code\_execution tool instead — it's already sandboxed server-side and needs no install. - Treat srt as a beta research preview: pin a version, and don't assume an allowed network domain is a safe domain — it only stops traffic to domains you didn't list. ## The decision in one paragraph If your bot has a shell tool or a code-execution tool and it runs on infrastructure you operate, put an OS-level sandbox between the tool call and your filesystem. Anthropic's own sandbox, sandbox-runtime (srt), is now a standalone open-source package you can install and wrap around any command, not just Claude Code sessions. If instead your bot talks to Claude over the API and you don't want to operate sandboxing infrastructure yourself, Anthropic's hosted code execution tool already runs inside a managed, sandboxed container on Anthropic's side — you don't install anything. The two options solve the same problem — stopping a tool call from reading or writing outside its lane — but they sit in different places. srt is something you run. The hosted code execution tool is something you call. Sources: [sandbox-runtime: OS-level filesystem and network restrictions](https://github.com/anthropics/sandbox-runtime), [Code execution tool - Claude Platform Docs](https://platform.claude.com/docs/en/agents-and-tools/tool-use/code-execution-tool). ## What srt actually restricts The standalone runtime provides the operating-system boundary used by Claude Code's Bash sandbox. An application embedding it must still supply its own filesystem and network policy. Claude Code's permission modes, prompts and credential settings are application behavior; installing the runtime does not automatically copy that whole setup into another bot. Install the standalone npm package before invoking srt. On macOS its isolation mechanism uses the operating system's Seatbelt facility. Linux and WSL2 deployments also need bubblewrap and socat. Check these prerequisites on the actual worker, rather than assuming that a successful package install proves the boundary is active. Review reads, writes and network access separately. The runtime's default read policy is broad, so deny access to sensitive files explicitly; configure the directories that commands may write and the domains they may contact. Supply a minimal environment too: a filesystem restriction cannot remove a secret that the parent process already passed to its child. Sources: [Configure the sandboxed Bash tool - Claude Code Docs](https://code.claude.com/docs/en/sandboxing), [sandbox-runtime: OS-level filesystem and network restrictions](https://github.com/anthropics/sandbox-runtime). ## Worked example: a research bot with a shell tool (illustrative) Say a small team builds a research bot that can run shell commands to fetch pages, extract text, and run light data cleanup scripts. Before srt, every command ran with the same filesystem and network access as the account hosting the bot — a bug in a generated script could write anywhere the process could write. In this illustrative setup, the team installs the runtime, grants writes only to a disposable project directory and permits only the research endpoints it needs. It excludes credential files and strips unrelated secrets from the command environment. The Linux worker also receives bubblewrap and socat. These are proposed controls for the example, not a claim that this team or BotBento tested them. A useful negative check would deliberately attempt to write a harmless test file outside the permitted directory. The expected result is a denied write; the operator should inspect that result on the worker before relying on the policy. If it succeeds, the boundary needs repair. No measured test result is being claimed here. Sources: [sandbox-runtime: OS-level filesystem and network restrictions](https://github.com/anthropics/sandbox-runtime). ## When to use the hosted code execution tool instead If your bot calls Claude through the API and you do not want to operate a code runner, the hosted code execution tool is an alternative. Anthropic runs the workspace and container; your application submits the tool-enabled request and handles its results. The hosted container has no outbound internet access and cannot install extra packages at runtime. That differs from a local runtime configured to reach selected domains. A research workflow that needs fresh pages must fetch them through an appropriate separate tool and pass the needed data to code execution, rather than assuming that code inside the container can open the URL. The current documentation lists three tool versions. code\_execution\_20250825 provides shell and file operations; code\_execution\_20260120 adds persistent Python interpreter state and programmatic tool calling. code\_execution\_20260521 uses that same runtime and documents the per-cell time limit in its tool description. Check support for the model you use and select the version your integration actually requires; do not infer compatibility from the date alone. Sources: [Code execution tool - Claude Platform Docs](https://platform.claude.com/docs/en/agents-and-tools/tool-use/code-execution-tool). ## Where the boundary doesn't cover you Two gaps are worth naming before you treat either option as a finished security control. First, a network allow-list is permissive, not precise. If your bot's sandbox permits a domain because it needs read access there, a compromised or misguided script can usually still use write access on that same domain — an allow-listed code host, for instance, doesn't distinguish between pulling a file and pushing one. The sandbox restricts where traffic can go; it has no opinion on what the traffic does once it's allowed through. Second, both tools are still moving targets. srt is distributed as a package whose maintainers describe it as evolving, and Claude's code execution tool has shipped multiple dated versions within the same year. Pin the version your bot depends on, and re-check behavior before upgrading — don't assume this month's sandbox config still matches next month's release notes. Sources: [Configure the sandboxed Bash tool - Claude Code Docs](https://code.claude.com/docs/en/sandboxing), [sandbox-runtime: OS-level filesystem and network restrictions](https://github.com/anthropics/sandbox-runtime). ## A checklist before you wire either one in Use this to decide which path fits your bot, and what to verify before you trust it. - Bot runs on a host you operate (laptop, VM, CI runner) → install srt and wrap the shell/code tool call; confirm the platform dependency (Seatbelt on macOS, bubblewrap and socat on Linux/WSL2) is actually installed, not just assumed. - Bot calls Claude purely over the API with no host to patch → use the hosted code execution tool and pick the tool version your routine actually needs (state persistence or not). - Either way, write down the filesystem write paths and network domains the tool is allowed to touch, and review that list separately from reviewing the bot's prompt — the sandbox enforces the list you give it, it does not generate a safe one. - Re-test after any srt or tool-version upgrade; don't carry last quarter's assumptions about default network access into a new release without rereading the current docs. Sources: [sandbox-runtime: OS-level filesystem and network restrictions](https://github.com/anthropics/sandbox-runtime), [Code execution tool - Claude Platform Docs](https://platform.claude.com/docs/en/agents-and-tools/tool-use/code-execution-tool). ## Primary sources Sources checked 2026-10-24. Standards and product documentation can change; follow the linked version when implementing. - [Configure the sandboxed Bash tool - Claude Code Docs](https://code.claude.com/docs/en/sandboxing) — Anthropic - [Code execution tool - Claude Platform Docs](https://platform.claude.com/docs/en/agents-and-tools/tool-use/code-execution-tool) — Anthropic - [sandbox-runtime: OS-level filesystem and network restrictions](https://github.com/anthropics/sandbox-runtime) — Anthropic BotBento is in development. [Suggest a correction](/contact/).