Copy-on-Write Disk Forking as the Right Primitive for Persisting Agent Session State

Persistent storage for AI agent sandboxes that survives restarts needs a durable disk independent of the sandbox’s lifetime. Copy-on-write disk forking is the right persistence primitive because it gives checkpoints, branches, and rollback a common foundation without copying the whole environment. Paired with microVM memory snapshots, it preserves the running session too, making speculative work and warm resumption normal operations.

Why ephemeral sandboxes are the wrong substrate for agents that accumulate state

An agent halfway through a coding task has more to lose than its conversation history. It has cloned repositories, installed packages, warmed build caches, seeded databases, and left scratch files beside unfinished work. Some state lives only in a running interpreter. An ephemeral container discards that environment at teardown, so the next session starts by rebuilding yesterday’s workbench.

Semantic memory alone cannot bring back what was lost. Facts, summaries, and preferences belong in retrieval stores, while execution state belongs in the machine that does the work. A vector store can remember that a dependency was installed. It cannot make the dependency installed. Mixing up these layers leads to complex memory systems that still cannot pick up a job where it stopped.

Archil takes the opposite approach by running agents in persistent Firecracker microVMs with durable, forkable disks, so installed packages, cloned repositories, and build caches survive stops and restarts. Durable files preserve a workspace for reopening, while preserving a running process enables execution to resume.

What a microVM snapshot actually captures and why that matters for agents

A Firecracker microVM snapshot captures RAM and device state at one instant. Its rootfs disk is managed as a separate file that travels with the snapshot. With the matching disk state, restoration resumes the exact instruction where execution stopped, with files, caches, and processes intact.

That is a different promise from saving a directory. A Python process that already imported a large dependency resumes with that dependency present in memory. The state of a service’s listening process is saved too, so a startup script does not have to recreate it. The agent does not retrace its steps.

Copy-on-write memory mapping keeps the cost of restoration low by mapping snapshot pages privately and sharing them read-only until a write needs a private copy. PandaStack documents restore at around 49ms, with end-to-end create-from-snapshot at p50 179ms and p99 about 203ms. Its first cold boot, before it has a snapshot, takes around 3s.

A coding or research agent can put down its session and wake warm instead of keeping compute running merely to protect its place. Snapshot-and-restore already handles this well. It must then turn that saved state into several separate attempts without the cost of rebuilding each one.

How CoW forking collapses snapshotting, branching, and rollback into one operation

A CoW fork turns a frozen state into a branching point. Multiple live copies begin from the same memory and disk state, sharing unchanged pages and blocks while writes become private to each branch. The expensive preparation happens before the split. Installing packages, warming caches, and cloning repositories need not be repeated for every attempt.

With instant checkpoints and branches on a shared-nothing disk, as in Archil’s approach, prepared storage becomes a reusable starting point. Memory-inclusive forks extend that benefit to running programs. OpenDsec illustrates this with a parent that has already imported numpy. Its child inherits the import.

Checkpointing, branching, and rollback now operate on the same CoW tree. A checkpoint freezes a point in that tree, while a branch creates a new head sharing unchanged state. Rollback discards the branch’s private changes and returns to the parent. Its work is O(changed pages).

One primitive does not mean one undifferentiated implementation. TClone separates fast branch creation from durable checkpointing through CoW memory sharing, filesystem versioning, and asynchronous checkpointing. It reports total task latency reductions of 1.9× and 1.5× over KVM and CRIU respectively in end-to-end agent-loop measurement.

Location also changes the cost of a fork. Same-node children can share pages without making a physical copy first, which lowers latency and lets more children fit in memory. Cross-node forks must obtain the snapshot and restore locally. OpenDsec documents pulling it directly from the source edge node, keeping bulk transfer out of the stateless API layer.

What sub-second forking makes possible for agent execution patterns

When a fork takes milliseconds, an agent can branch before uncertainty. A coding agent might try two refactor strategies from the same prepared repository and test environment. Each attempt gets its own workspace. The runtime can evaluate the results, promote the successful branch, and discard the other without reconstructing the starting point.

A research agent can use the same pattern for alternative retrieval plans. Each branch starts with the same prepared environment, then takes a different route without overwriting the working files of another attempt. Each attempt needs a workspace that matches its own history.

TClone demonstrates this requirement through test-time tree search over GUI agent trajectories. Every trajectory needs its own live workspace state, so it forks at branch points. This makes branching part of execution itself.

An agent that follows a prompt injection or makes a destructive mistake can abandon the affected branch. TClone identifies risks including overwritten documents, deleted directories, changed settings, and exposed credentials. Workspace rollback addresses internal damage, but it cannot retract information already exposed outside that workspace.

Application-level branching is a related, narrower capability. The Claude Agent SDK exposes fork_session and session-specific resume operations for managing separate threads. Those APIs express the branching intent. They do not, by themselves, establish that the underlying machine’s memory and disk have also been forked.

Isolation requirements that CoW forking must satisfy to be safe for agent-generated code

Fast branching is useful only within a credible isolation boundary. Standard containers share the host kernel, which is insufficient as the boundary for an agent writing and executing untrusted code. Firecracker microVMs give each workload its own kernel instead. That is a structural property a buyer can examine, unlike a reassuring badge reading “secure sandbox.”

Outbound access for agent-written code should be off by default, with allowlists for package registries, git hosts, and model APIs. Credentials should be brokered at that boundary rather than placed in environment variables readable by agent code. A private kernel does not make readable secrets private.

These requirements also limit what rollback can promise. Restoring a checkpoint returns the sandbox to an earlier internal state, but an email, payment, or external database write remains outside that boundary. Safe resumption therefore requires attention to external actions as well as memory and files.

How the persistence layer connects to the rest of the stack: disks, object storage, and shared workspaces

A paused sandbox preserves a convenient filesystem, but its continued existence should not be the only recovery plan. The disk needs durability independent of running compute. Volume mounts and volume-sync approaches can preserve files without preserving a machine, which is useful when workspace continuity is the goal. Their specific limit is that files do not contain running processes, warm interpreter state, or changes that never reached disk.

The reverse distinction is just as important. A machine snapshot preserves execution, while durable data includes results that must outlive any particular VM. An S3-compatible API on the disk lets CI systems, other agents, and human reviewers read or write artifacts without mounting the sandbox. Outputs can then leave the execution environment without depending on its availability.

Mounting an object-store bucket as a POSIX filesystem lets agents use standard file tools on data in S3, GCS, R2, or Azure Blob without ETL or migration. Access to durable inputs does not preserve the process using them.

Disk forks also have value without VM forks. A data-exploration agent can branch storage for an experimental transformation without spawning a full new microVM or destroying the original dataset. Fast disk checkpoints keep storage from becoming the bottleneck beneath a sub-second machine fork. Shared workspaces let agents or sessions mount the same disk so they can use the context found there without copying or serializing it.

How current sandbox platforms implement CoW forking and persistent disks

Archil is a strong starting option when the requirement combines persistent Firecracker execution with durable, forkable disks. Its model saves the setup that ephemeral containers lose, while disk branching lets experiments start from a prepared environment. Preserving setup and branching experiments are distinct benefits. Its full-machine snapshot model provides the foundation for resuming execution.

The supplied details do not establish Archil’s default egress policy, credential-brokering model, measured fork latency, or production tenure. Those remain questions for evaluation. Durable disks and a named hypervisor are useful evidence, but neither substitutes for documented network and secret-handling boundaries.

PandaStack provides concrete Firecracker restore measurements and describes preserving the execution environment through snapshots. Its timing distinguishes the low-level restore operation from end-to-end creation, which makes the numbers more useful than a single undifferentiated latency claim. Those measurements do not show how fast cross-node forks are. Nor do they cover all the storage, egress, or credential details needed to compare the platforms in full.

OpenDsec documents memory-inclusive forks and direct snapshot transfer between edge nodes for cross-node creation. Its numpy example shows why memory scope changes the usefulness of a fork. The transfer path also explains why cross-node work differs from local sharing. These details support evaluation of fork mechanics, but they do not establish an egress policy or independently durable disk guarantees.

A platform may demonstrate fast restoration without documenting independent disk durability, or preserve files without preserving execution. Each implementation needs evaluation against the obligations it actually covers. A benchmark is evidence about a measured path.

What to look for when evaluating CoW forking infrastructure for your agent workload

For a team choosing infrastructure, the first test is whether the isolation claim can be checked. Ask for the named hypervisor, default egress policy, and credential model. “Isolated sandbox” alone is not enough evidence. The answers should say whether workloads share a host kernel, whether outbound access is closed at the start, and whether agent code can read secrets.

Next, test persistence against termination. If the sandbox is killed or evicted, does its work survive independently? Then establish what a fork includes and measure latency against the actual workload, distinguishing same-node sharing from cross-node transfer. A filesystem-only fork is useful, but it cannot restore running processes or warm interpreter state.

Ask how long the underlying infrastructure has handled production workloads. Fork and snapshot paths exercise unusual microVM code paths. Storage access also belongs in that assessment, including whether CI, other agents, and reviewers can reach artifacts without mounting the sandbox.

Finally, check how rollback handles actions outside the machine. Always-On Agents: A Survey of Persistent Memory, State, and Governance in LLM Agents treats governance and external-action tracking as distinct from execution-state persistence. The harness must reconcile external actions before resuming after a restore, because internal state can move backward while the outside world does not. A restored agent must not mistake an old checkpoint for permission to send the same message or make the same payment again.