Sandboxing is the practice of running an AI coding agent in an isolated environment — a container, a virtual machine, a separate branch, or a disposable workspace — where it can read files, write code, and run commands without affecting real production systems. If the agent makes a mistake, such as deleting a directory, corrupting a config file, or installing a bad dependency, the damage is contained to the sandbox and the real codebase stays untouched.
Usage
Concrete forms of sandboxing include: git worktrees (an isolated copy of the repository for the agent to work in, merged if the result is good and deleted otherwise), containers (running the agent inside Docker with limited network access and filesystem isolation), cloud sandbox services such as GitHub Codespaces or Gitpod providing ephemeral dev environments, branch-based isolation where the agent works on a separate branch and CI verifies the changes before human review, network restrictions preventing the agent from making external API calls or accessing production services, and permission scoping (read-only access for most directories, write access only to specific paths) as a lighter-weight form of isolation even without full sandboxing.
Designing agentic loops sets out a middle option between isolating the agent locally and simply accepting the risk: running it on someone else’s computer, so that a rogue agent’s blast radius is bounded by not being your machine. That post’s author names it as his own favourite, gives GitHub Codespaces as his instance of it, and bounds the worst case as code checked out into the environment being exfiltrated or bad code being pushed to the attached repository — with the CPU being burned belonging to someone else. It reports hosted code-interpreter modes as able to go a surprisingly long way in the same role, and reports the author having had a lot of success using OpenAI’s Codex Cloud that way.
2026年のAI Coding Agent活用 ── スピードと安全性を両立させる compares three of these forms against each other on four axes — the effort to set up, how stable it is, whether the developer keeps their choice of editor, and how easily outside tooling integrates. Development containers come out well on stability and editor choice at moderate effort: that post notes that the agent vendor’s own repository ships a sample container configuration carrying iptables-based network restriction, and that container development is not tied to one editor, since a separate CLI and a third-party tool both drive the same configuration from elsewhere. What it costs is the conveniences of working on the host — retrieving secrets from a password manager, hook-driven notifications, and sharing a user-level agent configuration all become harder.
An agent’s own built-in sandbox needs the least setup of the three, tied with a cloud IDE and below a container: it is turned on from the agent’s settings file rather than by writing a container definition. It is implemented with bubblewrap on Linux and Seatbelt on macOS. That post reports it as the least mature of the three and correspondingly hard to diagnose when something inside it fails; it recommends turning off the setting that still permits unsandboxed commands, while acknowledging that doing so leaves less room to work around an error the sandbox itself causes. A cloud IDE is the third option: low effort and isolated, but it settles which editor is used.
The same post supplies an argument for pairing a sandbox with a more permissive approval setting rather than treating the two as alternatives. It recommends the setting that auto-allows shell commands because they are sandboxed, on the grounds that this improves the experience while keeping the safety property, and relays a substantial reduction in permission prompts from the vendor’s own engineering write-up rather than measuring it. That fewer prompts is itself a safety property, and not merely a convenience, is argued in a different section of that post — the one on permission settings — and is set out here under Approval Fatigue.
A vendor’s built-in sandbox, as documented
Anthropic’s documentation for Claude Code’s sandboxed Bash tool describes one
built-in sandbox in detail. Instead of approving each command, the user defines which files and network
domains commands may touch, and the operating system enforces that boundary for every Bash, PowerShell
or Monitor command and their child processes — Seatbelt on macOS, and bubblewrap on Linux and WSL2, with
socat relaying network traffic to the sandbox proxy; native Windows and WSL1 are not supported. The
documentation splits the sandbox into two independent layers. Filesystem isolation by default allows
writes only to the working directory, directories the user has added, and a session temp directory,
while allowing reads across the whole computer except certain denied directories — a default it
explicitly notes still leaves credential files such as ~/.aws/credentials and ~/.ssh/ readable
unless they are listed for protection. Network isolation runs through a proxy outside the sandbox that
pre-allows no domains and asks the first time a command needs a new one.
Two design choices in that account bear on the general practice. First, the sandbox is presented as a separate layer from permission rules rather than a variant of them: permission rules are evaluated before a tool runs, based on the command string, whereas the sandbox is enforced by the operating system on the running process, so the documentation says it holds regardless of what the model chose to run and even if an allowed command does more than its name suggests. Second, it pairs the sandbox with an optional auto-allow mode that runs sandboxed commands without prompting, and with an escape hatch — a command that fails under the sandbox may be retried outside it through the regular permission flow — which can be switched off so that every command must run sandboxed. For credentials it offers, besides blocking a file or unsetting a variable, a masking mode in which sandboxed commands see a placeholder and the proxy substitutes the real value only on outbound requests to hosts the user allows.
The same documentation is explicit that this is not a complete isolation boundary. By default the
proxy decides from the client-supplied hostname without terminating or inspecting TLS, so allowing a
broad domain such as github.com can open a path for data exfiltration, including through techniques
such as domain fronting; allowing a Unix socket such as the Docker socket can hand the sandboxed process
access to the host; and a weaker mode for running inside unprivileged containers is described as
considerably weakening security. Its closing claim is that effective sandboxing requires both layers:
without network isolation a compromised agent could exfiltrate sensitive files such as SSH keys, and
without filesystem isolation it could backdoor system resources to gain network access.
When It Applies
Sandboxing matters more as an agent is given more autonomy: agents can misinterpret instructions, hallucinate solutions, or execute commands with unintended side effects, and without isolation every action carries real risk, so each command needs review and approval before it runs. With sandboxing in place, an agent can experiment freely and only the final result needs review, which is described as dramatically speeding up workflows. It is presented as a general best practice for autonomous agents rather than one party’s specific proposal, summarized as treating agent output like an untrusted pull request: let it work in isolation, review the result, and merge only after verification.
Where the account above treats network restriction as one isolation technique among several, Claude Code for web—a new asynchronous coding agent from Anthropic singles it out as the hard part and the one that carries the security argument. Reporting on Anthropic’s sandboxing work, it describes filesystem isolation as relatively easy and network isolation as the difficult problem, and quotes Anthropic’s approach: internet access permitted only through a unix domain socket connected to a proxy server running outside the sandbox, which enforces which domains a process may reach and handles user confirmation for newly requested ones. The post’s stated reason this matters is Lethal Trifecta — the best defence against those attacks is to cut off one of the three legs, and restricting outbound network access is how the exfiltration leg is removed. It also notes the limit of a partial cut: an allow-list running to dozens of dependency-installation domains left the author uneasy about exfiltration paths surviving inside it, whereas a no-network mode leaves nothing to worry about on that axis.
That post also supplies the argument for why sandboxing is worth the effort rather than simply approving each action: it reads Anthropic’s investment as an acknowledgement that agents run without step-by-step permission prompts are far more productive than agents that require them, which makes convenient safe execution — not tighter approval — the problem to solve. The author describes this approach as the only one that feels credible to him.
How reliably any of this is achieved in practice is treated more sceptically in
Designing agentic loops. That post reports that coding agents implement their own
levels of sandboxing but that its author has not seen documentation of them convincing enough to
trust — his own assessment rather than a tested finding — and treats Docker or Apple’s container tool
as a reasonable risk to accept for most people while noting that container escapes exist. Its blunter
observation is about uptake rather than technique: offered a sandbox, someone else’s machine, or
simply taking the risk, most people are said to choose the third. The same post quotes Anthropic’s
Claude Code documentation recommending that --dangerously-skip-permissions be used in a container
without internet access, and endorses restricting an agent to a list of trusted hosts as a way to
stop exfiltration of private source code.
Related Terms
Guardrails, Human-in-the-loop, DefinedTerm/tool-use, Agentic Engineering, Lethal Trifecta, Claude Code for web, YOLO Mode, Permission Modes