# Run multiple isolated agents in a single Sandbox

Source: [Vercel](https://vercel.com/changelog/run-multiple-isolated-agents-in-a-single-sandbox)  
Feed7 permalink: https://feed7.dev/p/run-multiple-isolated-agents-in-a-single-sandbox-03i3r7u  
Published: 2026-07-30T04:00:00.000Z  
Trust: Official Source (official_source)

## Why Included

Vercel Sandbox can now isolate agents as Linux users while exposing selected files through a shared group directory. This gives multi-agent harnesses a simpler permission boundary.

## Source Summary

The **@vercel/sandbox SDK** now supports multiple Linux users and groups. Each agent gets a **private home directory**; users cannot read, write, or list one another’s files, while a **shared group directory** supports collaboration.

## Practical Implication

Create one user per agent and expose only the workspace they need through a group. This makes coder-reviewer or other multi-agent roles easier to separate without provisioning a sandbox for each role.

## Agent-Ready Context

The **@vercel/sandbox SDK** now supports multiple Linux users and groups. Each agent gets a **private home directory**; users cannot read, write, or list one another’s files, while a **shared group directory** supports collaboration.

Create one user per agent and expose only the workspace they need through a group. This makes coder-reviewer or other multi-agent roles easier to separate without provisioning a sandbox for each role.

The boundary is user and group permissions inside one Sandbox. The material does not claim separate kernels, resource quotas, or protection from vulnerabilities that cross operating-system user boundaries.

## Connected Context

Feed7 judgment across 297 accumulated Signals:

This adds a practical middle ground between sharing one unrestricted workspace and provisioning a sandbox per agent: role separation through Linux users, private homes, and an explicit collaboration directory. It narrows the security claim to filesystem permissions within one OS boundary, so workflow verification, authority, and stronger kernel isolation remain separate concerns.

- [From fork() to Fleet: Designing an Agent Sandbox Cloud — Abhishek Bhardwaj, OpenAI](https://feed7.dev/p/from-fork-to-fleet-designing-an-agent-sandbox-cloud-abhishek-bhardwaj-op-0np9ki3) — The microVM design addresses kernel exposure and fleet-level persistence, whereas this Signal separates agents only through users and groups inside one Sandbox.
- [What Does Done Even Mean? Agents and Paperclip's Liveness Model - Dotta, Paperclip](https://feed7.dev/p/what-does-done-even-mean-agents-and-paperclip-s-liveness-model-dotta-pap-0lx8wfc) — Filesystem separation can enforce role boundaries, but it does not supply the evidence, approval, or ownership model needed to decide when multi-agent work is done.
- [Don't Build Agents You Can't Answer For — Addy Osmani](https://feed7.dev/p/don-t-build-agents-you-can-t-answer-for-addy-osmani-1y9nwej) — Private and shared directories can constrain who handles artifacts, while explainable diffs, tests, logs, and ownership are still required to make those artifacts accountable.

## Context Map

- Layer: infra
- Domains: coding, security
- Topics: sandboxing, multi-agent, agent-reliability

## Uncertainty

- The boundary is user and group permissions inside one Sandbox. The material does not claim separate kernels, resource quotas, or protection from vulnerabilities that cross operating-system user boundaries.

## Agent Instruction

Use this item as source-backed context. Do not invent claims beyond the linked source. If this item conflicts with another source, call out the conflict.
