Vercel Sandbox Drives beta keeps agent workspaces beyond disposable VMs

Vercel published Sandbox Drives in private beta on June 5, 2026. The changelog is short: create a drive, mount it at a chosen path when a new sandbox starts, and keep the drive after the sandbox stops. For AI agent infrastructure, though, that small storage primitive changes the runtime boundary. The Firecracker microVM can remain disposable, while the repository, dependencies, build output, and task artifacts can live on a separate lifecycle.

Vercel's Sandbox documentation describes the product as an ephemeral compute primitive for safely running untrusted code, user-generated code, and AI agent output. Each sandbox runs in a Firecracker microVM with its own filesystem and network. That isolation is the right default for coding agents, UI builders, and code playgrounds. User-provided or model-generated code should not execute in the same process or filesystem as a production application.

The operational cost is that isolation resets useful state. When an agent starts from a clean sandbox every time, it may clone the same repository, install the same package tree, download the same browser dependencies, recreate the same test fixtures, and rebuild the same caches. That overhead can be acceptable for a short one-off command. It becomes expensive when an agent opens a monorepo, runs several test suites, starts a preview server, inspects logs, patches code, and repeats the loop.

The API shape in Vercel's announcement is deliberately simple. A developer calls Drive.getOrCreate({ name: "agent-workspace" }), then passes a mounts map into Sandbox.create(). In the example, the drive appears at /workspace with read-write mode. Vercel summarizes the use cases as preserving agent workspaces across disposable sandboxes, keeping cloned repositories, dependencies, and build outputs, and separating sandbox lifecycle from data lifecycle.

import { Drive, Sandbox } from '@vercel/sandbox';

const drive = await Drive.getOrCreate({
  name: 'agent-workspace',
});

const sandbox = await Sandbox.create({
  mounts: {
    '/workspace': {
      drive: drive.name,
      mode: 'read-write',
    },
  },
});

That snippet is closer to an agent runtime contract than to a generic storage feature. The sandbox is the task execution boundary. The drive is the workspace boundary. Human developers already understand that distinction because their local working directory outlives a terminal session. AI agents need the same continuity, but their workspace should not automatically share the lifetime or trust boundary of the VM that executes untrusted code.

Vercel Sandbox documentation already includes snapshotting. Snapshots preserve sandbox state so setup work such as dependency installation can be skipped in later runs. Drives address a related problem at a different unit. A snapshot is closer to reusing an image or filesystem state for the sandbox itself. A drive is named storage attached when a sandbox starts. Agent product teams can combine the two: use snapshots for the base environment and drives for repository workspaces, generated files, and task artifacts.

The system specification matters for operators. Vercel says Sandbox runs on Amazon Linux 2023 and supports node24, node22, and python3.13, with node24 as the default runtime. The sandbox user is vercel-sandbox, has sudo access, and starts in /vercel/sandbox. That fits many JavaScript, Python, web app builder, and agent workloads, but it does not mean every native dependency or browser tool is already installed. Teams still have to decide which setup belongs in a snapshot, which cache belongs on a drive, and which generated state should be discarded after a task.

Authentication also sits inside the Vercel project boundary. The documentation recommends Vercel OIDC tokens. For local development, it points developers to vercel link and vercel env pull to obtain a development token. In Vercel production, authentication is handled automatically. Non-Vercel CI/CD environments can use access tokens. Because a drive can keep an agent workspace alive after a sandbox exits, token scope, project boundary, and team policy become as important as sandbox creation permission.

The market context is that agent runtime competition is moving from model calls to execution surfaces. Google Gemini API Managed Agents emphasizes Google-hosted isolated Linux sandboxes. Microsoft MXC documents OS-specific containment backends. CoreWeave and Modal position sandboxes as primitives for reinforcement learning, evaluation, and code execution. Vercel is bundling web deployment, AI SDK, AI Gateway, and Sandbox into one developer surface. Drives answer a narrower but practical question inside that bundle: can an agent keep a real repository workspace across execution windows?

OpenAI's Agents SDK documentation shows how these runtime choices are becoming pluggable. VercelSandboxClient is documented under @openai/agents-extensions/sandbox/vercel with @vercel/sandbox as a peer dependency. The same sandbox client table includes E2B, Modal, Runloop, and Cloudflare. If an agent framework can swap sandbox providers, the provider race shifts beyond isolation alone. Startup time, mount strategy, persistent workspaces, log access, network policy, quotas, and pricing all become product differentiators.

For development teams, the immediate benefit is reduced restart cost. If a drive keeps the repository clone and package installation, a new sandbox can attach the same workspace instead of reconstructing it. That matters when a model is iterating through failing tests, browser checks, and build logs. It also helps long-running work split across execution windows. If a sandbox times out or fails, the VM can be thrown away without losing the working tree and artifacts that explain what happened.

Artifact persistence can improve agent quality, not only speed. A useful coding agent often relies on the previous failure: a test report, screenshot, build output, lint log, or generated file. If those artifacts vanish whenever the sandbox exits, the next run has to reconstruct evidence or reason from a text summary. A drive gives the agent a more stable substrate for inspect, patch, run, and inspect again.

The beta constraints should shape architecture decisions. Vercel says that during private beta, a drive can be mounted read-write by only one sandbox at a time. Parallel agent sessions that modify the same workspace will hit that limit. A workflow where one agent writes a database migration while another edits UI code needs a lock strategy, branch-level workspace separation, read-only mounts, artifact export, or a decision to give each agent its own drive.

Vercel also says Sandbox Drives should not be used for production data during private beta. That warning is not just a narrow feature limitation. Agent workspaces can contain repositories, sample .env files, generated code, logs, dependency caches, and test data. Mounting customer PII or production database dumps would force teams to audit sandbox isolation, storage retention, credential flow, and cleanup together. The safer beta evaluation path is synthetic fixtures, open-source repositories, or internal code paths that do not contain sensitive data.

Cost and quota behavior still need user-side validation. The changelog emphasizes preserving dependencies and build outputs, but real operating cost depends on storage size, retention policy, cleanup automation, quota visibility, and team-level reporting. Keeping node_modules, Playwright caches, compiled assets, and generated artifacts can cut startup latency while growing storage quickly. Product teams need naming and lifecycle rules: per repository, per branch, per task, per user, or per agent session.

Security teams should treat drives as a different boundary from sandbox escape prevention. Firecracker isolation addresses process and kernel boundaries. Drives introduce data persistence and reuse boundaries. If a malicious dependency or generated file lands in the workspace, the next sandbox that mounts the drive may inherit that state. Workspace reuse therefore needs dependency integrity checks, lockfile review, cache poisoning defenses, post-task cleanup, and rules for which files can survive between tasks.

That risk looks familiar from CI cache poisoning and package lifecycle script incidents. Caches make systems faster by reusing state, but reused state also carries trust decisions forward. AI agent workspaces have the same tradeoff. If an agent-created file becomes the next agent's assumed baseline, convenience and risk move together. Drives give continuity; operators decide which continuity is acceptable.

The feature also connects directly to AI app builders such as v0. In February 2026, a Vercel Community thread asked how v0's sandbox-based runtime connects to existing GitHub repositories and Vercel projects. That is not merely an import UX question. An agent that works on an existing codebase needs repeatable access to repository state, environment configuration, preview builds, branch output, and previous artifacts. Drives can become one primitive underneath that experience.

The announcement is still early. At the time the Korean article was researched, large independent Hacker News or Reddit discussions focused specifically on Drives for Vercel Sandbox were hard to find. That weak community signal likely reflects the private beta, the short changelog, and limited public experience with limits or pricing. Teams evaluating the feature should test their own workload instead of stopping at the official example: a 1GB repository, a 10-minute dependency install, Playwright cache reuse, and parallel agent sessions will reveal more than a toy script.

Compared with other providers, Vercel's differentiation is the proximity between web deployment and agent runtime. GitHub Copilot's cloud agent fits issue, pull request, worktree, and review flows. E2B and Modal focus more directly on sandbox primitives and execution APIs. Cloudflare connects Workers, Durable Objects, browser automation, and edge networking into an agent infrastructure story. Vercel puts Next.js, deployment previews, v0, AI SDK, AI Gateway, and Sandbox in the same developer workflow. Drives handle a specific missing piece in that workflow: whether the generated app and working tree survive until the next prompt.

Adoption should start with an operating checklist rather than a polished demo. Decide what class of data may enter a drive. Check whether the one-sandbox read-write limit matches the team workflow. Define drive cleanup and quota alerts. Rerun tests and dependency verification before trusting artifacts after a restart. If an OpenAI Agents SDK client or an internal agent harness uses Vercel Sandbox, document the mount path and credential handoff explicitly.

The short changelog code sample is therefore more like an operating contract than a product preview. Drive.getOrCreate, mounts, and mode: 'read-write' expose the workspace name, the connection point, and the concurrent write policy.

The real news is not that Vercel added one more storage feature. It is that AI agents increasingly need compute and workspace to be separate runtime units. Disposable microVMs provide isolation. Persistent drives provide continuity and reduce repeated setup work. Treating those two concerns as the same thing produces agent systems that are either slow, risky, or both. Vercel Sandbox Drives is still a private beta, but it makes the next agent infrastructure boundary easier to see.

Sources

• Vercel Changelog, Drives for Vercel Sandbox in Private Beta.
• Vercel Docs, Vercel Sandbox.
• Vercel Docs, Sandbox SDK Reference.
• OpenAI Agents SDK, Sandbox clients.