bash call runs in a fresh container. That’s ideal for working with files, but a coding agent wants a real machine: packages it installs should still be there on the next command, and the dev server it starts should keep running after the command returns.
This guide gives an agent a persistent sandbox as its computer. The agent builds a small web app, runs it as a supervised service, and you open it at a public URL. Between sessions you pause the sandbox, and the next session picks up exactly where the last one left off, with the server still running. The project lives on an Archil disk mounted at /workspace, so the code outlives the sandbox.
Prerequisites
Export your Archil API key, a region where sandboxes are available (aws-us-east-1, aws-us-west-2, or aws-eu-west-1), and an AI Gateway key for the model:
Define the agent
The agent has one tool,bash, that runs a command in the sandbox with sandbox.exec. Because it’s the same machine every time, npm install in one call is visible to the next, and the instructions tell the agent to run servers with archil-sandbox services create so they keep running in the background, restart if they crash, and come back if the sandbox reboots.
onOutputstreams output as it’s produced, so you can watch a slownpm installor test run instead of waiting for it to finish. The full output is still returned when the command exits.timeoutSecondsbounds every command. If the agent runs something that never exits, such as starting a server in the foreground, the command ends with statustimed_outand the agent is told so, rather than hanging the loop. That’s also why the instructions point it at services for anything long-running.
Build the app
The first session creates the workspace disk and the sandbox, then hands the agent its task. When the agent finishes, the script exposes port 3000 publicly and requests the app from your machine. Finally, it pauses the sandbox, which stops compute and snapshots memory so running processes, including the web server, resume intact.Resume in a later session
A paused sandbox keeps its memory, its root filesystem, and its mounts. When you come back, find it by name, resume it, and give the agent its next task.resume() does nothing if a request already woke the sandbox. Either way, the web server answers right away because the process never stopped; it was frozen with the rest of the VM.
stop() it instead: memory is discarded, but the root filesystem and /workspace are kept, and the web service starts again on the next boot because services are supervised. Either way, the project files are on the Archil disk, so you can read them with the disk APIs or mount the disk somewhere else even after the sandbox is gone.
Clean up
A sandbox must be stopped before it can be deleted, and a paused sandbox can be stopped directly. Stop and delete the sandbox, then delete the workspace disk.Next steps
Parallel agents
Fork a prepared sandbox per agent, run them side by side, and keep the best result.
Persistent sandboxes
Lifecycle, services, network access, and forking in detail.
Sharing disks
Mount one disk in several sandboxes at once with read-only and conditional mounts.
TypeScript SDK
Full reference for sandboxes, disks, and
exec options.