OpenClaw 2.0 Is Here, and Clawstainer Has a Recipe for It

OpenClaw 2.0 landed, and it is a genuinely big release.

The team's own post calls it accidental, in the sense that they slowed the release cadence to rebuild foundations properly and looked up to find they had shipped a major version. The numbers back that up. More than 16,000 pull requests went into it, roughly half of every PR ever merged into the project. That is not a point release wearing a bigger number.

What you actually get is a much better product. Setup is guided now, and it verifies your model connection before it saves anything, reusing the API keys, subscriptions, and local models already sitting on your machine instead of making you paste everything in again. The Control UI was rebuilt chat-first, with conversations in the sidebar, streaming Markdown replies, and a Sessions page you can search and batch-manage. There is a git panel with working-tree diffs, a dockable browser panel for inspecting elements, a background task panel that tracks work across conversations, and approval gates with a 30-day history for anything that wants a human in the loop. Tool calls render as readable rows with inline diffs, which makes watching your agent work feel like reading a changelog instead of squinting at a firehose. Shared cloud sessions bring other people into a conversation without losing context.

It is a lot. It is also, if you are coming from 1.x, a real upgrade rather than a drop-in one.

So here is our small contribution to the moment. Clawstainer ships a built-in OpenClaw recipe, and whether you are upgrading an existing Claw or meeting it for the first time this week, a disposable local sandbox is a great place to do it.

The Recipe

Clawstainer creates isolated Linux sandboxes on your laptop. No Docker, no cloud account, no bill. On macOS it runs a lightweight Linux VM through Lima and hides the whole thing from you. On Linux it runs natively. Boot takes 2-3 seconds.

brew install lima          # macOS only
cargo install clawstainer

Then two commands for a running gateway:

clawstainer create --name openclaw-box --memory 2048 --cpus 2 --linger
clawstainer provision <id> --components openclaw

The openclaw component pulls the current installer from openclaw.ai, so you get 2.0 and the Node 22 runtime it wants without thinking about either. It writes an openclaw-gateway.service unit, enables it, starts it, and verifies with openclaw --version. It carries a 600 second timeout so you are not guessing at one.

Pass --linger at create time. Without systemd lingering, user services get reaped on logout or idle, which for a long-lived gateway means your agent quietly dies the moment you stop watching it. The recipe enables lingering inside the sandbox as well, but setting it on the box saves you a confusing afternoon. The same applies to Hermes.

The rest of the loop:

# Get inside
clawstainer shell <id>

# Watch it come up
clawstainer logs <id>

# Open the new Control UI from your host browser
clawstainer port-forward <id> 8080:8080

# Push a config in
clawstainer cp ./config.json <id>:/root/

# Gone, cleanly
clawstainer destroy <id>

Every sandbox gets its own overlay filesystem, so destroy really does mean gone.

If You Are Upgrading from 1.x

This is the case we would most like to flag, because 2.0 changes how sessions and transcripts are stored. They move into SQLite. The release notes are clear that you should take a verified backup first, and that sessions created after the migration will not show up if you roll back to an older file-backed release.

That is a completely reasonable thing for a project to do at a major version. It is also exactly the kind of change you want to rehearse once before you run it against the Claw you actually depend on.

A sandbox makes the rehearsal cheap. Stand up a box, restore a copy of your config into it, run the upgrade, poke at your channels and your skills, and see what moves. If it all works, do it for real with confidence instead of hope. If something surprises you, you found it on a machine you can throw away.

If You Are Trying It for the First Time

Then the sandbox is just the tidiest front door available.

OpenClaw is an agent with hands. It runs shell commands, drives a browser, reads and writes files, and talks to you through WhatsApp, Telegram, Slack, Discord, iMessage, or Signal. That reach is the entire point, and 2.0 leans into it with better approval gates and a clearer trust model of one boundary per gateway. Running your first experiments inside a sandbox is not a hedge against the project. It is the same instinct the project itself recommends, made convenient.

Practically, it means you can be curious without being careful. Try a config, break it, destroy, start again two seconds later. Nothing accumulates on your laptop. Nothing needs cleaning up.

Where Sandboxes Really Earn Their Keep

Three habits worth stealing once you have the recipe running.

1. Snapshot your known-good gateway

This is the big one.

clawstainer snapshot create <id> --name openclaw-2-ready
clawstainer create --name test-1 --from openclaw-2-ready --linger

Now every experiment starts from an identical baseline. When something breaks you know it was your change, not four days of accumulated drift. That turns debugging an agent into an actual process. We wrote up the full pattern in Snapshot Your Agents, including the golden image workflow for keeping a fleet on the same version.

2. Audition skills before you trust them

Community skills are one of the best things about OpenClaw, portable SKILL.md files you can pull from ClawHub, a repo, or a URL, and read before you run. Reading them is good. Running them in a box you can delete is better. Provision from your snapshot, drop the skill in, watch what it does, tear it down, and then decide. It is the same quarantine habit we use for dependency updates, applied to agent extensions.

3. Test more than one config at once

A fleet.yaml gets you ten gateways in parallel:

machines:
  - name: openclaw
    count: 10
    memory: 1024
    cpus: 2
    provision: openclaw
    linger: true

clawstainer fleet create --file fleet.yaml --parallel 5

Handy for comparing models on the same task, or reproducing a bug against a setup you do not personally run.

Flags Worth Knowing

For sizing, OpenClaw wants 2GB during provisioning and runs comfortably in 1-2GB after that. A provisioned snapshot lands around 700MB.

One Honest Note on the Boundary

The default nspawn runtime is a container, which means namespace and cgroup isolation over a shared kernel. That is a strong boundary for testing, iteration, and keeping a half-configured agent away from your dotfiles. It is not a hardware wall. Clawstainer includes a Firecracker microVM backend for that, but it is experimental and untested today, so treat it as such.

A sandbox also does not solve prompt injection. If your gateway is wired to a channel where untrusted content arrives, that content can still steer the model. What the sandbox changes is the blast radius when it does.

Give It a Shot

OpenClaw 2.0 deserves the attention it is getting. If the release made you want to upgrade, or made you want to finally try the thing, the two commands are right here.

clawstainer create --name openclaw-box --memory 2048 --cpus 2 --linger
clawstainer provision <id> --components openclaw

Clawstainer is open source and MIT licensed. Issues, recipes, and pull requests welcome.