Skip to main content
In the quickstart, every 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:
Then install the dependencies. The TypeScript agent uses the AI SDK; the Python agent calls the same model through the gateway’s OpenAI-compatible API.

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.
Two details in the tool keep long commands manageable:
  • onOutput streams output as it’s produced, so you can watch a slow npm install or test run instead of waiting for it to finish. The full output is still returned when the command exits.
  • timeoutSeconds bounds every command. If the agent runs something that never exits, such as starting a server in the foreground, the command ends with status timed_out and 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.
You’ll see each command the agent runs, its streamed output, and then the response from your machine. The agent’s steps vary from run to run; here is one run, with the long file and JSON output trimmed:
Open the printed URL in your browser to try the form. The script has already paused the sandbox, but a request to an exposed port resumes a paused sandbox automatically, in about a second. The sandbox then keeps running until you pause or stop it again.
exposePort makes the port reachable by anyone with the URL. Don’t expose anything that handles real data without adding its own authentication. For programmatic access, use a port token instead; see Hosting network services.

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.
Pausing is the right default between agent sessions that are minutes or hours apart. If the sandbox will sit idle for longer, 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.