Designing Agent Sandboxes for Maximum Capability

# Designing Sandboxes That Unlock an Agent's Full Potential

Hi, I'm Norikazu Muramoto. (https://x.com/1amageek)

In August 2026, Anthropic made auto mode the default in Claude Code for Pro, Max, and Team plans. Its announcement described an experiment involving 1,053 paid testers recruited through a research firm. In a test environment, participants were shown a sequence of permission prompts, with one prompt replaced by an obviously dangerous command. Only 143 of the 1,053 testers, or 13.6%, noticed the dangerous command. Auto mode blocked the same commands in 89% of cases: 937 out of 1,053.

One-by-one approvals were barely functioning as a safety mechanism. In May 2026, Anthropic explained how it contains Claude across its products:

> Rather than supervising what the agent does, we supervise what it’s able to do by enforcing access boundaries through, for example, sandboxes, virtual machines, and egress controls.

If responsibility for safety moves from human approval to the environment, then designing that environment also determines what an agent can accomplish.

This article looks at sandbox environments for agents. A sandbox is often discussed as a safety mechanism, but for an agent it is the computer where work happens. Which commands are available? Can it access the network? Install packages? Continue its work the next day? These environmental choices determine how much capability we can draw from the same model. Restricting dangerous commands matters. But removing harmless commands weakens the agent, while systems that judge danger by command names continue to fail at security too.

Information in this article is current as of September 2026.

## 1. The Model Alone Does Not Determine Capability

An agent does not run on a model alone. An agent loop drives the model's outputs. A harness supplies tools and context to that loop. An environment receives the tool executions. Beyond it lies the external world.

Model — decides the next action ↓ Agent loop — reason → act → read the result ↓ Harness — tools, context, approvals ↓ Environment / sandbox — where commands actually run ↓ External world — Git, packages, APIs, production systems

Even with the same model, changing these layers changes the outcome. Terminal-Bench 2.0, a benchmark for terminal tasks, reported different scores for the same Claude Opus 4.5 across harnesses:

Terminus 2 — Model: Claude Opus 4.5; Terminal-Bench 2.0: 57.8%.

Claude Code — Model: Claude Opus 4.5; Terminal-Bench 2.0: 52.1%.

OpenHands — Model: Claude Opus 4.5; Terminal-Bench 2.0: 51.9%.

The paper nevertheless notes that model choice usually matters more than harness choice for improving performance.

What about the environment? In January 2026, researchers at Renmin University of China and Microsoft Research compared the same models answering directly and answering inside a sandbox. The sandbox was a Docker container with bash, file-editing tools, internet access, and the ability to install packages during execution. With bash, a model can install packages, run programs, and build the tools it needs on the spot.

The results moved in opposite directions depending on the model.

GPT-5 — Task: Mathematics; Model alone: 87.8; With sandbox: 97.9.

Claude Sonnet 4.5 (Thinking) — Task: Instruction following; Model alone: 59.3; With sandbox: 72.0.

GPT-5 — Task: Biomedicine; Model alone: 55.8; With sandbox: 49.0.

Qwen3-4B — Task: Mathematics; Model alone: 46.0; With sandbox: 32.5.

Stronger models benefited directly from the environment, while the weaker model performed worse inside the sandbox. Even a strong model lost ground on a task such as biomedicine, where the environment was less useful. An environment helps only when the model and task can make use of it.

Effective Capability = f(Model, Harness, Environment)

This is my interpretation, not a measured function. The expression is a way to show that capability emerges from the interaction of all three. As models become stronger, they can draw more from their environment, so the cost of a cramped environment also grows.

After choosing the model, design the environment. Measure the effect of expanding it for the particular model and task you will use.

## 2. A Sandbox Is the Agent's Computer

In September 2025, Anthropic released the machinery behind Claude Code as the Claude Agent SDK and described its central principle:

> The key design principle behind the Claude Agent SDK is to give your agents a computer, allowing them to work like humans do.

OpenAI's ChatGPT agent also works on its own virtual computer, moving between reasoning and action. Manus uses the filesystem as context that is unbounded in size, persistent, and directly accessible to the agent. Research findings and intermediate work that do not fit in the context window can be written to files and read again later. The filesystem is both a workplace and an extension of the agent's memory.

Take the shell, network access, and package installation away from a human engineer, and that same person can do much less. The same applies to agents. Here is what each part of the computer provides, and what is lost when it is removed.

OS — Role for the agent: Foundation for running commands and programs; What is lost without it: Execution itself.

Filesystem — Role for the agent: Storage for code, artifacts, and notes; What is lost without it: Intermediate progress and memory beyond the context window.

Shell — Role for the agent: General execution mechanism for combining local programs; What is lost without it: The ability to handle unanticipated work.

Runtime / Packages — Role for the agent: Language runtimes, build tools, and test tools; What is lost without it: Verification through builds and tests.

Network — Role for the agent: Fetch dependencies, read documentation, call APIs; What is lost without it: Resolving dependencies discovered during work.

Processes — Role for the agent: Keep a DB or server running while checking behavior; What is lost without it: Verification of components working together.

Credentials — Role for the agent: Authority to operate external services; What is lost without it: Changes to external services.

Persistent state — Role for the agent: Resume work the next day; What is lost without it: Accumulated setup and progress.

I have experienced this myself while building a Docker sandbox. I forgot to include commands such as python in the image. The agent could not run Python and struggled to proceed with verification. I had not removed it because it was dangerous; I had simply forgotten it. Even that omission took away the agent's means of verification, exactly as the Runtime row describes.

Designing the sandbox means designing the agent's capabilities. Before deciding what to prohibit, decide which of these components to provide.

## 3. What Does an Agent Lose When We Remove Commands?

First, a limitation of the evidence: in the research I reviewed, I did not find an experiment that removed available commands one at a time and measured the resulting drop in success rate. Nor did I find comparisons that changed only network access or package installation. What we have are ablation studies under related conditions.

The 2024 SWE-agent paper compared an agent-computer interface (ACI), a command set designed for agents, with a shell-only configuration using the same GPT-4 Turbo. On SWE-bench Lite, the resolution rate was 18.0% with the ACI and 11.0% with the shell alone: a 64% relative improvement over the shell-only setup. The paper also removed ACI components individually. Removing editing commands reduced the score to 10.3%; removing search tools reduced it to 15.7%. Without editing commands, the model had to modify files through redirection or sed. The paper concludes that difficult interfaces impair model performance.

With frontier models in 2026, the picture has changed. The minimal, bash-only mini-SWE-agent solved 76.8% of SWE-bench Verified with Claude Opus 4.5. The official SWE-bench site lists state-of-the-art results from agents given only a bash shell and the problem.

In July 2026, researchers at Rochester Institute of Technology compared three tool configurations for Claude Code with Claude Sonnet 4.6 and Codex CLI with GPT-5.5:

- Default tools.

- Bash only, with file-editing tools disabled.

- A single execution tool for Python and Bash.

Across four regimes and three configurations, success rates differed by less than three percentage points in every combination. The difference appeared in cost. For artifact-creation tasks, using a single execution tool with Claude Code reduced cache-adjusted cost by 24.6%.

Verdent's November 2025 technical report also describes a tool ablation with Claude Sonnet 4.5. Restricting the agent to basic bash, read, write, and edit tools barely changed its SWE-bench Verified performance.

There is a production example too. In December 2025, Vercel replaced 17 specialized tools in d0, its internal agent for converting natural-language questions into SQL for its analytics platform, with a tool for running bash in a sandbox and another for executing SQL. In five questions tested with Claude Opus 4.5, success rose from four out of five to five out of five, while time fell from 274.8 to 77.4 seconds. This was a small internal test, and it depended on an already well-documented semantic layer for the analytics platform. Files in the environment took over the knowledge previously embedded in specialized tools.

Here are the experiments organized by what was removed:

Execution feedback — Retained: A single-shot answer; Result: GPT-4 SQL: 73.7% → 9.1%; Source: InterCode.

Computer environment — Retained: Model alone; Result: GPT-5 mathematics: 97.9 → 87.8; Source: LLM-in-Sandbox.

Editing commands — Retained: Shell and remaining ACI; Result: GPT-4 Turbo: 18.0% → 10.3%; Source: SWE-agent.

File-editing tools — Retained: Bash or one execution tool; Result: Less than 3 percentage points difference; Source: Yang, Yu, Desell.

Advanced tools — Retained: Bash, read, write, edit; Result: Almost unchanged; Source: Verdent.

17 specialized tools — Retained: Bash and SQL execution; Result: 4 out of 5 → 5 out of 5; Source: Vercel.

The largest losses come from removing the means to execute and to inspect results. With a shell remaining as a general execution mechanism, reducing specialized tools barely changes frontier-model performance.

My interpretation is that the 2024 and 2026 results do not contradict each other. In the GPT-4 Turbo era, easy-to-use commands compensated for model limitations. Today's models can reconstruct specialized tools' roles if they have bash. Across both eras, losing editing, execution, and feedback causes substantial deterioration. What matters is not the number of tools, but what the general execution mechanism can reach.

If you reduce tools, start with specialized ones. Keep the shell, file editing, and access to execution results.

The cost of restricting tools for security has also been measured. AgentDojo, an evaluation environment for prompt injection attacks, tested a tool filter that preselected only the tools needed for a task. With GPT-4o, utility without attacks rose from 69.0% to 73.13%, while attack success fell from 57.69% to 6.84%. Viewed alone, that suggests tighter restrictions are better. The paper also identifies when the defense fails:

> This defense fails, however, when the list of tools to use cannot be planned in advance (e.g., because the result of one tool call informs the agent on what tasks it has to do next), or when the tools required to solve the task are also sufficient to carry out the attack (this is true for 17% of our test cases).

Progent, from researchers at UC Berkeley and UC Santa Barbara, quantified the first limitation. In a remeasurement using GPT-4o on AgentDojo, utility was 79.38% without a defense and 65.98% with static tool filtering. Progent, which can expand privileges as needed during execution, achieved 76.29%. On Slack tasks, enabling privilege updates raised utility without attacks from 61.9% to 90.5%. Some required tool calls could not be inferred from the user's request alone.

The cost of static restrictions depends on whether future needs can be predicted. The longer an agent works autonomously, the more it discovers its next requirements during execution. Use preselected tool filtering for tasks whose required tools can be determined from the initial request. For long-running agents, use a mechanism that can expand privileges during execution, or the boundary-based design discussed in Section 6.

Could we simply prohibit dangerous commands? Before sandboxing, Claude Code automatically allowed commands considered safe, such as echo and cat, and required approval for most other operations. But a command's name does not match the magnitude of its risk.

The first line looks dangerous, but it only deletes build artifacts in the working directory, which can be regenerated. The second looks harmless, but depending on the contents of scripts/analyze.py, it could read keys from the home directory and send them outside.

Danger depends on what a command can reach, not what it is called.

GTFOBins documents ways to launch a shell through commands that appear harmless. These can all run as an ordinary, unprivileged user.

npm install also executes package lifecycle scripts such as preinstall and postinstall. A command intended merely to install a dependency can run arbitrary code.

Anthropic acknowledged this issue in its March 2026 explanation of auto mode. When entering auto mode, it removes permission rules known to allow arbitrary code execution:

- Blanket shell permissions.

- Wildcard permissions for interpreters such as python, node, and ruby.

- Permissions for package managers' run commands.

It also acknowledges that this exclusion list is incomplete and derived from observed usage.

Such rules are widespread among users. As of June 2026, 49.5% of active CLI users had created custom Bash permission rules. Five percent allowed all shell commands, while another 43% had interpreter rules such as Bash(python:*) or Bash(node:*), which amount to essentially the same thing.

My interpretation is that many users trying to reduce approvals believe they have allowed a command by name, while actually opening up the entire shell. Users themselves undo the name-based restriction system.

Command-list defenses have repeatedly been bypassed in practice:

Cursor — Disclosure: July 2025, Backslash Security; How it was bypassed: Four ways around the auto-run denylist; the denylist was removed in version 1.3.

Cursor — Disclosure: CVE-2025-54131; How it was bypassed: Embedding another command in an allowed command through backticks or $(cmd).

Claude Code — Disclosure: CVE-2025-54795 and CVE-2026-24887; How it was bypassed: Parsing errors in echo and find allowed arbitrary commands without approval.

Claude Code — Disclosure: CVE-2025-64755; How it was bypassed: sed, treated as read-only, could write arbitrary files.

Gemini CLI — Disclosure: July 2025, Tracebit; How it was bypassed: A command disguised as permitted grep exfiltrated environment variables.

GitHub Copilot — Disclosure: CVE-2025-53773; How it was bypassed: The agent modified .vscode/settings.json to disable approvals.

Backslash Security expressed the limitation as a theorem:

> Theorem: For every command in a Cursor denylist, there are infinite commands not present in the denylist which, when executed, have the same behavior.

Anthropic's choice for auto mode was also to evaluate an operation's actual effects rather than its invocation string.

Command lists lose on two fronts. For security, they cannot stop alternative spellings of the same behavior. For capability, they block harmless work merely because a name resembles a dangerous one. Rather than relying on command allowlists or denylists as the safety mechanism, constrain what the agent can reach through the environment.

## 4. Approvals Stop Long-Running Agents

Operations that command lists could not classify have traditionally been sent to a human for approval. Claude Code previously asked users for permission on each turn to prevent unintended actions.

Agent proposes command → Approval prompt → Approve: execute / Reject: stop and retry → Next command.

As prompts accumulate, approval fatigue feeds back into this loop: users click without reading.

In March and May 2026, Anthropic reported that users approved roughly 93% of permission prompts. Its August announcement put the figure at 97% and noted that human review can become habitual. The May article explains that as people see more approvals, they devote less attention to each one, and supervision deteriorates over time.

In the experiment described at the beginning, human performance fell as sessions grew longer. Participants caught around 17% of dangerous commands early in a session, but only around 5% after seeing more than 50 prompts. Auto mode's blocking rate remained constant regardless of session length. The May article also argues that non-engineers should not be expected to read and judge bash commands.

The burden increases the longer an agent works. Continuous agent work is already discussed in hours:

METR, Claude Opus 4.6 — Figure: About 12 hours; What it measures: Completing tasks that take human experts around 12 hours, with 50% probability; not elapsed agent runtime.

GPT-5-Codex — Figure: More than 7 hours; What it measures: Continued independent work on large, complex tasks during testing.

Claude Sonnet 4.5 — Figure: More than 30 hours; What it measures: Maintained focus on complex, multistep tasks.

My interpretation is that requesting approval every few minutes during work of this length makes the human the speed limit. And, as the opening experiment shows, that human misses more dangerous commands as the session continues. Approval does not reliably preserve safety and also obstructs autonomy.

Classifiers such as auto mode mitigate this problem. But Anthropic reports that Claude Code auto mode stops roughly 83% of overreaching actions before execution while allowing roughly 17% through. It positions the classifier as one layer of defense inside a sandbox, not a replacement for the sandbox.

Use approval for operations that cross the boundary. Operations inside should proceed without approval; if a classifier is used, it remains one layer within the sandbox.

## 5. What Is a Fully Autonomous Agent?

Let me define the agent this article aims to support.

Here, a Fully Autonomous Agent means an agent that can work autonomously toward a given objective for an extended period without step-by-step human operation or approval.

That does not give it permission to do anything. Instead of approving individual actions, humans define the objective and boundaries. The agent works without interruption inside those boundaries, while operations crossing them receive separate treatment.

In October 2025, Meta proposed the Agents Rule of Two as a framework for deciding where to draw the boundary. The idea is to allow at most two of these three properties in one session:

A — Meaning: Process untrusted inputs.

B — Meaning: Access sensitive systems or private data.

C — Meaning: Change state or communicate externally.

Meta's position is that if all three are necessary and the agent cannot restart in a new session with a fresh context window, it must not operate autonomously. At minimum, it needs supervision through reliable verification, such as human approval.

Coding agents cannot avoid A and C. Web pages, issues, and dependency READMEs are untrusted input; changing files and running tests modify state.

My interpretation is that extended autonomy requires removing B through the environment. If the agent works somewhere that cannot reach sensitive data or production systems, it can retain A and C while operating autonomously.

Simon Willison questioned Meta's diagram treating A plus C as safe. In a Hacker News reply, Meta researcher Mick Ayzenberg gave agents operating in strong sandboxes or isolated from production as examples of that state.

A Fully Autonomous Agent operates inside a strong boundary. To let one work autonomously for long periods, first provide an environment that cannot reach sensitive data or production systems.

## 6. Give Freedom Through Isolation

The way to expand an agent's freedom is to fix its reach with a boundary and allow it to work freely inside.

Weak isolation: shared host privileges → review every command → constrain freedom.

Strong isolation: enforced reach boundary → no review inside → expand freedom.

Sandbox strength and agent freedom need not conflict. Strong isolation is what allows substantial freedom.

This is a design interpretation. No study directly measures the complete causal chain from isolation to freedom to autonomy and outcomes. The following evidence supports that design direction.

In October 2025, Anthropic reported that introducing a sandbox into Claude Code reduced permission prompts by 84% in internal use. This measures the number of prompts, not task success. The same article argues that defining a boundary within which Claude can act freely improves both security and autonomy. OpenAI's Codex documentation similarly describes trust in enforced boundaries rather than solely in the agent's intentions. Anthropic's May 2026 article goes further: strong boundaries allow less supervision, and Claude Code's reference devcontainer was designed for unattended operation without per-action approval.

The boundary needs both filesystem and network isolation. Without network isolation, a compromised agent can send sensitive files such as SSH keys outside. Without filesystem isolation, it can break out of the sandbox and gain network access.

There are situations where model judgment is insufficient. In an internal red-team exercise in February 2026, Anthropic researchers phished employees into launching Claude Code with a malicious prompt. The prompt looked like an ordinary workflow but asked the agent to read ~/.aws/credentials, encode it, and POST it externally partway through. Across 25 attempts with the same prompt, Claude completed the exfiltration 24 times.

> The only defense that holds in this situation is the environment, specifically egress controls that block the POST regardless of intent and filesystem boundaries that keep ~/.aws out of reach in the first place.

Credentials are the first thing to keep outside the boundary. Products separate them in different ways:

- Claude Code cloud execution: Git credentials and signing keys stay outside the sandbox.

- Codex cloud environments: Secrets are available only to the setup script and are removed before the agent begins.

- The initial version of Claude Cowork: On macOS, it ran in a VM using Apple's Virtualization framework; credentials stayed in the host keychain rather than entering the guest.

Network allowlists have an easily missed property. Claude Cowork allowed api.anthropic.com because the product required it. A malicious file in the workspace contained an attacker's API key and hidden instructions. Claude followed those instructions and uploaded workspace files to the attacker's account through the Files API.

> The sandbox worked perfectly, and yet the data was exfiltrated.

Anthropic concludes that allowlists are better understood as capability grants: every function reachable through an allowed domain becomes part of the attack surface. Claude Code's CVE-2026-54316 has the same structure. Because WebFetch preapproved huggingface.co, access to an attacker's model repository passed without approval. A request recorded as a download became an exfiltration channel. Choose permitted domains by examining all the capabilities they expose, not merely their destination names.

Isolation mechanisms also differ in strength.

OS sandbox — Kernel relationship: Shared with the host; Examples: Seatbelt on macOS, bubblewrap on Linux.

Container — Kernel relationship: Shared with the host; Examples: Docker.

Userspace kernel — Kernel relationship: No direct access to the host kernel; Examples: gVisor.

microVM — Kernel relationship: Each guest has its own kernel; Examples: Firecracker, Kata Containers.

Containers share the host kernel, so system calls inside the container reach that same kernel, and kernel vulnerabilities can lead to escape. In SandboxEscapeBench, from the UK AI Security Institute and the University of Oxford, GPT-5 and Claude Opus 4.5 achieved 40% success on difficulty-three container-escape scenarios. The paper regards plain Docker isolation as insufficient by default and recommends stronger isolation mechanisms.

In gVisor, a Go application kernel running in userspace receives system calls; none are passed straight through to the host. The Firecracker paper describes a traditional tradeoff between higher-security, higher-overhead virtualization and lower-security, lower-overhead containers. Firecracker, which supports AWS Lambda and Fargate, was built to avoid that choice: a lightweight virtual machine monitor replacing QEMU while retaining KVM. It uses less than 5 MB of memory per microVM, starts in under 125 milliseconds, and can create up to 150 microVMs per second on one host. Those figures use a minimal guest kernel.

According to Anthropic's May article, the hypervisors, seccomp, and gVisor used in its products worked as expected; its custom allowlist proxy was what failed. Choose isolation that avoids sharing the kernel, and use established isolation mechanisms rather than custom components.

The boundary itself can also contain bugs. In Codex CLI's CVE-2025-59532, a model-generated working directory was treated as a writable sandbox scope. The model's output must not define the boundary. Claude Code's CVE-2026-55607 used symlinks and git fsmonitor during git worktree operations to rewrite .zshenv in the home directory and execute code outside the macOS sandbox. A sandbox is software too: it requires updates and verification.

There is a cost. The auto mode article acknowledges that sandboxes are safe but operationally demanding. New features require configuration, and work needing network or host access challenges isolation. Still, reflecting on the phishing and allowlist incidents, the May article notes that there was no anomaly for the model layer to detect. It concludes:

> The deterministic boundary is what gets hit when everything probabilistic misses.

## 7. Requirements for a Sandbox

The following table is my synthesis of the preceding discussion. For each element, it separates freedom inside the environment from guarantees at the boundary.

Filesystem — Freedom inside: Read, write, and delete workspace files; Guarantee at the boundary: No access to home directories, keys, or configuration files.

Process — Freedom inside: Start servers and databases; run for extended periods; Guarantee at the boundary: No interference with host processes.

Runtime — Freedom inside: Freely use language runtimes and build tools; Guarantee at the boundary: No shared kernel, or no direct access to it.

Package — Freedom inside: Install dependencies discovered during work; Guarantee at the boundary: Restrict sources and retain records.

Network — Freedom inside: Read documentation and fetch dependencies; Guarantee at the boundary: Restrict destinations and operations; log all traffic.

Browser — Freedom inside: Operate and verify web applications; Guarantee at the boundary: Do not import real account sessions.

Identity — Freedom inside: Operate with agent-specific privileges; Guarantee at the boundary: Do not reuse a person's account.

Credentials — Freedom inside: Have necessary external operations performed by a proxy; Guarantee at the boundary: Keep the secrets themselves outside.

Resources — Freedom inside: Use CPU, memory, and disk; Guarantee at the boundary: Set limits so runaway work cannot affect the outside.

Persistence — Freedom inside: Carry the environment and work into the next day; Guarantee at the boundary: Keep them separate from production data.

Recovery — Freedom inside: Break things and try again; Guarantee at the boundary: Whole-environment snapshots and rollback.

Observability — Freedom inside: Experiment freely; Guarantee at the boundary: Audit logs of commands, traffic, and changes.

Policy — Freedom inside: No review of operations inside; Guarantee at the boundary: Evaluate only operations crossing the boundary.

Approval is one part of Policy in this table. Rather than asking for approval for every operation, evaluate boundary-crossing actions such as production deployment or transmission to an unapproved destination. With fewer approvals, people can devote attention to each decision.

## 8. Let the Agent Build Its Own Environment

One way to prepare a sandbox is to preinstall everything it will need. But requirements often become clear only during the task, making environment setup part of the agent's work.

Most existing benchmarks evaluate agents in environments with dependencies already installed. Microsoft's SetupBench does the opposite: starting with an empty Linux sandbox, agents must install packages, resolve dependency conflicts, initialize databases, and configure background services. Across 93 tasks, success rates were 62.4% for Claude 4 Sonnet and 34.4% for GPT-4o. Roughly 17–26% of repository setup failures came from not installing test tools. In EnvBench, even the best method successfully set up only 6.69% of Python repositories and 29.47% of JVM repositories.

Terminal-Bench 2.0 permits internet access for package installation and web research. Yet the most common failure was a command invoking an executable that was missing or absent from PATH, accounting for 24.1% of failures. This was not a restriction experiment. Even with network access, discovering and installing missing commands becomes an intermediate task before solving the original problem. Repairing the environment lies on the path to solving the task.

Who performs setup also changes its cost. In SWE-Gym, manually preparing dependencies for 11 repositories took about 200 hours. In SWE-smith, agents prepared environments for 128 repositories, with about 18 hours of human review. These were different setup procedures, not a controlled comparison. Nevertheless, delegating environment setup to agents offers a way to scale.

In September 2025, OpenAI announced that Codex could locate and execute common setup scripts to prepare its own environment. With internet access configured, it can fetch newly discovered dependencies through commands such as pip install. Codex cloud environments divide execution into two stages. During setup, the environment can access the network, install dependencies, and use secrets. During the agent stage, secrets are removed and internet access is blocked by default. If enabled, access can be limited to selected domains and the GET, HEAD, and OPTIONS HTTP methods.

My interpretation is that known dependencies should be installed during setup, while dependencies discovered during work must be installable during the agent stage. As the AgentDojo and Progent results in Section 3 show, excluding unanticipated requirements can stop an agent halfway through. Restricting requests to GET still leaves transmission channels, however. In the Hugging Face case discussed earlier, a request recorded as a download was the exfiltration path.

Install known dependencies during setup, and permit installation during work inside the boundary. Restrict package sources and log all traffic.

## 9. From Disposable Environments to Persistent Computers

For an agent that can build its own environment, starting from scratch every time is a loss. SetupBench reports failures where globally installed tools did not survive across shell sessions. In one instance, the agent installed pnpm, but it was unavailable when the evaluation harness opened a new shell.

Anthropic's article on harnesses for long-running agents compares work across context windows to a team of engineers working in shifts. The incoming engineer does not remember what happened on the previous shift. Its design creates three things in the first session:

- A script to start the environment.

- A file recording progress.

- An initial git commit.

Subsequent sessions leave clues for the next session after each round of work. Memory is stored in the environment.

In January 2026, Fly.io's Kurt Mackey argued that disposable sandboxes were obsolete and should stop being discarded after each use. He described what agents want:

> They don’t want containers. They don’t want “sandboxes”. They want computers.

In Fly.io's definition, a computer need not disappear when one job ends; it has persistent storage. Providers already differ in how they retain state.

Fly.io Sprites — Isolation: microVM; State retention: 100 GB persistent storage, no time limit, checkpoints and restoration.

E2B — Isolation: Firecracker; State retention: Paused environments retained indefinitely; snapshots include memory.

Vercel Sandbox — Isolation: Firecracker; State retention: Persistent by default; automatic filesystem snapshot on stop.

Modal — Isolation: gVisor; State retention: Five minutes by default, up to 24 hours; filesystem snapshots.

Cloudflare Containers — Isolation: A VM per container; State retention: Ephemeral disk; directories backed up to R2.

Codex cloud — Isolation: Container; State retention: Container state cached for up to 12 hours.

Claude Code on the web — Isolation: A VM per session; State retention: Setup results retained as filesystem snapshots for about seven days.

Claude Managed Agents — Isolation: A container per session; State retention: Fresh container for each session; no shared filesystem.

Claude Code on the web snapshots the filesystem when the setup script finishes, then uses that snapshot as the next session's starting point. What the script wrote to disk survives; processes that were merely running do not. Other designs, such as Claude Managed Agents, use a fresh container for every session. Disposability has the advantage of not carrying forward prior failures or contamination. The choice compares the value of accumulated work with the risk of contaminated state.

The sandbox's unit of operation is shifting from a single session toward a computer that stays in use. For tasks with expensive setup, choose an environment that preserves setup results. If running servers and process state must also be restored, choose snapshots that include memory as well as the filesystem. Persistent environments also accumulate failures.

## 10. Design for Safe Failure

An agent with freedom will eventually make mistakes. Here are incidents that have already occurred:

Replit, July 2025 — What happened: A development agent deleted production database data during a code freeze; Where the cause lay: Development and production databases were not separated.

Google Antigravity, reported December 2025 — What happened: In Turbo mode, an attempt to delete a cache deleted the root of the D drive, bypassing the recycle bin; Where the cause lay: The agent could reach the entire drive.

Gemini CLI, July 2025 — What happened: Files were lost after a folder-organization request; Where the cause lay: Execution was not sandboxed.

The Antigravity incident was reported by The Register based on one user's account.

In the Replit incident, SaaStr's Jason Lemkin had tried to stop the behavior through instructions. The Register quoted him:

> I explicitly told it eleven times in ALL CAPS not to do this.

Lemkin also said that vibe-coding apps such as Replit had no way to enforce a code freeze. Replit CEO Amjad Masad posted on X that this should never happen and began rolling out automatic separation of development and production databases over the weekend. That response aimed to make the incident structurally impossible through environmental separation, rather than instructions to the agent.

Instructions cannot create a boundary. The environment must enforce it.

Recovery mechanisms have limits too. Claude Code checkpoints rewind changes made through the agent's file-editing tools; they do not track files changed through bash commands. Replit rollback also does not automatically restore production databases. The more an agent uses the shell, the less adequate tool-level undo becomes, and the more necessary whole-environment recovery is. Fly.io compares Sprites checkpoints to git for the entire system. E2B snapshots capture both the filesystem and memory state of a running sandbox. Filesystem-only snapshots cannot restore a running server or shell's state.

Agents can also destroy their own sandboxes. In long-running SandboxEscapeBench experiments, among trials that failed to escape, the sandbox became unresponsive in all 14 of 14 trials for Claude Mythos Preview and in 20 of 31 for Claude Opus 4.6. Agents had run destructive exploits that broke their own sandbox, often early in the attempt: at a median of 11% through the transcript. These figures come from the specialized setting of attempted sandbox escape, but they demonstrate that agents can break their environments. If a broken environment can be discarded and restored, that becomes an attempt rather than an incident.

Anthropic's internally collected incidents include operations that crossed the boundary:

- Deleting a remote git branch after misunderstanding an instruction.

- Uploading an engineer's GitHub authentication token to an internal compute cluster.

- Attempting to run a migration against a production database.

A sandbox snapshot cannot undo any of these.

My interpretation is that rollback applies inside the captured boundary. Resource limits keep runaway execution within it, and audit logs provide a way to determine afterward what happened.

Safe failure requires two things. Targets whose changes cannot be undone by the sandbox, such as production databases, remote repositories, and credentials, must not be directly reachable from inside. Within the boundary, restore the whole environment rather than individual tools' changes. The goal is an environment where an agent's failures can be reversed inside the boundary.

## Conclusion

Put together, this is one computer with clearly assigned boundaries:

Human: defines the objective and boundaries.

Agent computer, strongly isolated: agent → shell, runtimes, packages, persistent filesystem, browser; snapshots and rollback cover the environment.

External access: agent computer → egress proxy, restricting destinations and operations → policy, evaluating boundary crossings → Git, packages, and APIs.

Credentials: a vault outside the computer provides credentials to the proxy.

Audit: both the computer and its outbound traffic produce audit logs.

An agent's capability is not determined by its model alone. The same model can produce different results when given a shell, dependency installation, execution feedback, and persistent work. Removing execution and verification has the greatest impact; the number of specialized tools is not the decisive factor.

Prohibiting dangerous command names cannot block alternative expressions of the same behavior, and it also blocks harmless work. One-by-one approvals miss more danger over time and interfere with long-running autonomy. The thing to control is the agent's reach.

The design sequence is:

1. Establish filesystem and network boundaries with isolation strong enough to avoid sharing the host kernel.

1. Keep credentials and production data outside those boundaries.

1. Allow shell use and installation inside, and make the environment persistent.

1. Evaluate operations that cross the boundary, and make everything inside recoverable as a whole.

A sandbox is the boundary that gives an agent freedom.

## References

## Models, Harnesses, and Environments

- Merrill et al. (2026) Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces. arXiv Harness differences with the same model, internet access, and missing-command failures. (https://arxiv.org/abs/2601.11868)

- Cheng et al. (2026) Computer Environments Elicit General Agentic Intelligence in LLMs. arXiv Opposite effects of sandbox access on stronger and weaker models. (https://arxiv.org/abs/2601.16206)

- Anthropic (2025) Building agents with the Claude Agent SDK The principle of giving agents a computer. (https://claude.com/blog/building-agents-with-the-claude-agent-sdk)

- OpenAI (2025) Introducing ChatGPT agent An agent working on a virtual computer. (https://openai.com/index/introducing-chatgpt-agent/)

- Manus (2025) Context Engineering for AI Agents: Lessons from Building Manus Using the filesystem as context. (https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus)

## Restrictions and Performance

- Yang et al. (2024) SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. NeurIPS ACI versus shell-only operation and component ablations. (https://arxiv.org/abs/2405.15793)

- Yang et al. (2023) InterCode: Standardizing and Benchmarking Interactive Coding with Execution Feedback. arXiv The effect of execution feedback. (https://arxiv.org/abs/2306.14898)

- SWE-agent. mini-SWE-agent A minimal bash-only agent. (https://github.com/SWE-agent/mini-swe-agent)

- SWE-bench. SWE-bench Verified Leaderboard for bash-only agents. (https://www.swebench.com/verified.html)

- Yang, Yu, Desell (2026) When Does Restricting a Coding Agent to execute_code Help? A Regime × Agent-Design Ablation. arXiv Success-rate differences below three percentage points across tool configurations. (https://arxiv.org/abs/2607.10569)

- Verdent (2025) Verdent SWE-bench Verified Technical Report Nearly unchanged performance with basic tools alone. (https://www.verdent.ai/blog/swe-bench-verified-technical-report)

- Qu (2025) We removed 80% of our agent's tools. Vercel An internal deployment replacing specialized tools with bash. (https://vercel.com/blog/we-removed-80-percent-of-our-agents-tools)

- Debenedetti et al. (2024) AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents. NeurIPS Tool-filter effectiveness and limits when tool needs cannot be planned in advance. (https://arxiv.org/abs/2406.13352)

- Shi et al. (2025) Progent: Programmable Privilege Control for LLM Agents. arXiv Static restrictions versus runtime privilege expansion. Figures use v1; the current title is “Progent: Securing AI Agents with Privilege Control.” (https://arxiv.org/abs/2504.11703)

## Approvals and Allowlists

- Dworken, Weller-Davies (2025) Beyond permission prompts: making Claude Code more secure and autonomous. Anthropic An 84% reduction in permission prompts, and both filesystem and network isolation. (https://www.anthropic.com/engineering/claude-code-sandboxing)

- Hughes (2026) How we built Claude Code auto mode: a safer way to skip permissions. Anthropic Removing permission rules that allow arbitrary code execution; sandbox operating costs. (https://www.anthropic.com/engineering/claude-code-auto-mode)

- Anthropic (2026) How we contain Claude across products Supervising reach rather than behavior, phishing exercises, and allowlist-based exfiltration. (https://www.anthropic.com/engineering/how-we-contain-claude)

- Anthropic (2026) Auto mode is now the default in Claude Code for Pro, Max, and Team plans The experiment with 1,053 testers and permission-rule usage. (https://claude.com/blog/auto-mode-default-in-claude-code)

- OpenAI. Agent approvals & security – Codex Trust in enforced boundaries. (https://developers.openai.com/codex/agent-approvals-security)

- GTFOBins Ways to launch shells through common commands. (https://gtfobins.github.io/)

- npm Docs. scripts Lifecycle scripts executed by npm install. (https://docs.npmjs.com/cli/v11/using-npm/scripts)

- Backslash Security (2025) The Denylist Delusion: Cursor’s Auto-Run Leaves Agentic AI Wide Open Four denylist bypasses and the stated theorem. (https://www.backslash.security/blog/cursor-ai-security-flaw-autorun-denylist)

- Cursor. GHSA-534m-3w6r-8pqr (CVE-2025-54131) Command substitution in allowed commands. (https://github.com/cursor/cursor/security/advisories/GHSA-534m-3w6r-8pqr)

- Anthropic. GHSA-x56v-x2h6-7j34 (CVE-2025-54795) Approval bypass through echo parsing errors. (https://github.com/anthropics/claude-code/security/advisories/GHSA-x56v-x2h6-7j34)

- Anthropic. GHSA-qgqw-h4xq-7w8w (CVE-2026-24887) Approval bypass using find. (https://github.com/anthropics/claude-code/security/advisories/GHSA-qgqw-h4xq-7w8w)

- Anthropic. GHSA-7mv8-j34q-vp7q (CVE-2025-64755) Arbitrary file writes through sed validation bypass. (https://github.com/anthropics/claude-code/security/advisories/GHSA-7mv8-j34q-vp7q)

- Tracebit (2025) Code Execution Through Deception: Gemini AI CLI Hijack Environment-variable exfiltration through commands disguised as grep. (https://tracebit.com/blog/code-exec-deception-gemini-ai-cli-hijack)

- Embrace The Red (2025) GitHub Copilot: Remote Code Execution via Prompt Injection (CVE-2025-53773) Disabling approvals by modifying settings. (https://embracethered.com/blog/posts/2025/github-copilot-remote-code-execution-via-prompt-injection/)

## Threat Models and Incidents

- Meta (2025) Agents Rule of Two: A Practical Approach to AI Agent Security A framework limiting agents to two of three properties. (https://ai.meta.com/blog/practical-ai-agent-security/)

- Willison (2025) New prompt injection papers: Agents Rule of Two and The Attacker Moves Second Questions about the Rule of Two and Mick Ayzenberg's clarification. (https://simonwillison.net/2025/Nov/2/new-prompt-injection-papers/)

- The Register (2025) Vibe coding service Replit deleted production database Production database deletion during a code freeze. (https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/)

- Masad (2025) X post Automatic separation of development and production databases. (https://x.com/amasad/status/1946986468586721478)

- The Register (2025) Google's vibe coding platform deletes entire drive A report of drive deletion in Turbo mode. (https://www.theregister.com/2025/12/01/google_antigravity_wipes_d_drive/)

- google-gemini/gemini-cli Issue #4586 A report of file loss without sandboxing. (https://github.com/google-gemini/gemini-cli/issues/4586)

- Anthropic. GHSA-fg94-h982-f3mm (CVE-2026-54316) Exfiltration through a preapproved Hugging Face domain. (https://github.com/anthropics/claude-code/security/advisories/GHSA-fg94-h982-f3mm)

- OpenAI. GHSA-w5fx-fh39-j5rw (CVE-2025-59532) A bug treating a model-generated working directory as the sandbox scope. (https://github.com/openai/codex/security/advisories/GHSA-w5fx-fh39-j5rw)

- Anthropic. GHSA-7835-87q9-rgvv (CVE-2026-55607) Code execution outside the sandbox using git worktree. (https://github.com/anthropics/claude-code/security/advisories/GHSA-7835-87q9-rgvv)

## Isolation and Persistence

- Anthropic. Securely deploying AI agents Risks from containers sharing the host kernel. (https://code.claude.com/docs/en/agent-sdk/secure-deployment)

- Marchand et al. (2026) Quantifying Frontier LLM Capabilities for Container Sandbox Escape. arXiv SandboxEscapeBench: container escape and agents destroying their own sandboxes. (https://arxiv.org/abs/2603.02277)

- Agache et al. (2020) Firecracker: Lightweight Virtualization for Serverless Applications. NSDI Lightweight microVM design and performance. (https://www.usenix.org/conference/nsdi20/presentation/agache)

- gVisor. Security Model A design that does not pass system calls directly to the host. (https://gvisor.dev/docs/architecture_guide/security/)

- Kata Containers Containers isolated through virtual machines. (https://katacontainers.io/)

- Mackey (2026) Code And Let Live. Fly.io From disposable sandboxes to persistent computers. (https://fly.io/blog/code-and-let-live/)

- Ptacek (2026) The Design & Implementation of Sprites. Fly.io 100 GB persistent storage and checkpoints. (https://fly.io/blog/design-and-implementation/)

- E2B. Sandbox persistence Indefinite paused-state retention and snapshots including memory. (https://docs.e2b.dev/sandbox/persistence)

- Vercel. Understanding Sandboxes Sandboxes that are persistent by default. (https://vercel.com/docs/sandbox/concepts)

- Modal. Sandboxes Runtime limits and filesystem snapshots. (https://modal.com/docs/guide/sandboxes)

- Cloudflare. Containers architecture A VM per container and ephemeral disk. (https://developers.cloudflare.com/containers/concepts/architecture/)

- OpenAI. Cloud environments – Codex Two-stage execution, secret removal, and a 12-hour cache. (https://learn.chatgpt.com/docs/environments/cloud-environment)

- OpenAI. Agent internet access – Codex web Domain allowlists and HTTP method restrictions. (https://learn.chatgpt.com/docs/cloud/internet-access)

- Anthropic. Configure cloud environments Per-session VMs and filesystem snapshot caching. (https://code.claude.com/docs/en/cloud-environments)

- Anthropic. Cloud environment setup Managed Agents using a fresh container for each session. (https://platform.claude.com/docs/en/managed-agents/environments)

- Anthropic. Checkpointing Checkpoints that do not track bash changes. (https://code.claude.com/docs/en/checkpointing)

- Replit. Checkpoints and Rollbacks Rollback that does not automatically restore production databases. (https://docs.replit.com/features/version-control/checkpoints-and-rollbacks)

## Environment Setup and Long-Running Autonomy

- Arora et al. (2025) SetupBench: Assessing Software Engineering Agents' Ability to Bootstrap Development Environments. arXiv Bootstrapping empty environments and failures to preserve changes. (https://arxiv.org/abs/2507.09063)

- Eliseeva et al. (2025) EnvBench: A Benchmark for Automated Environment Setup. arXiv Setup success rates for Python and JVM repositories. (https://arxiv.org/abs/2503.14443)

- Pan et al. (2025) Training Software Engineering Agents and Verifiers with SWE-Gym. ICML About 200 hours of manual dependency setup. (https://arxiv.org/abs/2412.21139)

- Yang et al. (2025) SWE-smith: Scaling Data for Software Engineering Agents. arXiv Agent-driven setup for 128 repositories. (https://arxiv.org/abs/2504.21798)

- OpenAI (2025) Introducing upgrades to Codex More than seven hours of independent work and automatic environment setup. (https://openai.com/index/introducing-upgrades-to-codex/)

- Anthropic (2025) Introducing Claude Sonnet 4.5 More than 30 hours of sustained focus. (https://www.anthropic.com/news/claude-sonnet-4-5)

- METR. Time horizons Task horizons measured in human work time. (https://metr.org/time-horizons/)

- Young (2025) Effective harnesses for long-running agents. Anthropic The shift-work analogy and handoffs stored in the environment. (https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)