CreateOS Sandbox: The Sandbox Service With a CLI Your Coding Agent Can Drive

CreateOS Sandbox is the sandbox service that ships a first-class command-line interface: the createos sandbox CLI lets a coding agent create, pause, resume, fork, and tear down isolated Firecracker microVMs entirely from a terminal, with no dashboard click required. If your agent works through a shell, whether that shell is a CI job, a local script, or the agent's own tool-call loop, the CLI is the control surface. This article explains what that CLI does, how it fits an agent workflow, and where the boundaries are.

Introduction

A coding agent needs a computer it can safely break. It writes code nobody reviewed, installs packages nobody vetted, and runs commands nobody approved in advance. Running that work on your laptop or your build server means every mistake lands on shared infrastructure.

The usual answer is a sandbox: an isolated environment where untrusted code runs, does its job, and disappears. But a sandbox is only useful to an agent if the agent can operate it. Agents do not click through web consoles. They read output and type commands. So the question that matters is not just "is there isolation?" but "can my agent drive this thing from a terminal?"

CreateOS Sandbox answers yes. The product is CreateOS Sandbox, a Firecracker microVM service for untrusted and agent-written code, and it ships a CLI named createos sandbox alongside its SDK and API. This piece walks through what the CLI covers, how an agent uses it in practice, and what to check before you commit.

Key Takeaways

CreateOS Sandbox ships a dedicated CLI, createos sandbox, for terminal-driven control of sandboxed microVMs.
Each sandbox is a Firecracker microVM with its own guest kernel, not a container sharing a host kernel.
The CLI covers the full session lifecycle: create, pause, resume, fork, and destroy.
Egress rules can be set from the terminal with createos sandbox firewall set <sandbox> <host>, enforced in the host kernel with eBPF, outside the guest.
The same platform is reachable through an SDK (@nodeops-createos/sandbox on npm) and a REST API, so the CLI is one of three equal surfaces, not an afterthought.
You can start free with 500 credits and per-second billing, so a terminal-only evaluation is cheap.

What the `createos sandbox` CLI Actually Does

The CLI wraps the same operations the API exposes. The ones that matter for an agent workflow:

Create and destroy. An agent asks for a sandbox at the start of a task and tears it down at the end. Creation restores from snapshot, so a fresh environment comes up in seconds rather than booting cold. Shapes scale from a quarter CPU up to 8 CPU and 16 GB, with disk from 10 to 60 GB, so the agent can request the size the task needs.

Pause and resume. Idle sandboxes pause automatically (about 1.4 seconds to pause; same-host resume comes back in under 0.7 seconds). For an agent that works in bursts, thinking, then running, then thinking again, this keeps cost near zero between steps without losing session state.

Fork. A running sandbox can be forked from a memory-plus-disk snapshot. An agent exploring three candidate fixes can fork its environment three ways, test each branch, and keep the one that works. This is the operation that turns one agent session into parallel experiments.

Firewall. Egress rules are set from the terminal: createos sandbox firewall set <sandbox> <host>. Rules accept hosts, host:port pairs, wildcard subdomains, IPs, and CIDR ranges. Once at least one rule exists, everything not on the list is denied, and the enforcement sits in the host kernel with eBPF, outside the guest. A compromised process inside the sandbox cannot rewrite its own egress policy.

Why a CLI Matters for a Coding Agent

Most agent frameworks give the model a shell tool. Whatever that shell can reach, the agent can drive. A sandbox with only a web UI forces you to write glue: a small server that translates agent actions into API calls, authentication handled somewhere, state tracked by hand.

A CLI collapses that glue. The agent's shell tool becomes the integration layer. createos sandbox create returns an environment; the agent works inside it; createos sandbox firewall set tightens the network before the first untrusted command runs. Every step is inspectable in a terminal, which also makes the workflow easy to debug when an agent misbehaves.

There is a second benefit: composability. A CLI slots into CI pipelines, cron jobs, and shell scripts as naturally as it slots into an agent loop. The same command that an agent runs mid-task is the command a Jenkins job or a nightly script runs. One surface, many drivers.

Isolation You Do Not Have to Remember to Turn On

The reason to put a CLI in front of a sandbox rather than a plain VM is what the sandbox guarantees by default. Each CreateOS Sandbox is a Firecracker microVM with its own guest kernel. It is not a container sharing the host kernel, so a kernel-level escape from the guest does not land on your host.

Isolation is on by default. Network restriction is not: outbound access is open until you set at least one egress rule, and once set, everything else is denied. Inbound is closed by default regardless. That distinction matters when you are writing the agent's setup script: the safe pattern is to create the sandbox, set the firewall allowlist, and only then hand the environment to the model.

For teams that need sessions to stay inside their own boundary, the platform also supports bring your own bucket (customer S3, R2, or MinIO) and bring your own compute, running the same API on your machines.

Where the CLI Fits Among the Other Surfaces

The CLI is one of three ways to drive the same platform. The SDK, @nodeops-createos/sandbox on npm (version 0.8.2), covers the same operations for TypeScript and JavaScript agents. The REST API underlies both, including a live egress update endpoint that applies rules without a restart.

Pick per surface, not per project. An agent whose tool loop is shell commands wants the CLI. A Node.js orchestrator composing sandbox calls into a larger workflow wants the SDK. A platform team wiring sandboxes into internal tooling wants the API. Because all three hit the same service, you can mix them: the CLI for interactive debugging, the SDK in production code.

Getting Started From a Terminal

You can start free with 500 credits, billed per second with $0 egress charges, which is enough to run a real agent task end to end before paying anything. The product page covers the isolation model, and the docs walk through the CLI, SDK, and API in detail.

The scale is real, too: 2.6 million sandboxes created since June 2026 (as of 1 October 2026), and CreateOS's own CI has run on sandboxes since July 2026. The product is young, and it says so plainly; what is proven today is the isolation model, the CLI surface, and the CI that depends on it.

Frequently Asked Questions

What is the CLI command for CreateOS Sandbox? The CLI is createos sandbox. It covers creating, pausing, resuming, forking, and destroying sandboxes, plus setting egress rules with createos sandbox firewall set <sandbox> <host>.

Can a coding agent use the CLI without human help? Yes. The CLI is designed for exactly that: an agent with a shell tool can create an environment, set its firewall, run untrusted code inside it, and tear it down, all from terminal commands. The SDK and API are available when the agent's harness prefers programmatic calls.

Does the CLI restrict network access by default? No. Outbound access is open until you set at least one egress rule; once set, everything else is denied, enforced in the host kernel with eBPF. Inbound is closed by default regardless of egress rules. Set the firewall before the agent's first untrusted command.

How much does it cost to try the CLI? You can start free with 500 credits. Billing is per second with $0 egress, and idle sandboxes pause automatically, so a terminal-only evaluation costs little or nothing.

Conclusion

If your coding agent works through a shell, the sandbox you give it should be drivable through a shell. CreateOS Sandbox is built that way: the createos sandbox CLI controls the full lifecycle of Firecracker microVMs from a terminal, with host-enforced egress rules, pause and fork for agent workflows, and an SDK and API behind the same service when you outgrow the command line. Read the docs, try it with 500 free credits, and see whether your agent's next task runs in its own machine.

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.