What happens to the work when the sandbox is lost?

An agent wakes up and clones a repository. It writes itself a helper script, drops an analysis into a file it invented on the spot, and gets halfway through the fix. Then the container is gone. An OOM kill, a host that reboots, a prune.

What of that do you still have tomorrow?

Somebody on Hacker News asked in October 2025 how to keep the compute layer stateless without storing whole system states somewhere. The answer given: mounted volumes, re-mounted on restart.

Volumes are half an answer, because the other half begins when the machine itself fails.

The compute is short-lived, the home persists

Compute and home are separated deliberately. The data plane is dumb and replaceable: a sandbox is an isolated workplace with a persistent home and a running daemon. It holds no state critical to the platform beyond the respective agent's working data. If it is lost, it is rebuilt from config and home.

The isolation model is one sentence long: persistent volume, ephemeral compute. The agent wakes up, mounts its home, works and goes back to sleep, and only the home survives.

That only shifts the question: a volume sits on a machine, and machines fail.

Almost nothing in a home is unique, and the little that is lies scattered

A measured developer home holds 7.1 GB (over 99 % of it derivable from somewhere else). Of that, 3.0 GB are checkouts under repos/ whose truth lives in the project's Git remote, and 4.0 GB of toolchain caches, among them flutter, .pub-cache, .gradle, .npm, jdk. A few MB are the wiki and the skills, which sit centrally anyway, leaving 48 MB whose source is nowhere else.

Those 48 MB are the entire point, and they lie everywhere. Beside the session transcripts you find useSevenAssistant.ts with 95 KB of extracted code, plus panel.json, subagent-223.json and the directories fix223/ and verify-729/. All of them sit in the root directory, where the agent happened to put them.

Because an agent puts its interim results wherever seems sensible to it, no list works. A positive list does not survive the agent who creates itself an analysis/ tomorrow, and a negative list against the image profile's caches fares the same. A list about a file's worth is a rule that can be wrong, and its error costs work already paid for.

So the whole home is secured

After every job the home goes into a central store as a whole and is materialised from there on wake, without whitelisting and without a check whether a checkout is clean. What counts as valuable is a question nobody asks.

What makes this practical is the store's construction. It is content-addressed: the same content is one block across an organisation's agents, keyed by (org_id, hash). Only new blocks travel upwards and only missing ones come down. Files up to 8 MB are addressed whole, larger ones split into fixed 4 MB blocks.

The 4 GB of toolchain caches therefore sit centrally once instead of once per agent, and the 48 MB travel with them, without anybody having to note that they exist.

The procedure has its own lifecycle state. securing (migration 0079_status_securing) sits between the last finished task and the vanished sandbox: the container stops, the home is written into the store. For a small home that is a second, for a grown one half a minute of scanning.

What the store holds is the state of the last sync. That sync runs at real falling-asleep, with the compute down and nothing writing into the home any more. A warm sandbox never reaches that point, so it is synced while parked, in the background and at most once every five minutes. An agent whose container dies mid-run finds the last of those syncs in the store; what it wrote since then goes with the container.

Something is left out even so, and the reason makes the difference. COVEY_HOME_EXCLUDES takes paths out of the sync, and its default is the scrap class, among them __pycache__, .dartServer, *.pyc, *.tmp, the pip and Playwright caches. Nothing but the tool that reads them recreates those, so their absence costs nothing. The package caches, .npm and .gradle for instance, are deliberately not in it, because leaving them out saves space and scan time and costs a fresh download on the next host.

What a loss costs is time

The agent's binding to a machine thereby turns into a preference. The scheduler prefers the runner it last ran on (its blocks already sit there locally); on a different one only the missing blocks follow.

The worst case is a fresh host without a single block: a full transfer, and a Flutter agent that reads no line for minutes. That costs time, and the state the store holds arrives intact.

The bill comes in several places. The longer sleep path is one, the first sync of a grown home a full pass over 7 GB. The store also holds what the runner has on disk anyway: with a single agent close to a doubling; from the second developer agent onwards deduplication earns it back.

And the store needs backup like the database. In its function it is a cache, in its need for protection a data set.

One snapshot exists per agent, replaced by every sync, and the store keeps no history of earlier states.

COVEY_HOME_STORE=false exists for the smallest installations. Homes then stay directories without snapshots, and a lost home is lost.

A sandbox may be dumb and replaceable as long as nothing lies in it that lies only in it. That is why the whole home goes into the store, with everything the agent built for itself.