The first generation of coding assistants mostly stayed outside the repository. They could answer questions, explain code, and generate diffs, but the actual work still came back to the developer. Someone had to apply the change, run the command, check the failure, and decide what happened next.

As assistants became agents, tools like Aider, Cursor, and Claude Code gave models access to the repo, the filesystem, and the terminal. This did remove a lot of friction: if the agent already knew what to edit and which test to run, it could close the loop itself.

But giving agents the ability to act also changed the risk. Shell access is useful for running tests and installing dependencies, but it can also execute destructive commands, expose sensitive files, or follow malicious instructions hidden in the repo. Permissioning helped, but allowlists and approval prompts could only go so far. Shell safety is contextual, and the same command can be harmless in one situation and dangerous in another.

Long-running workflows like Ralph loops and later claw systems made this more obvious. Developers wanted agents that could keep working beyond a single prompt: try an approach, run tests, inspect failures, update code, and continue. That kind of autonomy needs more than tool access. It needs a safe, persistent place to work.

While building Potpie, we ran into the same issue. There were no agent specific isolation systems that catered to the quirks of agent specific permissions. Docker, spare machines, allowlists, and remote sandboxes each solved part of the problem, but each left something unresolved: persistence, privacy, recovery, scale, and lastly trust.

That is why coding agents need an agent-native sandbox: A sandbox with a safer but permissive shell, a controlled workspace where they can work freely enough to be useful without putting the host, the codebase, or any other systems at risk.

Agent-native sandbox: A sandbox is more than an execution layer

Traditionally, a sandbox has been seen as a secure place to execute shell commands. That is part of it, but for coding agents, it is not enough. A coding agent needs three things to stay separate: the repository, the workspace and the execution environment.

The repository (eg: GitHub), is the source of truth. It should be cloned once, cached, and reused.

The workspace, like a local project folder, is where the agent does its actual work: edits, generated code, temporary changes, and task-specific state. If the agent session or command runner restarts, this should not disappear.

The execution environment is a virtual system where the commands run. The virtual environments can be LXC containers or VMs of any kind. The main requirement for these systems is they can maintain statefulness allowing for easy restart and replacement without taking the workspace down with it.

When these layers are tied too closely together, small failures become costly. A container restart should not erase edits, and a broken command runner should not force the agent to rebuild its context from scratch. Agents also introduce failure modes that normal execution environments were not designed around: long-running loops, partial edits, repeated retries, tool failures, prompt-injection risk, and state that needs to survive across sessions. So it is imperative a sandbox should separate durable workspace state from disposable execution, and is designed around the way agents actually work.

Agentic workflows need stronger isolation

Before AI agents, most code execution was still human-mediated. A developer reviewed the command, ran the script, approved the dependency, or checked the CI output.

Agents changed that.

They write code dynamically, install packages, run commands and follow instructions from files, issues and tool outputs. They may get it right, hallucinate a step, or read something malicious without realizing it.

This is why isolation matters.

A sandbox creates a boundary between the agent’s execution environment and the rest of your system. If the agent runs a bad command, installs a suspicious dependency or gets tricked by a prompt injection hidden in a README, the damage should stay contained. It should not touch your host machine, your production systems or another team’s workspace.

Isolation can also take more than one form. File system boundaries, network controls, secret handling, environment variable access, and outbound request policies are all part of the same problem. For example, some agent platforms are starting to treat credentials as something the agent should not see directly, even when the task needs access to a tool or service. LangSmith’s approach to hiding environment tokens points in this direction: the agent can use what it needs without being handed every secret in plain text.

As the agent runtime matures, these boundaries should become more explicit and more configurable. Teams should be able to decide what the agent can read, where it can connect, which secrets it can use indirectly, and what parts of the environment are completely off-limits. The important part is that these controls should not be bolted on as one-off decisions for every task. They should be part of the sandbox model itself.

For local development, this sandbox can simply be a container. Containers are fast, practical and easy to spin up, which makes them a good default for coding agents. But the broader idea is the same regardless of the backend: the agent needs an isolated place to work.

As teams scale, the isolation boundary needs to get stronger. A local container may be enough for one developer, while larger teams will eventually want managed sandboxes, shared infrastructure or stronger VM-like isolation. The infrastructure should be able to grow with the team.

Not every team needs a self-contained sandbox from day one. But every coding agent needs a safe execution boundary from the start.

Stable sandbox accelerates the agent workflow

In less tool-native setups, agents end up relying heavily on prompts for file edits. If they need to change a file, they have to pull file contents into context, reason over them, generate a diff and hope the patch applies cleanly. That burns tokens and makes edits more fragile.

With a stable write-capable workspace, the agent does not need to describe every file operation in the prompt. It can use tools directly.

The flow is simple: the agent works inside the sandbox, makes changes, runs checks, and returns the result as a diff, branch, or pull request. From there, the engineering workflow takes over: review, CI, approval, and merge. If the same task needs more work later, the agent can return to that environment. If not, it can be cleaned up.

This boundary matters. The agent gets a safe place to edit, test, search the repo, run commands, and prepare commits, but production code still moves through the usual controlled process.

This improves the efficiency of the agent loop. The model can focus more on the task instead of wasting context on moving file contents around.

This follows the same pattern as Potpie’s knowledge graph approach: agents work better when they can query structure instead of blindly searching through raw text, and when they retrieve only the code they actually need instead of pulling entire files into context.

The guarantees that matter

A sandbox system for coding agents should keep a few promises.

The repository should not be re-cloned for every task. If the repo has already been cloned and cached, the agent should use that cached version. Re-cloning wastes time, bandwidth, and compute.

The workspace should survive restarts. If an execution process dies or a sandbox is evicted, the agent’s edited files should still be there.

Execution should be replaceable. A broken command environment should not destroy repository state or workspace state.

State should be tracked explicitly. Database-backed state tracking matters because resume, cleanup, eviction, and lifecycle management need to be honest. The system should know which repo is cached, which workspace belongs to which task, which backend is active, and what can be safely cleaned up.

Without this knowledge, sandbox recovery becomes guesswork. And guesswork is exactly what you do not want in infrastructure that is supposed to let agents work autonomously.

Parallel Sandboxes: From safe execution to faster experimentation

Once sandboxes become cheap and reliable, you do not have to think of them as one agent working in one environment. You can run multiple isolated sandboxes at the same time.

One sandbox can try one implementation branch. Another can try a different approach. A third can run tests or check for regressions. None of them pollute each other’s workspace, and the system can compare the results before deciding what to keep.

This matters because software work is often exploratory. There are usually multiple ways to fix a bug, refactor a module or design an API. Parallel sandboxes let agents try those paths side by side instead of one after another.

This is where sandboxing stops being just a safety layer. It becomes a way to make agents faster, more reliable and less afraid to experiment.

Why Containers work locally, but do not solve everything

For local development, a containerized sandbox is the obvious starting point.

Docker is the most familiar version of this. It is quick to spin up, easy to clean up and gives enough isolation without adding the overhead of a remote setup. Since everything runs locally, latency between the agent and the sandbox is minimal. Commands execute fast and file changes feel instant.

The important part is that the container is write-capable. Modern coding agents are not just answering questions anymore. They are modifying files, creating branches, running tests, and validating changes. They need a workspace they can actively work in.

For an individual developer or a medium-sized repo, this works well. But once teams start running many agents, working with larger repositories, or delegating heavier tasks, the developer’s machine becomes a bottleneck. Your laptop should not be the limiting factor deciding whether an agent can finish a long-running refactor.

That is why the sandbox backend needs to be pluggable.

Making Sandbox backend pluggable by design

Once local containers stop being enough, the temptation is to pick one self-contained sandbox backend and build everything around it.

That works for a while, but it does not scale across different teams. A small team may care most about fast local execution. A larger team may need stronger isolation. Enterprises may need shared storage and persistent remote workspaces that are not tied to a single developer’s machine.

So the agent should be agnostic to the sandbox underneath. Docker can be the fast local default, Daytona can handle managed remote sandboxes, NFS can support teams running many agents at scale, and E2B can slot in as another managed backend when needed.

The agent should talk to one clean interface. The backend becomes a deployment choice, while the agent logic stays stable.

From Supervision to Delegation

The sandbox may look like a backend detail. For coding agents, it becomes part of the agent contract. It defines where edits live, how commands run, what state survives, which secrets are available, and what should happen when execution fails. Those details matter because the agent works across a longer chain of actions: reading tool output, making partial edits, retrying failed steps, installing dependencies, and sometimes continuing through long-running loops.

That is why the sandbox has to be designed around agent-specific failure modes. If the runtime disappears, the workspace should remain intact. If a command environment breaks, it should be possible to replace it without losing the task. If a workflow needs stronger isolation, the backend should be able to change without forcing the agent logic to change with it. The system should handle this complexity in the sandbox layer, where workspace state, execution, and access can be managed deliberately.

Docker, Daytona, NFS, and E2B are useful because they answer different parts of this architectural requirement. One team may need fast local execution, another may need persistent remote workspaces, and another may care most about stronger isolation or shared storage. A stable sandbox interface keeps the agent logic independent from those deployment choices, while the backend is selected based on the task, the team, and the level of isolation required.

Once that layer exists, delegation changes shape. Developers can define the boundary the agent operates inside: what it can access, where it can run, what state is durable, and how failures are recovered. The agent gets a consistent place to work, and the system keeps that work contained enough to be trustworthy.