Paseo Runs AI Agents on Vercel Sandbox with Persistent Sessions Between Laptop and Phone

Vercel's changelog recorded an integration that changes how code agents can be used day to day: Paseo, a tool that manages the execution of agents like fx, Codex, Claude Code, OpenCode, and Pi, now has an official plugin to run these sessions inside Vercel Sandbox instead of on the local machine.

The package comes from the GitHub vercel-labs organization, Vercel's lab for experimental projects, which indicates the integration is maintained by the company itself, not by a third party. That matters because Vercel controls both ends: the execution environment (Sandbox) and the routing of model calls (AI Gateway).

What Changes in Practice

Until now, running a local code agent meant tying the session to the machine where it started. Closing the laptop or switching networks broke the flow, and any process in progress (a build, a test, a long refactor) was left orphaned.

With Vercel Sandbox as the execution destination, Paseo decouples the session from the device. The changelog describes the use case directly:

You can now start an agent in Vercel Sandbox from Paseo on your laptop, then connect from your phone to control the same session, even when your laptop is closed.

Vercel Changelog

Stopping the sandbox saves the files and the conversation history, so you can resume later from where you left off. Active processes, however, are interrupted along with the sandbox: there's no background computation running for free while you're not looking.

The Path I'd Follow to Test This

If I were setting up this flow in a typical project, the sequence documented in the changelog is straightforward:

1. Open Paseo and go to Settings → Plugins to enable plugins (disabled by default).
2. Install the official plugin through Paseo itself:

paseo plugin add vercel-labs/paseo-vercel-sandbox

1. Provide the Vercel AI Gateway key once, during the plugin's initial setup.
2. Start a supported agent (Codex, Claude Code, OpenCode, Pi, or fx), choosing Vercel Sandbox as the execution destination.
3. End the session on the laptop when you need to leave, knowing that the state (files and history) stays saved in the stopped sandbox.
4. Reopen Paseo on another device, connect to the same session, and resume the conversation from where it left off.

The point worth paying attention to in step 5 is what the changelog makes explicit: stopping the sandbox isn't just "pausing the screen," it's freezing the state. A build process running in the background, for example, doesn't survive the shutdown: it stops along with everything else, and it needs to be restarted manually upon resuming.

Why the AI Gateway Key Stays Outside the Sandbox

The security piece is treated as a requirement, not as a footnote. The plugin asks for the Vercel AI Gateway key once, during setup, and reuses it for model calls in all subsequent sessions, keeping the key outside the sandbox.

This solves a known problem for anyone who has experimented with autonomous agents in isolated environments: if the API key lives inside the container the agent controls, any command the agent itself executes (or any successful prompt injection) can leak or reuse that credential. By keeping the key on the AI Gateway side, outside the sandbox, the worst-case scenario is the agent losing access to the model, not exposing the credential.

In short: the design clearly separates two trust perimeters. The sandbox is where the agent's code runs and can do whatever it wants with the ephemeral file system; the AI Gateway is where authentication with model providers happens, and this second perimeter never comes into direct contact with the agent's execution environment.

What This Means for Those Who Already Automate Tasks with Agents

For those who use Codex, Claude Code, or OpenCode in the local terminal today, the mental model shift is to treat the agent session as something that lives in the cloud by default, not on the machine. This brings the code agent workflow closer to the CI/CD workflow: you trigger it, monitor it, and can walk away from the process without tying up the laptop.

It also opens an interesting door for teams that review agent work as a group: if the session lives in Vercel Sandbox rather than on a personal machine, it's theoretically possible to think about handoff between people, not just between devices belonging to the same person, although the changelog doesn't explicitly mention this scenario.

An honest caveat: the changelog doesn't provide any latency figures, cost per active sandbox session, or time limit before an idle session is automatically terminated. Anyone putting this into a production flow needs to check the Vercel Sandbox documentation and the Paseo plugin listing linked in the changelog itself before relying on this for critical tasks.

What Remains Open

Vercel's material doesn't detail what happens if the connection drops in the middle of a model call, nor how the plugin handles multiple devices trying to control the same session at the same time. There's also no mention of pricing: running a persistent sandbox has a computation cost that varies according to the Vercel plan, and that doesn't appear in the announcement.

For those who already use Paseo locally, the safest path is to first test with a non-critical task, confirm that the history actually persists when stopping and resuming the sandbox, and only then migrate agent flows that really matter to this remote execution model.