The Sandbox Is the Wrong Abstraction for AI Coding Agents

Open any 2026 guide to running AI coding agents and you'll find the same definition. A sandbox is an isolated environment where an agent can execute code without touching your host — and it is ephemeral, destroyed automatically when the task completes.

Docker, E2B, Modal, Northflank, and most of the agent frameworks agree on this. It has become the default answer.

It's also, for a large and growing class of work, the wrong abstraction. Not because ephemerality is bad — it's excellent for what it was designed for — but because the industry has quietly applied a code execution primitive to a software development problem, and those are not the same thing.

Two problems that look identical

Problem one: run this untrusted code.

A user pastes Python into your app. An LLM generates a script you want to test. A CI job runs a fork's pull request. You need it isolated, you need it fast, and when it's done you want every trace of it gone.

Ephemeral sandboxes are the correct answer, and the engineering behind the good ones — sub-second cold starts, microVM isolation, aggressive teardown — is genuinely impressive. Nothing below argues otherwise.

Problem two: build and maintain this software.

An agent is adding OAuth to your API. That means reading the existing auth code, installing a library, wiring config, running the server, hitting an endpoint, reading a stack trace, fixing it, running the tests, discovering two unrelated tests now fail, fixing those, and opening a pull request. Then tomorrow, reviewing feedback and changing the approach.

These two problems have opposite requirements. The first wants no state. The second is made of state.

The industry took the primitive that solved the first and pointed it at the second, because it was there.

What ephemerality costs when you're actually building

The environment becomes the dominant cost

Every ephemeral task starts by rebuilding what the last one had. Clone the repo. Install dependencies. Start Postgres. Run migrations. Seed data. Build.

For a real project that's minutes — sometimes many. Against an agent step that takes seconds, you've inverted the ratio: most of the wall-clock time and most of the cost is spent recreating a world that existed five minutes ago and was deliberately deleted.

Teams work around this with layer caching, prebuilt images, and snapshot restores. Notice what those workarounds are: increasingly elaborate attempts to make an ephemeral environment behave like a persistent one. When your optimisations all point in one direction, the abstraction is fighting you.

Iteration count is the agent's effective intelligence

This is the part that gets underrated.

An agent's output quality is roughly a function of how many observe-and-correct loops it can run. Not model size — loops. A weaker model that can run its code, read the error, and try again will beat a stronger model reasoning blind about a codebase it can't execute.

Ephemeral environments tax every loop. When a single iteration costs ninety seconds of setup, the economics push you toward fewer, larger, more speculative steps — which is precisely the behaviour that produces confidently wrong code. You've optimised the environment for isolation and pessimised it for the thing that actually determines quality.

State the agent creates is state the agent needs

Give an agent a filesystem for an hour and it will use it well: notes on what it tried, a scratch script that reproduces the bug, a narrowed-down test case, a TODO of what's left.

That is externalised memory, and it's the same thing a competent engineer does. Ephemeral teardown deletes it. The next invocation re-derives it — burning context on orientation it already paid for once.

The deep problem isn't lost files. It's that the agent cannot accumulate understanding of your specific codebase. Every session begins as a stranger.

Some work does not fit in one session

A migration verified in stages. A refactor across forty files. An intermittent failure that needs twenty runs to reproduce. A feature that needs review, feedback, and revision.

None of this is exotic — it's ordinary engineering. In a stateless model, each piece must be re-established from scratch, or serialised into a prompt and hoped for. Long-horizon tasks aren't just slower here; many of them are structurally impossible.

The security objection, taken seriously

The strongest argument for ephemerality is safety: an agent might do something destructive, and a fresh environment guarantees a clean slate.

This deserves a real answer, because the concern is legitimate.

But look at what's actually being conflated. "Destroy the container" and "destroy the project" are different operations, and only the first is a security control. What protects you from a misbehaving agent is isolation — namespaces, enforced CPU and memory limits, a non-root user, no host filesystem, no Docker socket, restricted egress. Those hold whether the container lives for thirty seconds or thirty days.

What ephemerality adds on top is drift control — bounding how far an environment can wander from its declared state. Real, but a maintainability property, not a security one.

You can have both, and the split is the whole design:

The runtime is disposable. Rebuilt from an image, any time, no loss.
The project is durable. Source, git history, dependencies, environment variables, and data live on a mounted volume.

Destroying and recreating the container is routine. It just doesn't take your work with it.

The version-control analogy is exact: git doesn't make your working tree ephemeral to keep it safe. It gives you a durable history and a cheap path back to any known state. Safety through recoverability, not through amnesia.

When ephemeral is genuinely right

To be concrete, because the answer is not "persistence always":

Use ephemeral	Use persistent
Executing untrusted user code	Developing a specific project
One-shot script evaluation	Multi-step tasks across sessions
CI on untrusted forks	Debugging that needs accumulated state
Per-request tool calls	Agents that revisit a codebase
Adversarial / hostile input	Long-horizon refactors and migrations

The dividing line is simple: does the work have a memory? Evaluating an expression doesn't. Building a feature does.

Most agent infrastructure today assumes the first case, because it grew out of code-execution products. Most agent work is drifting toward the second.

What to ask a platform

If you're choosing infrastructure for coding agents:

What survives a container restart? If the answer isn't "repo, git history, dependencies, env vars, and data," it's a sandbox.
What does the second iteration cost? Compare a warm loop to a cold one. That ratio governs how well the agent works.
Is isolation independent of lifetime? Enforced limits should hold regardless of how long the workspace lives. If safety depends on teardown, the isolation is weak.
Can I recreate the runtime without losing the project? This should be a routine, boring operation.
Can I watch and interrupt it? Long-lived autonomous work is only acceptable if it's observable and stoppable mid-task.

The summary

Ephemeral sandboxes solve untrusted code execution, and they solve it well. That is a real problem and the engineering deserves respect.

But building software is not executing code. It's a long, stateful, iterative process where the environment accumulates the context that makes the next step cheaper. Applying a stateless primitive to it means paying setup costs forever, capping iteration count, and forcing the agent to rediscover your codebase every morning.

The right model isn't ephemeral or persistent. It's disposable runtime, durable project — isolation strong enough that lifetime stops being the safety mechanism.

EasySpawn gives every project a persistent workspace in an isolated container with enforced CPU, memory, and process limits — project data on a mounted volume, runtime rebuildable at any time. See how it works or join the waitlist.