A full computer, ready when you ask
A sandbox is a small Linux computer with root access. Use it to run an agent, test a product, try a build, or run code nobody has read. The worst outcome is a computer you throw away.
A computer that was never off
Nothing boots. A sandbox is restored from one that was already running, so it is ready at once and not in the time an operating system takes to start.
These are medians from the production fleet, printed by the test battery on one of its hosts. Every number on this site carries its source. Hover one to see it.
Checkpoint before the risky step, restore after it
An agent about to run a migration, an upgrade, or a command it just invented is one step away from a computer that no longer works. A checkpoint makes that step cheap to undo, and the restore puts the state back without putting a new computer in its place.
$ pilot machine checkpoint my-app --comment pre-upgradeID SEQ DURABLEck-3a3077f4 2 false$ pilot exec my-app -- ./upgrade.shSegmentation fault$ pilot machine restore ck-3a3077f4NAME STATE CREATED URLmy-app running 2h ago https://my-app.pilotrun.appsame computer, same URL, same agent tokenIn place, on the same computer
A restore does not hand you a new computer at a new address. It is the same computer, at the same URL, with the same key your agent is already holding.
Named and chained
Checkpoints have names and can be taken from a restored state, so an agent can walk back to a known-good point and try a different branch.
Durable in the background
The computer carries on at once, and the checkpoint is backed up behind it. You can wait for the backup to finish when you need to be sure of it.
Run a command, or watch it run
Run a command and get its output when it ends, or watch the output as it happens. An agent that works for minutes needs the second.
Working directory and environment
Every command takes a directory, an environment and a user, whether you wait for its output or watch it.
Optional stdin
A command that never reads input can be started without any, which is what a long-running agent wants.
Clients for JavaScript and Go cover everything the platform does. Every client and adapter.
A running command counts as activity. A sandbox in the middle of a build is not idle, so the 2s timer never puts an agent to sleep in the middle of its work.
Run an agent in it
A sandbox is where an agent belongs. Give it every permission, because there is nothing of yours in there to wreck, and let it work on its own. Claude Code opens inside a sandbox with one command, signed in from your terminal.
$ pilot claude scratchpilot: installing Claude Code (once)...opens signed in as you, with no login in the sandboxSigned in from your own computer
The first run takes a long-lived token for your subscription, or an API key, and keeps it beside your Pilots key on the computer you are typing at. Every run after that, in any sandbox, opens Claude Code already signed in. Nothing is saved in the sandbox, and nothing in it ever asks you to log in.
The credential rides with one process
It travels as the environment of the process that starts Claude Code, the way an SSH agent is forwarded. Nothing on the sandbox's disk carries it, and once Claude Code exits, the next command in that sandbox cannot see it.
Where that stops
While it runs, the credential is in the sandbox's memory, so exit it before forking that sandbox for somebody else. And this is a command you run yourself: an agent asked to run it would carry the credential through its own context.
Everything above applies to the agent inside. It sleeps with the sandbox when it goes idle and costs only its disk until the next command, a checkpoint before its risky step brings back the exact moment, and the boundary around it is a whole computer.
Claude Code is the one it signs in. Any other agent runs in a sandbox through
pilot exec, with whatever environment you hand it.
The boundary is a whole computer
Every sandbox is a virtual machine with a kernel of its own. What runs in one cannot reach another, or the computer underneath it.
Limits on every sandbox
Each one has a cap on processor, memory and how many programs it may start. A runaway program stays inside.
No way into your network
A sandbox cannot reach the computer it runs on, or its neighbours.
A key of its own
Each sandbox has its own key, so a leaked one opens only that sandbox.
Made to be thrown away
The expected end of a sandbox is that you destroy it. Nothing assumes it is precious.
Yours alone
A key sees only what its team owns. Anything else answers as not found.
No ceiling per team
A team runs as many computers as it needs. The only refusal for size is a full fleet, and it says so.
Drive one through its whole life
Put a sandbox to sleep, wake it, take a checkpoint and restore it. Its address holds through all of it.
- state
- running
- autoStop
- suspend
- minRunning
- 0
- replicas
- one
- checkpoints
- 0
A simulation of the lifecycle, not a live computer. The states, knobs, and transitions are the real ones.
- create computer created from template, URL assigned
Any port is reachable too, at a name on the same address, so a dev server your agent started can be opened in a browser with nothing to set up.
What a restore promises
A restore always brings the computer back. In one case it comes back without what was running.
Usually a computer returns with its memory, and every program is where it was. When that is not possible, it starts again from its own disk instead.
It keeps its name, its URL, its storage and every file it had written. It loses the programs that were running and what they held in memory, and it tells you so.
A request that arrives while a computer is asleep is held, not bounced, for up to 120s.
The sandbox becomes the service
When something built in a sandbox turns out to matter, it is not rebuilt somewhere else. Ask your agent to promote it, and it is live at pilotrun.app with nothing for you to configure.