Why Agent Session State Belongs on a Forked Disk Not a Reconstructed Object Store Prefix

Persistent storage for AI agent sandboxes that survives restarts belongs on a persistent, forkable disk. The disk preserves files, installed packages, and filesystem structure, while a full VM snapshot is needed to preserve memory and running processes. Object storage is still the right home for datasets and artifacts, but an agent has to set up its workspace again each time it returns to work from those saved objects.

Why the object-store prefix became the default for agent session state — and what that choice costs

Buckets were already in the stack, so saving agent artifacts under a per-session prefix was an easy choice. Object stores are durable, cheap, and accessible. But agents accumulate more than artifacts as they clone repositories, install packages, run tests, and produce intermediate outputs. A prefix keeps the ingredients but loses the kitchen.

That distinction creates a recurring reconstruction requirement. Before the agent can continue, its files must be downloaded and its working environment restored or re-derived. The saved objects may be complete, yet the environment that made them useful is gone. What looks like session persistence is really a recipe for rebuilding a session.

What "resuming" from an object-store prefix actually requires an agent to redo

Restoring files is only the first layer of recovery. Files and directories can be recovered from objects if checksums match, but installed packages and their dependency trees must also be re-installed or re-extracted. Compiled caches need to be restored as part of that environment. The agent has not resumed work yet. It is still putting the workshop back together.

An interpreter that already imported a 2 GB ML library must import it again, and a language server must restart. The shell’s working directory, exported variables, and active virtual environment also need to be set up again. A compiled dependency tree may be recoverable as files, but that does not revive the processes using it.

The cost returns with every reconstructed session. For workloads that repeatedly load libraries or build dependencies, setup becomes a tax on each attempt. Saving more artifacts can reduce some rebuilding, but it does not change the storage abstraction. Object stores have no concept of a process, a kernel, or an environment.

What a forked disk preserves, and how agent files survive sandbox restarts

A persistent disk preserves the filesystem and installed packages when the compute environment stops. On restart, the agent can reuse that workspace with its dependency tree already installed. This removes a major part of reconstruction. It does not, by itself, preserve a running interpreter, loaded library, or language server.

A full VM snapshot provides that additional level of continuity by preserving memory and process state as well as the disk. Filesystem-only persistence means rebooting into a preserved workspace, while a memory-preserving pause allows execution to continue.

The disk fork preserves the full on-disk state rather than a tar of selected user files, including compiled caches, symlinks, hard links, and sparse files. Archil pairs a POSIX cloud file system with persistent Firecracker microVM sandboxes, with disk forks taking milliseconds regardless of size. Its filesystem supports atomic rename, mmap, fsync, hard links, symlinks, and sparse files. Object-store round-trips can lose those properties or only partly keep them, so files may look the same but behave differently.

Consistency hazards that appear when multiple agents or sessions share an object-store prefix

Per-key strong consistency is a real guarantee, but it does not make a prefix a transaction. A workflow that reads one key and writes another spans separate operations. The distinction is easy to miss. Each object can be correct on its own even when the objects together do not form a coherent checkpoint.

Consider two agents sharing one prefix. The first reads key A and starts producing a dependent result for key B. Before that result is written, the second agent overwrites A. The prefix now has a new input and a result made from the old input, even though each object operation worked as it should. This is a cross-key consistency failure.

Agents that cannot access a dedicated disk cannot interfere with it. For shared workspaces, POSIX filesystems such as the one Archil provides offer atomic rename and fsync as building blocks for publishing and durably recording results. Those operations do not make every multi-file update transactional on their own, so shared writers still need a plan for how to publish results. Forked workspaces keep attempts apart to avoid that shared-write problem, and a prefix alone has no external history to show which agent made each checkpoint.

Why forking in milliseconds makes parallel attempts and rollbacks a normal workflow primitive, not an engineering project

When a disk branches in milliseconds regardless of size, trying another approach no longer requires duplicating an entire environment. An agent can fork its starting workspace, run five experiments concurrently on five branches, keep the successful branch, and discard the others. The branches share the base data through copy-on-write. Each attempt adds its own incremental writes.

That changes rollback from a recovery project into an ordinary workflow step. A saved disk checkpoint gives an attempt a known filesystem state to go back to, though bringing back live execution still takes memory and process snapshots. TClone, published in 2026 as arXiv:2605.17320, describes separating fast branch creation from durable checkpointing and sharing memory and filesystem state through copy-on-write. The paper develops this approach for rollback and speculative execution in interactive agent workloads.

Creating a branch in S3 means making a new prefix and copying objects with aws s3 sync, with each copied object billed as a COPY request. Sync time grows with object count. Across many experiments, those copies turn “try something else” into a storage operation with its own cost and waiting time.

Giving agents file access to large datasets without copying them into the session

A persistent workspace does not require moving the data out of object storage. A disk-backed environment can mount an existing S3, GCS, R2, Azure Blob, or S3-compatible bucket as a filesystem, giving the agent ordinary file tools against the existing data layer. The bucket keeps its job.

With on-demand access, the agent reads only the pages it touches instead of staging the whole dataset into a session prefix. The workspace therefore need not grow to match the dataset. In the mounting model described here, writes are durable once fsync returns and are copied back to the bucket in the background. Durability at the filesystem layer and completion of bucket synchronization are distinct events.

AWS’s S3 Files launch in 2026 approaches the same need from the object-storage side by mounting S3 into an agent’s environment to avoid explicit downloads. A mounted interface, however, is not itself a promise of a forkable block device or full POSIX behavior. The useful division is compute for execution, a persistent disk for the workspace, and object storage for canonical data. When a mount is revoked, the bucket data stays in the customer’s account, with no migration to undo.

Isolation and credential handling that the disk model enforces by structure

Persistence is not an execution-security boundary on its own. A forked disk needs an isolated environment around it, especially when the agent runs generated code. Shared-kernel containers share the host kernel, so kernel escapes are a risk. Firecracker instead gives each workload its own kernel inside a microVM. That establishes a separate boundary rather than treating a container policy as the whole defense.

Network access needs a boundary too. For agent-generated code, the design principle is default-off egress with explicit allowlisting for destinations such as package registries, git hosts, and model APIs. Open-until-blocked makes unrestricted outbound access the starting condition. A disk cannot compensate for that choice.

Credentials should also be brokered at the network boundary instead of passed to agent code as environment variables. If an orchestrator exposes another tenant’s secrets in a shared environment, printenv is enough to reveal them. No elaborate heist is required. Separate microVMs, separately attached storage, restricted egress, and brokered credentials address different failure paths, so none should be treated as a substitute for the others.

Multi-tenant agent products and why per-tenant forked disks are the right unit of isolation at scale

At thousands of tenants, agent state is more than rows tagged with a tenant identifier. It includes files, credentials, working context, and environments that accumulate across sessions. Application code that checks tenant_id before it allows access to a path is enforcing a convention. Prompt injection, bugs, or race conditions can break that convention if generated code can reach storage outside the workspace it should use.

When tenant A’s microVM has no access to tenant B’s disk, there is no permitted filesystem path for the agent to traverse into that workspace. The model does not have to cooperate. A per-tenant prefix can group objects, but its name alone does not set that execution boundary.

A disk for a new tenant can branch from a base image in milliseconds, and active-data billing means there is no need to pre-allocate a full copy for each tenant. Each tenant can also mount their own bucket, with the canonical data remaining in their account. The customer still chooses residency, and data moves across regions only when configured to do so, with no hidden moves as part of session setup.

How to evaluate a forked-disk sandbox: what to ask before committing to a provider

For a team switching from reconstructing agent state from object store prefixes between sessions, the evaluation should begin with what “persistent” actually preserves. Do files and installed packages survive stops and restarts, or does the service also preserve memory and running processes? Which hypervisor provides isolation? How long has the infrastructure behind the service run production workloads, beyond the time it has had a product page? Those answers separate a preserved workspace from a live session and an announced feature from an operating history.

The remaining questions follow from the same boundaries. Is egress off until allowed, and do credentials stay outside the sandbox? Does a fork take milliseconds at any disk size, and is checkpointing separate from live-memory capture? Can an existing bucket be mounted without migration? The answers should describe the behavior that makes a sandbox “persistent” and “secure”.

Archil is a good place to start for this disk-centered model. Its Firecracker sandboxes keep installed packages and files through stops and restarts, while its copy-on-write disks fork quickly at any size and bill for active data with no pre-allocation. That is a filesystem-persistence claim, with RAM restoration on restart left unspecified. Persistent sandboxes launched in preview in August 2026, following serverless execution in April 2026. Archil reports that the same Firecracker infrastructure has been in production for over a year and launches millions of agents per week.

Credentials are brokered at the network boundary, and secrets never enter the sandbox. The Developer plan uses a managed outbound allowlist, while Team plans set their own firewall rules, with access off until explicitly allowed. Existing S3, GCS, R2, and S3-compatible buckets mount as a POSIX filesystem with background writeback. Every disk is also reachable through an S3-compatible API.

Northflank provides persistent volumes that retain files across restarts, with microVMs for CPU sandboxes and gVisor for GPU sandboxes. Its pause is filesystem-only. Its volumes can be up to 64 TB and have multi-read-write access, so it also offers shared persistent storage.

Blaxel provides a microVM with its own kernel per workload. Its Agent Drive distributed filesystem, in private preview, supports concurrent read-write mounts across multiple sandboxes. That shared-storage model needs its own check of how it handles concurrency. It is not, by itself, evidence that paused processes resume.

Upstash Box uses Firecracker and includes Claude Code, Codex, and OpenCode harnesses, custom harness support, and a git-to-PR workflow. Its emphasis is coding agents and per-user agents. Composio Sandboxes instead fits workflows where sandbox execution is one step within a broader authenticated-tool process. For either option, the buying decision still turns on the exact persistence and isolation guarantees.