How to Run AI Coding Agents in Isolated Sandboxes

Start by separating the agent loop from the execution environment

The model or agent loop decides what to do next. The execution environment is where those decisions become filesystem changes, shell commands, package installs, tests, browser actions, and calls to other systems. Keeping those responsibilities separate gives the application a place to enforce controls outside model-generated instructions.

That separation is visible in the new Cursor and Vercel integration. Cursor manages the agent harness and inference loop, while Vercel Sandbox supplies the machine where repository and command execution happens. The control plane sits around the worker instead of living inside the prompt.

A production design does not have to use those exact products, but it should preserve the boundary. The agent can request an action. Infrastructure decides which environment receives it, which identity is attached, which destinations are reachable, how long the worker may run, and what happens when the task finishes.

Give every run a clear isolation boundary

A sandbox limits the blast radius of code the agent did not fully understand before executing. Vercel describes each Sandbox as an isolated Firecracker microVM with its own filesystem, network, and process space. Cursor likewise documents per-agent VM isolation for its hosted Cloud Agents.

Isolation matters because repositories are not passive text. A package install can execute lifecycle scripts. A test suite can start subprocesses or connect to services. A browser test can submit forms. A generated script can consume CPU, write large files, or call an external endpoint. The safest default is to assume that code execution deserves its own boundary even when the repository itself is trusted.

The sandbox does not solve every risk by itself. If the worker receives a production database credential and unrestricted outbound network access, strong VM isolation still leaves the agent with powerful capabilities inside that VM. Infrastructure controls have to work together.

Short-lived credentials should follow the user and task

Coding agents often need more than repository access. Tests may call a staging API, read from object storage, connect to a cloud account, or query a development database. Giving every agent the same long-lived secret is simple, but it makes the execution boundary much weaker.

The September 3 Vercel architecture specifically calls out short-lived, user-scoped credentials inside each Sandbox. Cursor's current Cloud Agent documentation also supports OIDC tokens so an agent can obtain temporary identity without storing long-lived cloud keys in the environment. Its repository access model is designed so an agent inherits the triggering user's repository permissions rather than expanding them.

The design principle is broader than OIDC. Credentials should answer four questions before they enter the worker: who started this task, what resource does the task need, what actions are allowed, and when should the authority expire? If the answer is simply "everything this team can access," the credential scope is too broad for an autonomous executor.

Retries belong in the control plane, not inside an endless agent loop

A long-running agent task can fail before the model produces a useful result. The worker may fail to start, repository cloning may fail, dependency installation may time out, a package registry may be unavailable, tests may fail, the model may stop, or the worker may reach its execution limit.

Vercel's reference architecture puts durable retries around the sandbox worker. That is the right direction because the product needs to know which stage failed and whether repeating that stage is safe. A retry should be a state transition owned by orchestration, not an instruction to "try everything again" without context.

This becomes especially important when the run can create side effects outside the sandbox. Opening a pull request, pushing a branch, applying a migration, posting a comment, or triggering a deployment should not happen twice because an infrastructure retry replayed an earlier step.

Make the task idempotent before you make the worker retryable

A retryable worker is only useful when the product can distinguish repeatable work from consequential work. Cloning the same repository into a fresh sandbox is normally easy to repeat. Creating a second pull request or running a database migration may not be.

Give each agent task a stable job ID and attach idempotency to external actions. If a run has already pushed agent/task-1842, a replacement worker should be able to discover that state instead of blindly creating another branch. If the product needs to post a review artifact, record whether that artifact already exists before the retry begins.

The same principle applies to approvals. A worker can prepare a deployment or migration, but the authorization to perform that action should remain outside the sandbox when the consequence is high. Isolation limits execution. Approval boundaries limit what an automated run can commit to durable systems.

A sandbox needs an explicit end

Short-lived execution is useful only when the lifecycle is actually closed. Vercel Sandbox has a default session timeout, and its documentation recommends stopping a sandbox promptly instead of waiting for the timeout to clean up idle resources.

The application should therefore treat cleanup as part of the task contract. A success path stops the worker after exporting its result. A failure path still stops it after capturing diagnostics. A cancellation path should revoke or let temporary credentials expire and prevent new commands from entering the worker.

A minimal lifecycle wrapper can make that rule visible in code:

1import { Sandbox } from "@vercel/sandbox";2 3type CommandResult = {4exitCode: number;5stdout: string;6stderr: string;7};8 9export async function runIsolatedCommand(): Promise<CommandResult> {10const sandbox = await Sandbox.create({11  persistent: false,12  timeout: 10 * 60 * 1000,13});14 15try {16const result = await sandbox.runCommand("npm", ["test"]);17 18  return {19    exitCode: result.exitCode,20    stdout: await result.stdout(),21    stderr: await result.stderr(),22  };23 24} finally {25await sandbox.stop();26}27}

Decide what is allowed to survive the run

Not every agent task should start from an empty machine, and not every task should preserve its entire workspace. The useful distinction is between execution state and durable output.

Execution state includes cloned repositories, installed packages, caches, temporary credentials, local logs, and processes that only exist to complete the run. Durable output is the result the product intentionally wants to keep: a commit, patch, test report, screenshot, build artifact, review summary, or task audit record.

Persistent sandboxes and snapshots can be useful for large repositories or follow-up sessions, but persistence changes the threat and cleanup model. Old files, cached credentials, build outputs, and environment assumptions can survive into a later run. Use persistence because the product needs continuity, not because cleanup was omitted.

When should execution stay inside your own perimeter?

Hosted agent sandboxes are convenient when the repository and required services can safely run in that environment. Some teams have a different boundary: policy may require code execution to stay on company-managed infrastructure, a critical service may be unreachable from the hosted environment, or the task may require special hardware or persistent local storage.

Cursor's current runtime guidance uses those conditions to separate its hosted Cloud Agents from Self-Hosted Machines. The broader decision is useful for any agent platform. Choose the execution location from policy and dependency constraints, not from a general preference for "more control."

A self-hosted worker also transfers more operational responsibility back to the team. Host patching, worker updates, VM resets, capacity, secret distribution, network access, monitoring, and incident response become part of the system you own. The location may satisfy a perimeter requirement while increasing the reliability work around the agent fleet.

Production checklist for an AI coding-agent sandbox

The execution layer is ready when the team can explain both the happy path and the failure path without relying on the model to remember a safety rule. The product should know which identity started the task, where the code ran, which resources were reachable, what was changed, what was verified, and how the worker ended.

Use the checklist below as an architecture review rather than a provider-specific requirement.

The durable lesson is the boundary around the agent

The September 3 Cursor and Vercel integration is one implementation of a pattern that will matter across coding-agent products: autonomous code execution needs an infrastructure contract around it.

A useful agent needs enough freedom to install, run, test, and inspect. A dependable product keeps that freedom inside an isolated worker, gives the worker temporary and narrow authority, treats retries as explicit job states, preserves only intended outputs, and closes the execution environment when the work is over.

That design does not make every generated command safe. It makes the consequence of a bad command easier to contain, observe, and recover from. As coding agents gain more ability to act, those boundaries become part of the product architecture rather than an infrastructure detail added later.