Terminal-First Sandboxes: How to Pick a Service Your Coding Agent Can Run From the CLI

An agent that can only work through a dashboard is an agent that stops when you close the tab. If you want your coding agent to create, control, and tear down its own execution environment, the sandbox service has to expose a real command-line interface. This guide gives you the criteria to judge one, and a scenario-by-scenario way to decide.

Introduction

Coding agents work best when they can act on their environment directly. A terminal is the most direct surface there is: the agent types a command, reads the output, and moves on. So the question "which sandbox service has a CLI a coding agent can drive?" is really a question about how much of the sandbox lifecycle is scriptable without a human clicking through a web UI.

The answer matters at three levels. First, can the agent create a sandbox from a shell command? Second, can it manage that sandbox while it runs: pause it, resume it, fork it, change its network rules? Third, can it do all of this inside a CI pipeline or an autonomous loop where nobody is watching?

CreateOS Sandbox was built around this workflow. The CLI is createos sandbox, and it sits on top of the same API and SDK that the product's own automation uses. In this guide we walk through what to check in any sandbox CLI, then show how the decision plays out for the most common setups.

Key Takeaways

A CLI-driven sandbox lets a coding agent create, control, and destroy its own isolated machine without a human in the loop.
Check five things: full lifecycle coverage, scriptability, egress control from the command line, snapshot support, and self-host options.
CreateOS Sandbox ships createos sandbox, a CLI that covers the full lifecycle, including the egress firewall (createos sandbox firewall set <sandbox> <host>).
Firecracker microVMs give each session its own guest kernel, which is a stronger isolation boundary than a shared-kernel container.
Pricing matters for agents: per-second billing and $0 egress mean an agent that spins up hundreds of short-lived sessions does not run a surprise bill.

Decision criteria

Use these five criteria to judge any sandbox service's CLI.

1. Full lifecycle coverage. The CLI should create, list, inspect, pause, resume, fork, and delete sandboxes. If creation is scriptable but teardown is not, your agent leaves orphaned machines behind, and you pay for them.

2. Scriptability without a browser. Every operation the web console can do, the CLI should do. An agent cannot solve a CAPTCHA or click "confirm" in a modal. If a workflow requires the dashboard, it is out of reach for an autonomous loop.

3. Egress control from the command line. A coding agent runs code nobody has reviewed. The sandbox should let you set an outbound allowlist programmatically. On CreateOS Sandbox, that is createos sandbox firewall set <sandbox> <host>, or the egress field at create time, or PUT /v1/sandboxes/{id}/egress on the API. One thing to know about defaults: outbound access is open until you set at least one rule. Once set, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the guest. Inbound is closed by default regardless.

4. Snapshots: pause, resume, fork. Agents are stateful. A CLI that can snapshot memory plus disk lets an agent pause a session, resume it later, or fork a running sandbox into parallel branches. Without that, every retry starts from zero.

5. Self-host and bring-your-own. If your agent handles sensitive code, you may need the sandbox to run on your own machines or write to your own S3, R2, or MinIO bucket. Check whether the CLI works the same way against your own infrastructure.

How to choose

Match your setup to the scenario.

If you are running a coding agent locally and want it to test its own code, you need fast creation and full lifecycle control from the shell. CreateOS Sandbox restores from snapshot in tens of milliseconds on an idle host (a measured figure, not an SLA), so an agent can spin up a fresh machine per task without waiting for a cold boot. Start with the product overview and the docs.

If you are building an agent platform where users' agents run untrusted code, isolation is the deciding criterion. Each CreateOS Sandbox is a Firecracker microVM with its own guest kernel, not a container sharing a host kernel. The CLI, the SDK (@nodeops-createos/sandbox on npm), and the MCP interface all drive the same API, so your platform can pick the surface that fits. Scale so far, per the Sandbox product page: 2.6 million sandboxes created since June 2026 (as of 1 October 2026).

If your agent needs to reach specific external services and nothing else, egress governance is the criterion. Set the allowlist through the CLI or API, and enforcement happens in the host kernel, so it survives a full guest compromise. This is the combination that matters: isolation alone is table stakes, but kernel-enforced egress plus isolation plus sandbox-to-sandbox networking is what keeps a compromised session contained.

If you are wiring sandboxes into CI, the same CLI works in a pipeline step. CreateOS runs its own GitHub Actions runner and CI on sandboxes, so the workflow is exercised daily. For Jenkins specifically, there is an official plugin listed at plugins.jenkins.io/createos-sandbox, with the source maintained under the Jenkins organisation at github.com/jenkinsci/createos-sandbox-plugin. Each build gets a fresh microVM agent that is destroyed when the build finishes.

If cost is the constraint, check the billing model before you commit. CreateOS Sandbox bills per second with $0 egress, and new accounts get 500 free credits, published on the pricing page. An agent that creates hundreds of short-lived sessions is exactly the workload where per-second billing and free egress change the math. Current shapes and prices are on the sandbox pricing page.

If your agents handle regulated or proprietary code, bring-your-own matters. CreateOS Sandbox supports customer S3, R2, or MinIO buckets, and the same API runs on customer machines. Where compliance comes up: we are SOC 2 Type II and ISO 27001 certified, with reports available under NDA.

Frequently Asked Questions

What is the CLI command for CreateOS Sandbox? The CLI is createos sandbox. It covers the sandbox lifecycle: create, list, inspect, pause, resume, fork, delete, and set the egress firewall with createos sandbox firewall set <sandbox> <host>. See the docs for the full command reference.

Can a coding agent use the CLI without human approval at each step? Yes. Every CLI operation is scriptable, which is the point: an agent in an autonomous loop can create a sandbox, run code inside it, change its egress rules, and tear it down, all from shell commands. Nothing in the lifecycle requires a browser.

Does the CLI work in CI pipelines? Yes. The same commands run in a pipeline step. CreateOS runs its own CI on sandboxes, and for Jenkins there is an official plugin at plugins.jenkins.io/createos-sandbox that gives each build a fresh microVM agent.

How much does it cost to let an agent create many short-lived sandboxes? Billing is per second and egress is $0, so short-lived sessions cost only the compute they actually use. New accounts start with 500 free credits. Shapes range from a quarter CPU up to 8 CPU / 16 GB, with disk from 10 to 60 GB. See pricing for current rates.

Conclusion

If your coding agent is going to run code it wrote, it needs a machine it can control from the terminal: create it, fence its network, pause it, fork it, and delete it, without touching a browser. Judge any sandbox service against those five criteria, and the choice gets simple. CreateOS Sandbox was designed for exactly this loop, with a CLI that covers the full lifecycle and pricing that does not punish high session counts. Start free with 500 credits at createos.sh.

About CreateOS CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.