Solari for Coding Agents: A Sandbox per Task

Coding agents have moved past suggesting a line of code: they now take a task and finish it. GitHub Copilot plans changes, edits files and runs tests in a cloud development environment, and Claude Code reads a codebase, runs commands and creates pull requests on its own.

Every one of those tasks needs a machine to run on, and it can't be the laptop or server that called the model. This guide covers why each coding task should get its own sandbox, what an agent does inside one, how Solari runs it from the first clone to the final pull request, and where coding agents are heading next.

Why Does Every Coding Agent Task Need Its Own Sandbox?

A coding agent needs a sandbox because nobody has reviewed the code it runs. A sandbox is a restricted execution environment, and agent-written code needs one: it installs packages, runs scripts and sometimes deletes the wrong directory.

The old way was a developer's machine or a shared CI runner, where one task's broken install or leftover file became the next task's problem. The inputs raise the stakes: an issue, a README or a dependency can carry a prompt injection that steers the agent toward a command nobody asked for.

The new way is a sandbox per task. A broken install or a runaway process ends with its task, and the next task starts on a clean machine. Your agents run in parallel without seeing each other's files, and you throw a machine away the moment its work is done.

What Can a Coding Agent Do in a Sandbox?

A coding agent in its own sandbox does the same work a developer does at a terminal, end to end. These are the jobs teams hand to it first:

• Reproduce the bug. The agent clones the repository, installs the dependencies and runs the failing test. Your reviewer starts from a confirmed failure instead of a guess about one.

• Run tests and servers. It runs the suite, reads the exit codes and starts a dev server to check the change. Every result comes back as output the agent can act on.

• Work through data in Python. It loads a fixture or a log file and inspects it step by step, keeping variables between calls the way a notebook does. Plots come back as images, so the agent can check a chart as well as a number.

• Wait for a person. When the agent needs a decision, it stops and keeps everything in place: the checkout, the installed packages and the running processes. The reviewer answers hours later and the work picks up where it stopped.

• Try several fixes at once. When more than one fix is plausible, the agent copies its machine and tries each fix in its own copy. Your reviewer comes back to finished candidates instead of a question.

• Ship the change. It commits to a branch and pushes, so the change arrives as a pull request with the build artifacts and reports alongside. Nothing leaves the sandbox except what you ask for.

What Role Does Solari Play?

Solari runs each coding task in its own AI sandbox: an isolated Linux machine you create by API, pause while the agent waits and copy when it needs more than one attempt. The agent brings the model and the logic; Solari gives it the machine.

Getting a repository in and the tests running takes four calls:

const sbx = await sandboxes.create({ template: "base", lifecycle: { onTimeout: "pause" } })
await sbx.connect()
await sbx.git.clone(repoUrl, { path: "/work/repo" })
const res = await sbx.commands.run("npm", { args: ["test"], cwd: "/work/repo" })

const sbx = await sandboxes.create({ template: "base", lifecycle: { onTimeout: "pause" } })
await sbx.connect()
await sbx.git.clone(repoUrl, { path: "/work/repo" })
const res = await sbx.commands.run("npm", { args: ["test"], cwd: "/work/repo" })

const sbx = await sandboxes.create({ template: "base", lifecycle: { onTimeout: "pause" } })
await sbx.connect()
await sbx.git.clone(repoUrl, { path: "/work/repo" })
const res = await sbx.commands.run("npm", { args: ["test"], cwd: "/work/repo" })

• Isolation per task. By default every Solari sandbox gets a microVM of its own behind a hypervisor. Choose the "hardened" tier for code that came from untrusted input, and Solari blocks all outbound network for that machine.

• Repositories without leaked tokens. The git namespace clones, commits and pushes with typed results, so your agent never parses Git output by hand. A private repository's token travels as an environment variable of that one command, never in the URL, .git/config or the process arguments, so nothing is left behind for the agent's later code to find.

• Commands that report back. commands.run returns the exit code, stdout and stderr, and a command that hits its deadline returns timedOut: true instead of throwing, so your agent checks that flag first. commands.start streams a dev server's output and takes stdin, pty.create gives terminal tools a real pseudoterminal, and runCode runs Python with its state kept between calls.

• Files in and out. files.write puts a fixture or a reviewer's patch in place, and the upload and download calls move larger blobs such as coverage reports. files.watch streams filesystem events, so your orchestrator collects output as it lands. File operations run on the default "dedicated" tier or "hardened"; a "shared" sandbox runs commands and code only.

Pausing and forking decide how often your agent pays for setup. The figure below sets out what each sandbox lifecycle call keeps.

• Pause while the agent waits. With onTimeout set to "pause", the default, an idle sandbox pauses on its own with its memory and disk intact, and connecting again resumes it with the running processes still there. A paused machine stops counting against your limit on running machines, so a task waiting on review holds no slot. Keep the sandbox id in a secrets store, not in logs, because whoever holds it can run commands as root.

• Snapshot and fork for parallel attempts. A snapshot captures a running sandbox's memory and disk, so new sandboxes start with the repository cloned and the failing test already reproduced. Fork takes the snapshot and starts as many copies as you ask for in one call. Solari bills snapshot storage at $0.05 per GB-month after the first 10 GB.

Teams already on E2B's SDK move to Solari with one import change and pay almost 3x less per sandbox hour. The same account runs cloud browsers and desktops, so an agent that needs to check a deployed page or click through an app never leaves Solari.

Where Are Coding Agents Going Next?

Today most coding agents take one ticket at a time and wait for a person at every step. Over the next year that changes in four ways:

• From one attempt to many. Agents will try several fixes in parallel by default and hand the reviewer the one that passes. The other attempts stay attached as evidence of what did not work.

• Tasks that last for days. Agents will hold a task open across several rounds of review. Pausing and resuming a machine becomes as routine as saving a file.

• Checking their own work in a browser. Agents will deploy a preview, open it in a browser and test the change the way a person would. Review starts from a change that has already been clicked through.

• Tighter network defaults. Teams will block outbound network by default for code that came from untrusted input. Access opens only where a task needs it.

What stays human is judgment: which fix merges, how the codebase should look in a year, and the call on anything that touches security or customers. The teams that win will spend their engineers on that and hand the repetitive loop to agents.

Get Started With Solari

Start with one task: create a sandbox, clone the repository, run the tests and let it pause at the first review. Solari is the fastest and cheapest way to run cloud browsers and VMs for coding agents. Get started with a free account and start running your agents today.