Persist AI Agent Files with Drives

Mount a Vercel Drive so an AI agent's files persist between sandboxes.

Introduction

30 Second Summary

Temporary workspaces are handy until you need a note from yesterday. When the workspace closes, the files inside usually disappear.

In this project, you will build a Node.js script that mounts a Vercel Sandbox Drive at /data for an AI agent. The script proves the same file survives after one sandbox stops and another starts.

What You'll Build

You'll watch a fresh sandbox print the notes that an earlier sandbox saved before shutting down.

By the end of this project, you'll have:

  • A persistent agent workspace that saves notes.txt in /data for the next sandbox run.
  • A single-writer test that reveals the error produced by a second read-write mount.
  • A read-only sharing demo where two sandboxes can read the same snapshot at once.
  • An optional Secret Mission: challenge to push your persistence skills further.

Are there any prerequisites?

You'll need a Vercel Hobby account.

You'll also need Node.js plus a Vercel access token for the Sandbox SDK.

Prepare Your Node Environment

Every later proof depends on a local script that can create a Vercel Sandbox. Missing runtime or authentication credentials would stop the experiment before you test persistence.

Node.js runs the script on your computer. The Vercel Sandbox SDK connects that script to your Vercel project.

In this step, get ready to:
  • Install Node.js version 22 or higher.
  • Prepare a local Node project with the Vercel Sandbox SDK installed.
  • Link the local folder to Vercel for authentication.
Check your Node.js version

The Sandbox SDK requires Node.js version 22 or higher. The version check tells you whether your current runtime is ready.

  • Press Cmd+Space on macOS or Windows+S on Windows to open system search.
  • Enter Terminal on macOS or Windows Terminal on Windows.
  • Press Enter to launch the terminal.
  • Check your installed Node.js version by running this command:
node --version

What does this check?

The node --version command prints the Node.js version available in this terminal. The first number determines which outcome below matches your setup.

✔️ I see version 22 or higher

Your Node.js runtime meets the Sandbox SDK requirement. You can use this terminal for the rest of the setup.

ⓧ I see an older version

Your current Node.js installation is below the required version. Installing a supported LTS release gives the SDK the runtime it expects.

  • Visit the official Node.js download page.
  • Choose an LTS release numbered 22 or higher for your operating system.
  • Run the downloaded installer.
  • Accept the default installation options.
  • Close every terminal window after the installation completes.
  • Use the system search steps above to launch a fresh terminal.
  • Confirm the updated version by running this command:
node --version

What should this show?

The command reads the version from your fresh terminal session. The new output should meet the 22 minimum.

ⓧ Command not found

Your terminal cannot find a Node.js installation. The official installer adds Node.js plus npm to your computer.

  • Visit the official Node.js download page.
  • Choose an LTS release numbered 22 or higher for your operating system.
  • Run the downloaded installer.
  • Accept the default installation options.
  • Close every terminal window after the installation completes.
  • Use the system search steps above to launch a fresh terminal.
  • Confirm Node.js is available by running this command:
node --version

What should this show?

The command now asks the installed runtime for its version. A version number that meets the 22 minimum confirms Node.js is available.

Still seeing the old Node.js version?

  • Close every terminal window before opening a fresh one.
  • Restart your computer if the fresh terminal still uses the older installation.
  • Check that you downloaded an LTS release numbered 22 or higher.
  • Help me fix my Node.js version check.
Create the local project

A Node project records its dependencies in package.json. Keeping this project on your Desktop makes its files easy to find during the walkthrough.

  • Move to your Desktop in the terminal by running this command:
cd ~/Desktop

What does this command do?

The cd command changes the terminal's current location. New project files now land on your Desktop.

  • Create the my-sandbox-app folder by running this command:
mkdir my-sandbox-app

What does this command do?

The mkdir command creates a folder named my-sandbox-app on your Desktop. This folder holds the local project.

  • Move the terminal into my-sandbox-app by running this command:
cd my-sandbox-app

What does this command do?

This changes the terminal's current location to my-sandbox-app. Your terminal prompt should now end with the project folder name.

  • Initialize the Node project by running this command:
npm init --yes

What does this command create?

The command creates package.json with standard project values. The terminal prints the generated file contents as a visible confirmation.

  • Install the Vercel CLI by running this command:
npm i -g vercel

Why install the Vercel CLI?

The Vercel CLI links your local folder to a Vercel project. It also downloads the short-lived authentication credential used during local development.

  • Install the Sandbox SDK in my-sandbox-app by running this command:
npm i @vercel/sandbox

What did npm add?

The command adds @vercel/sandbox to the dependency list in package.json. It also creates the local installation files that Node.js uses when your script imports the SDK.

Package installation failing?

  • Confirm that your terminal prompt still ends with my-sandbox-app.
  • Check that your internet connection can reach the npm package registry.
  • Run the Node.js version check again if the terminal reports that npm is unavailable.
  • Help me install the Vercel Sandbox SDK.
Connect the project to Vercel

Local Sandbox requests use an OpenID Connect token tied to a Vercel project. Linking the folder lets Vercel issue that credential for local development.

The link flow is interactive. It may open a browser so you can sign in to Vercel.

Choose the project path

When the link flow asks how to connect this directory, choose Create a new project. The project does not need a deployment for Sandbox authentication.

  • Start the project link flow by running this command:
vercel link

What does this command do?

The command associates my-sandbox-app with a Vercel project. Complete the browser sign-in if the CLI requests authentication.

The next command writes a short-lived credential to .env.local. Keep this file private because it contains VERCEL_OIDC_TOKEN.

  • Pull the local authentication credential by running this command:
vercel env pull

How does local authentication work?

The command downloads a development token into .env.local. The Sandbox SDK reads this credential when your local script sends a request to Vercel.

Authentication setup not completing?

  • Confirm that the terminal is still inside my-sandbox-app.
  • Complete the browser sign-in with the Vercel account that owns the linked project.
  • Pull a fresh token with the command above if authentication stops working after a break.
  • Help me configure Vercel Sandbox authentication.

Before you run the final package check, do you expect npm to find the Sandbox SDK in this project?

  • Verify the installed SDK dependency by running this command:
npm ls @vercel/sandbox

What does this verification prove?

The command reads the current project's dependency tree. It should list @vercel/sandbox with an installed version.

You should see the Sandbox SDK beneath my-sandbox-app. That result confirms the local package installation is ready.

  • Open the Vercel dashboard in your browser.
  • Confirm that my-sandbox-app appears in the project list.

Your linked project is visible in the dashboard. Your local folder now has the runtime, SDK, and authentication path needed for Sandbox requests.

✔️ Awesome, I've got everything!

Your Node environment is ready for the first Drive call. The linked project gives the SDK a secure local authentication path.

ⓧ I'd like to double check the full code

This setup step creates an environment state instead of application code. Your checkpoint should match this exact state:

Node.js installed; local project directory prepared; Vercel Sandbox SDK installed; Vercel authentication configured.

How to read this checkpoint

Your terminal is inside my-sandbox-app. The SDK appears in the dependency tree. The Vercel dashboard also shows the linked project.

That foundation is complete. Next up, you will create the persistent Drive that keeps your agent's files between sandbox runs.

Create the Persistent Drive

A sandbox can disappear as soon as its run ends. Without external storage, an agent loses the files it created during that run.

A Vercel Sandbox Drive lives independently from any single sandbox. In this step, you use Drive.getOrCreate() to prepare that persistent storage.

In this step, get ready to:
  • Create or retrieve a Drive named agent-workspace.
  • Confirm the Drive appears in your Vercel dashboard.
Create the named Drive

A Drive name identifies the same storage across separate sandbox runs. The Drive.getOrCreate() method retrieves the existing Drive when that name is already present.

  • Predict whether the command creates a duplicate when a Drive with the same name already exists.
  • Create or retrieve agent-workspace by running this command in the terminal from earlier:
node --input-type=module -e "import { Drive } from '@vercel/sandbox'; const drive = await Drive.getOrCreate({ name: 'agent-workspace' }); console.log(drive.name);"

What does this command do?

  • The Drive import gives your Node process access to persistent Drive storage.
  • Drive.getOrCreate() looks for the requested name. It creates the Drive only when no matching Drive exists.
  • console.log(drive.name) prints the returned Drive's name as a concrete success signal.

You should see agent-workspace printed in your terminal.

Drive command not completing?

  • Confirm your terminal still points to the local project directory where the Sandbox SDK is installed.
  • Confirm your configured Vercel credentials belong to the project where you want the Drive to live.
  • Check that your Vercel account has access to Sandbox Drives.
  • Help me troubleshoot this Drive creation command.

At this checkpoint, the Drive contains no project notes file.

✔️ Awesome, I've got everything!

Your terminal printed the Drive name. Keep the Drive available for the next step.

ⓧ I'd like to double check the full code

Compare your creation command with this complete command.

node --input-type=module -e "import { Drive } from '@vercel/sandbox'; const drive = await Drive.getOrCreate({ name: 'agent-workspace' }); console.log(drive.name);"

What should this confirm?

The command imports Drive from @vercel/sandbox. It requests the exact Drive name agent-workspace.

Confirm the Drive in Vercel

The terminal proves that the SDK returned the named Drive. The dashboard gives you a second view of the resource attached to your Vercel project.

  • Predict how many entries named agent-workspace you expect to find before checking the dashboard.
  • Return to the Vercel dashboard from earlier.
  • Select the project associated with your configured Sandbox SDK credentials.
  • Use the project's Sandbox area to display its Drives list.
  • Locate agent-workspace in the Drives list.

You should see one Drive named agent-workspace in the project.

That is the storage layer ready. Your future sandbox runs now have a persistent Drive waiting for them.

Drive missing from the dashboard?

  • Refresh the project view after the terminal command completes.
  • Confirm the selected dashboard project matches the project used by your configured SDK credentials.
  • Help me find the Drive in my Vercel project.

Your persistent Drive is ready. Next, you will mount it inside a sandbox so an agent can write files under /data.

Write Notes in a Mounted Sandbox

The agent-workspace Drive now exists in Vercel. It still needs an agent file worth preserving.

In this step, a Vercel Sandbox mounts that Drive at /data. Your script writes a working note through the mounted path.

In this step, get ready to:
  • Start a sandbox with the Drive mounted at /data.
  • Write an agent note to /data/notes.txt.
  • List the mounted directory to confirm the note exists.
Build the mounted sandbox script

A mount exposes persistent storage through a normal directory path. Files written under /data go to the Drive attached there.

  • Create index.mjs inside the local project directory from earlier using your editor's new-file control.
  • Confirm the new file exists by running this command in the terminal from earlier:
ls

You should see index.mjs in the directory listing.

  • Paste this code into index.mjs to mount the Drive at /data.
import { Drive, Sandbox } from '@vercel/sandbox'

// Retrieve the persistent workspace created earlier
const workspace = await Drive.getOrCreate({
  name: 'agent-workspace',
})

// Mount the Drive as writable storage in the first sandbox
const sandbox = await Sandbox.create({
  mounts: { '/data': workspace },
})

// Write an agent note into persistent storage
await sandbox.writeFiles([
  {
    path: '/data/notes.txt',
    content: Buffer.from('Agent working note: keep this file between sandbox runs.\n'),
  },
])

// List the mounted directory to prove the file is visible
const listing = await sandbox.runCommand('ls', ['-la', '/data'])

if (listing.exitCode !== 0) {
  throw new Error(await listing.stderr())
}

// Print the evidence while leaving the sandbox running
console.log(await listing.stdout())
console.log('First sandbox is still running with the Drive mounted at /data.')

What does this code do?

  • Drive.getOrCreate() retrieves the existing agent-workspace Drive for this script.
  • Sandbox.create() starts the first sandbox with the Drive mounted at /data in read-write mode.
  • sandbox.writeFiles() writes the working note directly into the mounted Drive.
  • sandbox.runCommand() runs the directory listing inside the sandbox.
  • The script omits sandbox.stop() so the first sandbox remains available for the next step.
  • Save index.mjs.
Inspect /data from the running script

Before you run the script, which filename do you expect the mounted directory listing to contain?

  • Start the mounted sandbox by running this command in the terminal from earlier:
node index.mjs

The directory listing includes notes.txt. The final line confirms that the first sandbox is still running with the Drive mounted at /data.

You now have your first persistent agent artifact. The running sandbox can see the note through its mounted filesystem.

Note missing from the listing?

  • Confirm that the Sandbox SDK is installed inside the same local project directory as index.mjs.
  • Check that your configured Vercel credentials can access the project containing agent-workspace.
  • Compare the write path with the mounted path. Both must begin with /data.
  • Help me troubleshoot why notes.txt is missing from my mounted Vercel Sandbox Drive.

✔️ Awesome, I've got everything!

Great. Your index.mjs file is saved with the mounted sandbox workflow.

ⓧ I'd like to double check the full code

Compare your index.mjs file with this complete version.

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

// Retrieve the persistent workspace created earlier
const workspace = await Drive.getOrCreate({
  name: 'agent-workspace',
})

// Mount the Drive as writable storage in the first sandbox
const sandbox = await Sandbox.create({
  mounts: { '/data': workspace },
})

// Write an agent note into persistent storage
await sandbox.writeFiles([
  {
    path: '/data/notes.txt',
    content: Buffer.from('Agent working note: keep this file between sandbox runs.\n'),
  },
])

// List the mounted directory to prove the file is visible
const listing = await sandbox.runCommand('ls', ['-la', '/data'])

if (listing.exitCode !== 0) {
  throw new Error(await listing.stderr())
}

// Print the evidence while leaving the sandbox running
console.log(await listing.stdout())
console.log('First sandbox is still running with the Drive mounted at /data.')

Your first sandbox is running with the working note stored on agent-workspace. Next up, you will stop this sandbox before checking whether a new one can recover the same file.

Restore Notes in a New Sandbox

Your first sandbox has written a working note to a mounted Vercel Sandbox Drive. That proves the file exists while the original sandbox is running.

Persistent storage becomes useful when a different sandbox can continue with the same files. A fresh sandbox will mount the same Drive and read the note back.

In this step, get ready to:
  • Stop the first sandbox to release its read-write mount.
  • Mount the same Drive at /data in a second sandbox.
  • Read the persisted /data/notes.txt file from the second sandbox.
Stop the first sandbox

A Drive supports one read-write mount at a time. Stopping the first sandbox releases that mount while leaving the working note on the Drive.

  • Switch back to the script from earlier.
  • Place your cursor directly after the code that listed /data.
  • Add this block to stop the first sandbox:
// Release the Drive before another sandbox mounts it read-write.
await sandbox.stop();
console.log('First sandbox stopped.');

What Does This Code Do?

  • The sandbox.stop() call waits until the first sandbox has fully stopped.
  • Stopping the sandbox detaches the Drive from that running environment.
  • The final message confirms that the stop operation finished before the script continues.
  • Save the script.

Before you run it, consider this: will the Drive remain attached after the sandbox stops.

  • Run the script using the same terminal command from the previous step.

You should see First sandbox stopped. after the earlier file listing. Good work. The original sandbox is now stopped while its note remains stored on the Drive.

First Sandbox Not Stopping?

  • Confirm that sandbox still refers to the first sandbox created earlier in the script.
  • Check that the stop block appears after the code that writes and lists the Drive contents.
  • Use the terminal output to identify any authentication or connection problem.
  • Help me troubleshoot why sandbox.stop() is failing in my Vercel Sandbox script.
Restore the note from the Drive

The Drive has its own lifecycle outside the first sandbox. Mounting the same workspace object gives a second sandbox access to the existing files under /data.

  • Return to the end of the script.
  • Add this block directly below the first sandbox stop block:
// Start a fresh sandbox with the same persistent Drive.
const secondSandbox = await Sandbox.create({
  mounts: { '/data': workspace },
});

// Read the note that the first sandbox stored on the Drive.
const restoredNote = await secondSandbox.fs.readFile('/data/notes.txt', 'utf8');
console.log('Second sandbox status:', secondSandbox.status);
console.log('Restored note:', restoredNote);

How Does the Restore Work?

  • The new Sandbox.create() call starts a separate sandbox with the existing Drive mounted at /data.
  • The secondSandbox.fs.readFile() call reads the persisted note as UTF-8 text.
  • The two log messages expose the second sandbox state and the recovered note in your terminal.
  • Save the script.

Before you run it, consider this: will the note still be present after the sandbox that wrote it has stopped.

  • Run the script using the same terminal command from the previous step.

You should see Second sandbox status: running. The next line should show Restored note: followed by your original working note.

That is the persistence proof. Your note survived the first sandbox and is now available inside a different running sandbox.

Note Not Restored?

  • Check that both sandbox configurations mount workspace at the exact path /data.
  • Check that the read path exactly matches /data/notes.txt.
  • If the Drive is already attached elsewhere, stop the previous test sandbox from the Sandboxes dashboard before rerunning the script.
  • Help me find why the second sandbox cannot read /data/notes.txt from the mounted Drive.

✔️ Awesome, I've got everything!

Your first sandbox is stopped. Your second sandbox is running with agent-workspace mounted read-write at /data.

The terminal shows the original contents of /data/notes.txt from the second sandbox.

ⓧ I'd like to double check the full code

The restore section at the end of your script should match this reference:

// Release the Drive before another sandbox mounts it read-write.
await sandbox.stop();
console.log('First sandbox stopped.');

// Start a fresh sandbox with the same persistent Drive.
const secondSandbox = await Sandbox.create({
  mounts: { '/data': workspace },
});

// Read the note that the first sandbox stored on the Drive.
const restoredNote = await secondSandbox.fs.readFile('/data/notes.txt', 'utf8');
console.log('Second sandbox status:', secondSandbox.status);
console.log('Restored note:', restoredNote);

Your Drive now carries an agent workspace across separate sandbox runs. Next, you will test what happens when another sandbox requests the same read-write mount.

Test Concurrent Write Access

Your recovered note proved that a Vercel Sandbox Drive can preserve an agent's files between sandboxes. A shared workspace also needs clear ownership when something writes to those files.

The second sandbox currently holds a read-write mount at /data. This step tests what happens when another sandbox requests write access to the same Drive.

In this step, get ready to:
  • Keep the current Drive writer active.
  • Attempt another read-write mount of the same Drive.
  • Review how the Drive handles competing writers.
Confirm the experiment conditions

A concurrency test needs the current writer to stay active. Stopping that sandbox would release its mount before the competing request arrives.

  • Return to the local project session from the previous step.
  • Confirm that the second sandbox is still running with agent-workspace mounted at /data.

The second sandbox now provides the active writer that this experiment challenges.

Challenge the active writer

The competing request must use the same Drive object. It must also request another read-write mount at the same path.

Before you trigger the attempt, consider whether another writer starts or the current mount stays protected.

  • Trigger a new Sandbox.create request that mounts the existing Drive object at /data with read-write access.
  • Watch the local project output until the request finishes.

You will see the new sandbox request fail with an exclusivity error. The message shows that only one read-write mount can use the Drive at a time.

You found the single-writer guardrail in action. The second sandbox keeps exclusive write access to agent-workspace.

What Does This Result Prove?

  • The failed request proves that the active read-write mount blocks another writer.
  • The original mount remains attached to the second sandbox at /data.
  • A future writer must wait until the active sandbox releases the Drive.

Did a Second Writer Start?

  • Confirm that the original second sandbox is still running.
  • Confirm that both requests use the Drive returned by Drive.getOrCreate for agent-workspace.
  • Confirm that the competing request asks for read-write access at /data.
  • Help me diagnose my concurrent Drive mount.
  • Leave the second sandbox running after the competing request fails.

The single-writer rule is now proven by a real rejected mount. Next, you will use a read-only snapshot to share the Drive while its writer stays protected.

Share a Read-Only Snapshot

Your failed concurrent mount proved that a Drive protects its single writer. That safeguard keeps two sandboxes from changing the same workspace at once.

A read-only snapshot gives another Vercel Sandbox a point-in-time view of the files. The original sandbox keeps its read-write mount throughout the comparison.

In this step, get ready to:
  • Mount a read-only snapshot of agent-workspace in a third sandbox.
  • Read /data/notes.txt through both active sandboxes.
  • Compare the two outputs to prove simultaneous access.
Mount the read-only snapshot

The snapshot reflects the Drive when it is mounted. Later changes to the Drive stay outside that mounted view.

  • Switch back to the Node.js script from earlier.
  • Add this code at the end of the script:
// Mount a point-in-time view without taking the Drive's write access.
const thirdSandbox = await Sandbox.create({
  mounts: { '/data': workspace.snapshot() },
});

// Read the persisted note through both active mounts.
const [secondNote, thirdNote] = await Promise.all([
  secondSandbox.fs.readFile('/data/notes.txt', 'utf8'),
  thirdSandbox.fs.readFile('/data/notes.txt', 'utf8'),
]);

console.log('Read-write sandbox:', secondNote);
console.log('Read-only snapshot sandbox:', thirdNote);

What does this code do?

  • The workspace.snapshot() call supplies a point-in-time read-only mount configuration for the existing Drive.
  • The third sandbox mounts that snapshot at /data while the second sandbox keeps its read-write mount.
  • The Promise.all() call starts both file reads during the same script execution.
  • The two console.log() labels identify which sandbox produced each result.
  • Save the Node.js script from earlier.

Before you run the script, do you expect the snapshot reader to succeed while the read-write sandbox remains active?

  • Run the script with the same terminal command you used earlier.

You should see two labeled lines. Each line contains your working note from /data/notes.txt.

Snapshot read not working?

  • Confirm the snapshot code appears after the earlier declarations for workspace and secondSandbox.
  • Confirm the earlier write created /data/notes.txt before the first sandbox stopped.
  • Check that the third sandbox starts in the same region as the Drive.
  • Ask for help with the snapshot mount if the third sandbox still cannot read the file: Help me troubleshoot my read-only Vercel Sandbox Drive snapshot.

✔️ Awesome, I've got everything!

Great work. Your read-write sandbox now stays active while a third sandbox reads the same note through a snapshot.

ⓧ I'd like to double check the full code

The snapshot section at the end of your existing script should match this code.

// Mount a point-in-time view without taking the Drive's write access.
const thirdSandbox = await Sandbox.create({
  mounts: { '/data': workspace.snapshot() },
});

// Read the persisted note through both active mounts.
const [secondNote, thirdNote] = await Promise.all([
  secondSandbox.fs.readFile('/data/notes.txt', 'utf8'),
  thirdSandbox.fs.readFile('/data/notes.txt', 'utf8'),
]);

console.log('Read-write sandbox:', secondNote);
console.log('Read-only snapshot sandbox:', thirdNote);
Compare the simultaneous reads

Matching output proves that one sandbox can keep the read-write mount while another reads a stable snapshot. Both sandboxes can access the saved note during the same run.

  • Compare the text after Read-write sandbox: with the text after Read-only snapshot sandbox:.
  • Confirm that both lines contain the working note you saved earlier.

You have cleared the single-writer obstacle. The active writer now coexists with a read-only snapshot reader.

Your Drive now supports one active writer alongside a snapshot reader. You have proved the sharing pattern that lets agent work continue while another sandbox reviews a stable copy.

Secret mission

Design a Safe Drive Handoff Runbook

Turn your persistence experiment into an operations runbook for agent handoffs. Define how one agent keeps write access while reviewers receive consistent snapshots of the workspace.

Clean Up Your Resources

Clean Up Your Resources

Your persisted note uses part of the Vercel Hobby storage allowance while its Vercel Sandbox Drive exists. Decide whether to keep your work active, pause the running sandboxes, or delete the project resources.

Resources you used:

  • The agent-workspace Drive containing the persisted /data/notes.txt file.
  • The second Vercel Sandbox instance holding the Drive's read-write mount at /data.
  • The third sandbox instance holding a read-only snapshot at /data.
  • The local project directory currently open in your terminal or editor.

Keep everything running

No action needed. Choose this if you are actively extending the project or testing more Drive behavior.

  • Leave the second sandbox running with the Drive mounted read-write at /data.
  • Leave the third sandbox running with the read-only snapshot mounted at /data.
  • Keep the agent-workspace Drive available in your Vercel account.
  • Keep the local project directory for future experiments.

Pause - I'll come back to this later

Pause the active sandbox sessions. Your Drive and local project directory remain available for later.

  • Stop the second sandbox with the same stop action you used for the first sandbox.
  • Stop the third sandbox with the same stop action.
  • Confirm that the Vercel dashboard shows no running sandbox instances from this project.
  • Keep the agent-workspace Drive so /data/notes.txt remains available.
  • Keep the local project directory so you can resume with the installed SDK.

You're set for an easy return. The Drive still holds your note without keeping either sandbox active.

Delete - I don't want to use this again

Removing persistent storage can feel final. This option permanently removes the saved note and your local project directory.

  • Stop the second sandbox with the same stop action you used for the first sandbox.
  • Stop the third sandbox with the same stop action.
  • Return to the Vercel dashboard view where agent-workspace appeared earlier.
  • Select the agent-workspace Drive.
  • Use the deletion control on the selected Drive's page.
  • Complete the deletion confirmation requested by the dashboard.
  • Refresh the Drive view to verify that agent-workspace is no longer listed.
  • Close the terminal or editor that has the local project directory open.
  • Delete the local project directory using Finder on macOS or File Explorer on Windows.
  • Empty the Trash on macOS or the Recycle Bin on Windows.

That cleanup leaves no project Drive using your Vercel storage allowance.

Nice Work!

Nice Work!

You did it! You proved that an AI agent's working files can survive across separate sandbox runs with a Vercel Sandbox Drive.

You've learned how to:

  • Create a named Vercel Sandbox Drive with Drive.getOrCreate. You mounted it at /data so a working file remained available after the first sandbox stopped.
  • Prove file persistence by writing /data/notes.txt in one sandbox. You then read the same file from a new sandbox.
  • Test the single-writer rule through a concurrent read-write mount attempt. You also used a read-only snapshot to read the file from two sandboxes at the same time.
  • Completed an optional Secret Mission to push your persistent sandbox storage skills further.

Ready to quiz yourself?