Integrations

CreateOS ships plugins for seven coding agents and terminal tools. They all end up at the same place — your code runs on a disposable Linux microVM instead of your laptop — but they differ in where the agent itself runs, and that difference is what should decide which one you pick.

Three shapes

The agent runs locally and calls out to a sandbox. Claude Code, Codex, and OpenCode work this way. The agent reads and edits files on your machine as usual, and reaches for a sandbox when it needs to build, test, or run something untrusted. You stay in control of what goes remote, because the agent has to choose a sandbox command or tool to get there.

The agent runs locally but its tools are remote. Pi can go further: with one flag, its built-in shell, file, and search tools all operate inside the sandbox. The agent behaves normally and never sees your filesystem. This is the closest thing to working on a remote machine without changing how you work.

The agent runs inside the sandbox. Herdr and Orca invert the arrangement — the agent process lives on the microVM and you drive it through a local pane or workspace. Nothing about the agent touches your machine, which matters when the agent itself is what you want contained.

DeepSeek Harness is a fourth case: rather than adding tools, it replaces the harness's filesystem and subprocess layers outright, so everything built on them runs in the sandbox without knowing it.

Picking one

Integration	Agent runs	How you reach the sandbox
Claude Code	Locally	18 slash commands, plus a skill that offers to offload heavy work
Codex	Locally	A skill that teaches the `createos` CLI
OpenCode	Locally	33 sandbox tools
Pi	Locally	34 sandbox tools, and optionally every built-in tool
Herdr	In the sandbox	A terminal pane per sandbox
Orca	In the sandbox	A whole workspace on a microVM
DeepSeek Harness	Locally	Filesystem and subprocess layers replaced

If your problem is a slow or risky command — a long build, a flaky suite, a script you did not write — start with the integration for the agent you already use. If your problem is that you want the whole session off your machine, look at Pi's remote-tools mode, or at Herdr and Orca.

Setting up

Every integration except DeepSeek Harness drives the createos CLI underneath. None of them hold credentials of their own — they shell out to the CLI and use whatever session it has. So there is really only one thing to set up, and it works for all of them.

Install the CLI:

Bash
1curl -sfL https://raw.githubusercontent.com/NodeOps-app/createos-cli/main/install.sh | sh -

Most integrations install it for you on first use, so this is belt-and-braces — but doing it yourself makes the first run faster and any failure easier to read.

Then authenticate, one of two ways.

At a terminal, sign in:

Bash
1createos login

This is the path for day-to-day work on your own machine. It opens a browser, so it needs a real terminal — run it yourself rather than asking an agent to.

In CI, a devcontainer, or anywhere headless, set an API key instead:

Bash
1export CREATEOS_API_KEY=<key>

Neither is a lesser option: the plugins accept both, and the API key takes precedence when both are present. Export the key in your shell rather than pasting it into a conversation with an agent.

The exception

DeepSeek Harness does not use the CLI. It talks to the control plane through the sandbox SDK and takes CREATEOS_SANDBOX_API_KEY plus a shape directly, so createos login does nothing for it and the CLI is not a prerequisite.

Agents that run inside the sandbox

Herdr and Orca involve two sets of credentials, which is worth separating clearly. Your CreateOS credentials live on your machine and create the sandbox. The agent's own provider credentials — Anthropic, OpenAI, or whatever it uses — belong inside the sandbox, and you sign the agent in there. Putting the agent's key in a local plugin config does not get it to the box, and is not where it should live.

What you get in every one

The underlying sandbox is the same regardless of which integration creates it, so the platform capabilities are available throughout: private networks between boxes, public HTTPS URLs, port tunnels back to localhost, S3 disk mounts, custom images built from a Dockerfile, egress allowlists, and pause, resume, and fork.

Two behaviours are worth knowing before your first run, because both surprise people:

Egress is unrestricted by default. A sandbox can reach the whole internet until you tell it otherwise. Every integration exposes a way to restrict it, and the presets cover the common package registries. When the goal is genuinely to prevent exfiltration, prefer IP and CIDR rules over domain rules — domain allowlists are a strong control for HTTPS and a weak one for cleartext HTTP.

Cleanup differs between them. One-shot commands destroy their box on the way out. Reusable boxes stay until you destroy or pause them, and a paused box costs nothing to keep. Whether quitting a session destroys anything depends on the integration — each page says which.