Open Agents: the coding agent runs outside its sandbox

The agent runs outside the VM instead of inside it

Plenty of coding agent demos put the model loop and the shell in one process, which means that process also owns their lifetime. Open Agents splits the system into three named layers and calls that split the main point of the project.

Web -> Agent workflow -> Sandbox VM

The web app owns auth, sessions, chat and the streaming UI. The agent runs as a durable workflow on Vercel. The sandbox is the execution environment, holding the filesystem, the shell, git, dev servers and preview ports. The decision worth understanding is that the agent does not live in the VM. It runs outside and interacts through tools such as file reads, edits, search and shell commands. Four consequences follow from that one choice: agent execution is not tied to a single request lifecycle, the sandbox lifecycle can hibernate and resume independently, model and provider choices can evolve separately from the sandbox implementation, and the VM stays a plain execution environment instead of turning into the control plane.

Preview ports are fixed at 3000, 5173, 4321 and 8000

A dev server inside the sandbox is only reachable if it listens where the platform already looks. These sandboxes expose ports 3000, 5173, 4321 and 8000, so a framework that defaults somewhere else has to be reconfigured by hand or the preview link stays dead. That is the practical tax of running preview servers inside someone else's VM. Lifetimes are handled explicitly: sandboxes hibernate after inactivity, and a fresh one can start from a configured base snapshot instead of Vercel's standard Sandbox runtime. The snapshot has to be one created in or accessible to your own Vercel scope, which makes the base image an account-level asset rather than a file in the repository. Producing one is a repository task, since the sandbox:snapshot-base script calls node scripts/vercel-refresh-base-snapshot.ts, so refreshing that image does not mean clicking through a dashboard.

Auto-commit, push and pull requests are preferences you enable

Nothing touches your repository unless you ask it to. Auto-commit, push and PR creation after a successful run are described as supported but preference-driven rather than always-on, so the default path leaves the working tree sitting there for you to inspect. Turning them on does not mean pasting a personal access token. Repo access, pushes and pull requests go through a GitHub App, which needs a client id, a client secret, an app id, a private key, an app slug and a webhook secret, and its homepage, callback and setup URLs have to point back at your own domain, the setup URL being a separate path from the callback. One instruction in the walkthrough is easy to skim past: make the app public if you want org installs to work cleanly. A private app is fine for your own account and becomes awkward the moment an organisation installs it.

Ten variables in three groups stand between you and a run

The environment file is the entire configuration surface. Two variables are the minimum runtime: a Postgres connection string and a session signing secret, and Neon provisions the first automatically through the deploy button.

POSTGRES_URL=
BETTER_AUTH_SECRET=

Sign-in through Vercel OAuth adds a pair.

NEXT_PUBLIC_VERCEL_APP_CLIENT_ID=
VERCEL_APP_CLIENT_SECRET=

GitHub repo access, pushes and pull requests need six more.

NEXT_PUBLIC_GITHUB_CLIENT_ID=
GITHUB_CLIENT_SECRET=
GITHUB_APP_ID=
GITHUB_APP_PRIVATE_KEY=
NEXT_PUBLIC_GITHUB_APP_SLUG=
GITHUB_WEBHOOK_SECRET=

Everything else is optional and degrades quietly. REDIS_URL and KV_URL cache skills metadata and fall back to in-memory when they are not configured. OPEN_AGENTS_RESOURCE_PROFILE set to hobby switches chat and sandbox resources to Hobby-compatible defaults. ELEVENLABS_API_KEY turns on voice transcription. VERCEL_PROJECT_PRODUCTION_URL and its NEXT_PUBLIC twin give a canonical production URL for metadata and callbacks, and VERCEL_SANDBOX_BASE_SNAPSHOT_ID decides what a fresh sandbox boots from.

A local start is corepack, pnpm and a copied env file

Running it on a laptop is the shortest path in the document, and it assumes corepack and pnpm rather than a global install.

corepack enable
pnpm install

Then copy the example file and fill in the required values.

cp apps/web/.env.example apps/web/.env

Start the web app with:

pnpm web

That script resolves to `pnpm --dir apps/web dev`, so it starts the dev server inside apps/web instead of at the workspace root, where `pnpm dev` hands off to turbo and runs every package. If you already have a linked Vercel project, `vc env pull` fills the local file with deployed values instead of typing them. Two constraints sit underneath all of that: package.json pins engines to node 24.x and declares [email protected] as the package manager. The deploy path asks for the signing secret first, and the walkthrough generates it with `openssl rand -base64 32`.

turbo, ultracite and a bun reporter wire the checks together

The monorepo is legible in package.json. Workspaces sit under apps/ and packages/, with turbo orchestrating the parallel work: turbo dev, turbo build, turbo typecheck. Linting and formatting come from ultracite, exposed as check and fix and sitting on oxlint and oxfmt. One script chains everything a change has to survive, and the chain is the interesting part: pnpm check, then pnpm typecheck, then pnpm test:isolated, then a database check inside apps/web. Tests run two ways, node scripts/test-isolated.ts for the default path and bun test with a junit reporter writing to stdout for verbose runs, so that second path needs a bun binary on the machine. The root also carries AGENTS.md, CLAUDE.md, an .agents/ directory and a skills-lock.json, which means the repository ships instructions aimed at coding agents and pins the skills it expects.

There is no release to pin, and no runtime outside Vercel

A few things a production deployment wants are missing on purpose. Start with versioning: the repository has no GitHub releases, so there is no tag to pin a fork to and no published changelog to diff against an upgrade. Moving forward means comparing main against whatever you forked. Vercel is not an optional target either. Sandbox orchestration, the durable workflow and the deploy button all assume it. Sign-in has exactly two social providers named, Vercel and GitHub, handled by Better Auth with every auth route served from the /api/auth/[...all] catchall. Session sharing gives read-only links, which suits circulating a transcript and gives you nothing collaborative. Voice input needs an ElevenLabs key. And the capability list names no default model provider, so which model drives the loop is a decision you make yourself.

Editorial conclusion

Adopt Open Agents if you want a durable agent that survives a closed browser tab and a hibernating VM, and you are willing to fork it. Do not adopt it expecting a versioned dependency or a runtime that is not Vercel, because there are no GitHub releases to pin and the README describes the agent as a durable workflow on Vercel. Before the first deploy, check two things: that your dev server inside the sandbox listens on 3000, 5173, 4321 or 8000, and that you are willing to run node 24.x with pnpm 11.5.1 as pinned in package.json.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. vercel-labs/open-agents on GitHub