Integrations

CreateOS ships plugins for seven coding agents and terminal tools, plus nodes for two workflow builders, n8n and Langflow, and a provider for AgentBox. 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.

AgentBox is a fifth: it already runs agents in disposable boxes, and the plugin swaps the box for a microVM, so you pick CreateOS per box and nothing else about it changes.

No agent at all. n8n and Langflow are the odd ones out, a workflow step rather than an agent tool. Reach for them when the untrusted thing is an input, a form submission, a webhook body, a row someone else controls, rather than a build. n8n runs one command and hands back stdout, stderr and the exit code. Langflow goes further, with three separate surfaces: it can harden an existing flow's Python node, give you a sandbox node to wire up yourself, or move a whole flow graph off the host.

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
AgentBox	In the sandbox	A provider plugin, selected per box
n8n	No agent	A workflow node that runs one command
Langflow	No agent	A sandbox backend, a canvas node, or the whole flow

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. If there is no agent in the picture and the command comes from an automation, use the n8n node, or the Langflow plugin if the automation is a Langflow flow.

Setting up

Every integration except DeepSeek Harness, n8n, Langflow and AgentBox 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:

curl -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:

createos 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:

export 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 exceptions

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.

n8n does not either. The node calls the control-plane API directly and holds its own CreateOS API credential, so it is set up inside n8n rather than at a terminal.

Langflow reads CREATEOS_SANDBOX_API_KEY from the environment Langflow runs in, so there is no CLI session involved.

AgentBox holds its own key too, prompted on first use or read from CREATEOS_API_KEY, and attaches to boxes over an authenticated websocket rather than SSH.

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 is charged for memory and storage but not vCPU. Whether quitting a session destroys anything depends on the integration, each page says which.