Which Sandbox Service Has a CLI a Coding Agent Can Drive From a Terminal?

CreateOS Sandbox. Its CLI, createos sandbox, installs from a Homebrew tap or an install script and gives a coding agent the sandbox lifecycle in the shell: create a session, set its egress rules, pause it, resume it, fork it. Every session runs in a Firecracker microVM with its own guest kernel.

The Terminal Is Where a Coding Agent Already Lives

A coding agent works through a shell. Claude Code, Codex, and tools like them read files, run commands, parse the output, and run the next thing. The terminal is the loop. When code an agent writes needs to run somewhere safe, the sandbox has to fit that loop. If reaching the machine means opening a dashboard or wiring up an HTTP client the agent does not have, the workflow breaks.

CreateOS Sandbox is built around that constraint. It is Firecracker microVM infrastructure for untrusted and agent-written code, sold self-serve: free trial, SDK, CLI, MCP, no sales call. The CLI, createos sandbox, is the piece a terminal agent drives. See the Sandbox product page for the full picture, and Tools for Sandboxing AI Coding Agents for the broader comparison of isolation approaches.

Quick Takeaways

The CLI is createos sandbox. Install it with Homebrew (brew tap nodeops-app/tap && brew install createos) or the install script, then hand it to your agent.
Every sandbox is a Firecracker microVM with its own guest kernel. Agent-written code gets a machine boundary, not a container on a shared host.
Egress control is one documented command, createos sandbox firewall set <sandbox> <host>, enforced in the host kernel with eBPF, outside the guest.
Sessions pause in about 1.4 seconds and resume on the same host in under 0.7 seconds, so an agent can checkpoint work and pick it up later.
New accounts start with 500 free credits. Billing is per second and egress is $0.

Why a CLI Fits the Way Coding Agents Work

An agent's universal interface is the shell. It already runs git, package managers, and test runners. A sandbox it controls through that same interface needs no glue code, no dashboard credentials, and no custom integration between the agent and the machine. The loop stays in one place: run a command, read the output, decide, run the next one.

Fit is also about trust. Agent-written code is untrusted code. You are pointing a command generator at your infrastructure, and the machine that code runs on needs a boundary that holds when the code misbehaves. A Firecracker microVM gives each session its own guest kernel, VM-isolated at the machine boundary. Code inside cannot reach the host kernel or another session's kernel, because those are different kernels.

The network policy has to cut both ways: enforceable by the agent, not rewriteable by the code it runs. CreateOS enforces the egress allowlist in the host kernel with eBPF, outside the VM. Code in the sandbox cannot rewrite it or route around it, and the rule survives a full guest compromise. Terminal control plus host-enforced policy is the combination that makes this fit.

What the CLI Puts on the Terminal

Isolation. Each sandbox is a Firecracker microVM with its own guest kernel. That is the argument for microVM over container: the boundary is a machine, not a namespace.

Egress control. From the CLI: createos sandbox firewall set <sandbox> <host>. Rules take host, host:port, wildcard subdomains, IPs and CIDRs. Outbound access is open until the first rule is set; once set, everything else is denied. Inbound is closed by default regardless. You can also set the egress field at create time, call PUT /v1/sandboxes/{id}/egress to change rules live with no restart, or use the SDK's setEgress method.

Session state. Pause, resume, fork. Pausing writes a snapshot of full guest state and stops compute billing. Resume restores that exact machine. Forking a paused sandbox branches its memory and working state for parallel runs. Pause takes about 1.4 seconds, same-host resume is under 0.7 seconds, and a cross-host cold start runs 11 to 13 seconds. A new session starts from snapshot restore in tens of milliseconds on an idle host. That figure is a measured idle number, not an SLA.

Direct access. Interactive shell and SSH forwarding, so the agent or the human can step inside the machine.

Portability. Bring your own bucket (S3, R2, MinIO) and bring your own compute, the same API on customer machines. When the harness prefers code over shell, the SDK (@nodeops-createos/sandbox on npm) and MCP support cover it.

The Evidence: Adoption, Uptime, and What Ships

The adoption number: 2.6 million sandboxes created since June 2026. CreateOS has run its own CI on sandboxes since July 2026, and its GitHub Actions runner and coding-agent plugin are working code, not roadmap items. Uptime runs at 99% or better. The infrastructure underneath is operated by NodeOps, the infrastructure company behind CreateOS, operating production infrastructure since December 2023. Traces and usage dashboards are live today.

What is young, said plainly: this is a young product, and compliance certifications are on the roadmap for the Sandbox surface, not shipped. What is proven is the isolation model, the egress enforcement, and the CI that runs on it every day.

Before You Commit: Limits, Pricing, and Tradeoffs

Size. Shapes run from a quarter CPU up to 8 CPUs and 16 GB of memory, with 10 to 60 GB of disk. No GPU sandboxes. Check the heaviest workload your agent will run.
Egress default. Outbound is open until you set a rule. Set it at create time or with the firewall command. Do not assume deny-by-default.
Wake-up paths. Auto-resume triggers on ingress HTTP only. Every other wake-up goes through the CLI or API.
Cross-host moves. A cold start on a different host costs 11 to 13 seconds. If your agent forks across hosts, plan for the wait.
Cost. Per-second billing, $0 egress, 500 free credits to start. Current numbers are on the Sandbox pricing page.
Procurement. Certifications are roadmap for this surface. If your security review needs one today, raise it early.

Frequently Asked Questions

What can a coding agent actually do with the createos sandbox CLI?

It drives the sandbox lifecycle from a shell: create a session, set its egress rules with createos sandbox firewall set <sandbox> <host>, pause and resume work, and fork a paused session for parallel runs. Install is one Homebrew command or an install script. The docs cover the full command set.

Does the CLI replace the SDK and the API?

No. One platform, three surfaces. Terminal agents use the CLI. Code-first harnesses use the SDK, @nodeops-createos/sandbox on npm. Pipelines call the REST API directly, including PUT /v1/sandboxes/{id}/egress for live egress changes with no restart. Pick the surface your harness already has.

Is outbound network access locked down by default?

No. 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, where the sandboxed code cannot touch it. Inbound is closed by default no matter what.

What does it cost to try with an agent?

New accounts start with 500 free credits. Billing is per second and egress is $0, so a short agent run costs very little. Shapes run from a quarter CPU up to 8 CPUs and 16 GB of memory. The pricing page has current numbers.

Drive It From the Terminal

The answer is CreateOS Sandbox, and the reason is fit. A coding agent works in a shell. A sandbox it can drive from that shell, on a machine with its own kernel, under network policy it can set in one command and the code cannot rewrite, is the version of this that holds. Install the CLI, start free with 500 credits on the Sandbox product page, and give your agent's code a real 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.