Clawops MCP Server

clawops

MCP-native infrastructure ops for OpenClaw, with read-only mode, destructive-action confirmation, and audit logs built in.

clawops is a CLI and MCP server for deploying and operating self-hosted OpenClaw instances. Provision on AWS, GCP, Azure, or any Linux VM, then manage day-to-day operations from the terminal, or let Claude Code and Cursor drive them through typed MCP tools with explicit safety controls.

---

What's new: 2.4 release notes below, and the full history in CHANGELOG.md.

---

Who this is for

• OpenClaw users who want the simplest path to self-hosting across cloud or local VMs, with reliable deploy, status checks, logs, backups, and upgrades in a single CLI.
• Claude Code / Cursor / MCP users looking for a real-world reference implementation of safe infrastructure operations through MCP. Typed tool schemas, read-only mode, destructive-action confirmation, and audit logs.
• Self-hosted AI and local-first developers who want to run their own AI assistant without committing to Kubernetes, a managed SaaS platform, or a single cloud provider.

---

What clawops does

• Provisions and tears down OpenClaw infrastructure on AWS, GCP, Azure, and local VMs using the Pulumi Automation API. You do not install Pulumi; clawops installs the CLI it needs into ~/.clawops/.pulumi-cli on first use.
• Manages day-to-day operations: status, logs, SSH, tunnels, config, agents, gateway, backups.
• Exposes every operation as a typed MCP tool so AI agents can drive ops safely.
• Enforces a plan → review → apply discipline for cloud deployments.
• Emits JSON output everywhere (--json) for scripting and automation.
• Never stores cloud credentials. Reads them from your environment's existing CLI profiles.

What clawops does not do

• No high availability or clustering. Optimized for single-node deployments.
• No Kubernetes. It deploys to VMs, not container orchestration platforms.
• No OpenClaw skill/agent authoring. clawops manages infrastructure; what runs on it is up to you and OpenClaw.
• No TLS or domain automation (yet). Bring your own reverse proxy or see docs/limitations.md for the manual path.
• No credential storage. Cloud credentials must be configured in your environment before using clawops. They are never written to ~/.clawops/config.json.
• No native Windows. WSL2 is fully supported; see docs/support-matrix.md.

---

Quick Start

npm install -g @clawops/cli
clawops setup

clawops setup is an interactive wizard that gets OpenClaw running in about 2 minutes. It handles everything in one flow, no config files to write by hand, no commands to memorize.

What the wizard does

Step 1. Choose a deployment target

Pick an existing server you can SSH into (Linux or macOS), or a new cloud VM on AWS, GCP, or Azure. Cloud deployments walk you through authenticating with the provider CLI if you aren't already signed in.

Step 2. Pick an LLM provider

Choose from Anthropic, OpenAI, Amazon Bedrock, Ollama, or others. The wizard prompts for your API key and saves it locally (in ~/.clawops/secrets/, chmod 600), it is never sent anywhere except to OpenClaw on the target host when the config is applied.

Step 3. Add chat integrations (optional)

Select any combination of Discord, Telegram, Slack, WhatsApp, or Teams. The wizard collects each integration's bot token the same way as the API key. Paste it in, reference an env var, or point to a file.

Step 4. Wire your AI editor

Select which AI apps should have access to clawops. Claude Desktop, Claude Code, Cursor, Windsurf, VS Code, and Zed are all supported. The wizard writes an MCP server entry into each app's config file using the absolute binary path so the app can launch it independently.

Step 5. Deploy

The wizard bootstraps OpenClaw on the target host over SSH (installs Docker, pulls the image, starts the container), applies your LLM and integration config, generates a gateway auth token, and prints a direct dashboard URL:

✔ All done! OpenClaw is running.
ℹ Open dashboard: http://192.168.1.50:18789?token=<your-token>
ℹ Token saved to ~/.clawops/secrets/GATEWAY_TOKEN_my-stack

Prerequisites: Node.js ≥ 22, an SSH key, and either an SSH-reachable Linux/macOS host or a cloud account with CLI credentials configured (aws configure, gcloud auth login, or az login). You do not need Pulumi. The first cloud deployment installs the CLI clawops drives into ~/.clawops/.pulumi-cli and says so while it does.

For a full narrated walkthrough with example output, see docs/demo-script.md.

---

Manual setup, existing server

If you prefer step-by-step control, or are adding clawops to an already-running deployment:

npm install -g @clawops/cli

clawops doctor   # verify environment

clawops init --provider local --host 192.168.1.50 --user ubuntu --key-path ~/.ssh/id_ed25519
clawops up       # installs Docker + OpenClaw over SSH
clawops status

See docs/examples/local-vm.md for SSH prerequisites, firewall setup, and troubleshooting.

Manual setup, cloud (AWS)

npm install -g @clawops/cli

# Requires AWS credentials in your environment (AWS_PROFILE or ~/.aws/credentials)
clawops init --provider aws

# Edit ~/.clawops/config.json: set stateUrl to your S3 bucket

clawops plan --provider aws --stack default --ssh-cidr auto --out /tmp/plan.json
clawops apply /tmp/plan.json

--ssh-cidr auto allows SSH from this machine's public IP, resolved while the plan is generated and written into it. Without it the plan allows no ingress at all and nothing, including clawops, will be able to connect.

---

Connect an AI editor

The setup wizard handles this automatically (Step 4). To wire or re-wire editors at any time:

clawops mcp install

This opens the same interactive checkbox used in the wizard, select Claude Desktop, Claude Code, Cursor, Windsurf, VS Code, or Zed and clawops writes the MCP entry into each app's config using the correct absolute binary path.

To add the entry manually instead, paste this into your editor's MCP config:

{
  "mcpServers": {
    "clawops": {
      "command": "npx",
      "args": ["-y", "@clawops/cli", "mcp", "serve", "--read-only"]
    }
  }
}

That form needs nothing on $PATH and is what a directory or an installer will copy. If you would rather point at the binary you already have, use its absolute path — the output of which clawops — with the same arguments:

{
  "mcpServers": {
    "clawops": {
      "command": "/path/to/clawops",
      "args": ["mcp", "serve", "--read-only"]
    }
  }
}

Either way, pass the arguments. mcp serve is what speaks the protocol, and an explicit config is one that still reads clearly a year later. clawops does not strand a client that omits them: run with no command at all and a pipe on stdin — how every MCP client starts a server — and it starts mcp serve, saying so on stderr. Typed at a terminal, clawops still prints help.

Pass cloud credentials in env. A client starts the server with the environment its config gives it, not your shell's, so an AWS_PROFILE exported in a terminal does not reach it, and every tool that reads a stack fails with "Could not read the state of stack". Name the profile, or the variables your state backend needs, in the server's env block:

{
  "mcpServers": {
    "clawops": {
      "command": "npx",
      "args": ["-y", "@clawops/cli", "mcp", "serve"],
      "env": { "AWS_PROFILE": "my-profile" }
    }
  }
}

It holds a profile name, not a key: the credentials themselves stay where the cloud CLI keeps them (R6).

Config file locations:

Start with --read-only. It enables status, logs, config reads, and diagnostics while blocking mutations. Remove it only after reviewing docs/security/mcp-safety.md.

Destructive tools (clawops_destroy, clawops_up, clawops_config_set, etc.) require explicit confirmation before executing, they will never run silently.

For HTTP mode setup see docs/mcp/.

---

Day-to-day operations

clawops status              # Stack outputs: IP, gateway URL, SSH info
clawops logs -f             # Tail OpenClaw logs over SSH
clawops ssh                 # Interactive SSH session
clawops ssh --command "docker ps"

clawops config get maxAgents
clawops config set maxAgents 8

clawops tunnel              # Port-forward gateway UI to localhost

clawops destroy --yes       # Destroy cloud-provider stack
clawops down --yes          # Destroy local-provider stack

---

Commands

Full flag reference: clawops <command> --help

---

Plan → Apply workflow

For non-local providers, clawops enforces a review-before-apply discipline:

# 1. Generate a plan: runs `pulumi preview` internally, produces JSON
#    --ssh-cidr decides who may connect. `auto` means this machine; omit it and nobody can.
clawops plan --provider aws --region us-east-1 --ssh-cidr auto --out /tmp/plan.json

# 2. Review plan.json: the `diff` field shows projected changes at plan-generation time
cat /tmp/plan.json | jq .diff

# 3. Apply: reads and validates the plan file, then runs `pulumi up`
clawops apply /tmp/plan.json

# Without --yes, apply prompts: "Continue? (y/N)"
clawops apply /tmp/plan.json --yes    # skip prompt in automation

The plan JSON conforms to spec/deploy-plan.schema.json (AJV-validated) and captures reviewed intent: provider, region, instance type, CIDR ranges, and OpenClaw version. apply re-runs pulumi up using those parameters against the current live state, it does not replay a locked execution artifact. Review and apply in the same session to minimize drift risk.

See docs/plan-apply.md for full semantics, drift guidance, and the safe CI pattern.

---

MCP server

clawops ships an embedded MCP server. Claude Code, Cursor, and any MCP-compatible agent can drive deployments without leaving the chat interface.

Wire your editor

clawops mcp install   # interactive checkbox: writes config for selected apps

The wizard resolves the absolute binary path automatically so app launchers can find clawops without inheriting your shell's PATH. See Connect an AI editor above for manual config paths.

Wire the gateway AI

The OpenClaw gateway runs its own AI agent. Once wired, that agent can call clawops directly instead of guessing at infrastructure state:

clawops mcp wire --stack prod   # openclaw mcp add, which connects before it saves

Requires OpenClaw 2026.7.1-2 or later on the gateway. The clawops setup wizard offers this step after a successful deploy.

Every agent on the gateway gets every clawops tool, including the default agent, which answers anyone who can message the gateway. OpenClaw's MCP servers are gateway-wide. After wiring, mcp wire names each agent that can now call clawops. To keep one away, add "clawops__*" to its agents.entries.<id>.tools.deny. For an agent that hands destructive changes back to you instead of making them, use clawops agent install.

Stdio mode (Claude Code / Cursor / VS Code)

Start the server manually or confirm your config is correct:

clawops mcp serve --read-only   # safe for first evaluation
clawops mcp serve               # full mode: enables provisioning, config write, ssh exec

HTTP mode (remote / multi-client)

clawops mcp serve --http 3333 --bind 127.0.0.1
# MCP HTTP server listening on 127.0.0.1:3333

Do not bind to a non-loopback address without additional authentication controls in front of it.

Available tools

Tools in the read toolset are also available in --read-only mode; the table's Toolset column shows the primary toolset. All other toolsets require full mode. Destructive tools require explicit confirmation (elicitation) unless yes: true is passed.

See docs/security/tool-risk-matrix.md for the full risk classification of every tool.

---

Configuration

Config lives at ~/.clawops/config.json (override with $CLAWOPS_HOME).

{
  "version": 1,
  "defaults": {
    "provider": "aws",
    "stack": "default"
  },
  "stacks": {
    "default": {
      "provider": "aws",
      "region": "us-east-1",
      "stateUrl": "s3://my-clawops-state"
    }
  },
  "ssh": {
    "keyPath": "~/.clawops/id_ed25519",
    "knownHostsPath": "~/.clawops/known_hosts"
  }
}

Cloud credentials are never stored in config. Clawops reads them from the environment:

Spending limits

An optional policy block limits what clawops will deploy from this machine, whichever tool asks:

"policy": {
  "allowedInstanceTypes": { "aws": ["micro", "small"] },
  "maxStacks": 3
}

plan, apply and up refuse a server size outside allowedInstanceTypes for that provider (a clawops size or the provider's own type; small and t3.small are the same on AWS), and init refuses a new stack beyond maxStacks. Every MCP tool that deploys is held to the same limits, in the same words, and no tool can change them. clawops setup asks whether to set them, then offers only the sizes you allowed. The limit lives here rather than in the plan because a plan is what an agent writes.

---

Known limitations

See docs/limitations.md for the full list. Key points:

• Single-node deployments only, not a high-availability or clustering platform.
• clawops apply is not an immutable plan execution. See docs/plan-apply.md.
• No TLS/domain automation in the current release.
• MCP tools execute privileged operations, use --read-only for first evaluation.

---

Architecture

clawops
├── src/cli/          citty-based commands (one file per verb)
├── src/config/       ~/.clawops/config.json management
├── src/providers/    Cloud adapters (AWS, GCP, Azure, local)
│   ├── aws/          Pulumi inline program + ProviderAdapter
│   ├── gcp/
│   ├── azure/
│   └── local/        SSH bootstrap (no Pulumi)
├── src/pulumi/       Pulumi Automation API wrapper + output helpers
├── src/transport/    SSH client (ssh2) + connection pool + tunnels
├── src/mcp/          MCP server, tool handlers, progress tracking
├── src/plan/         Maker plan generation, AJV validation, apply
├── src/output/       ASCII table, spinner, JSON, human-readable output
├── src/errors/       Typed error hierarchy with exit codes
└── spec/             Machine-readable ground truth (JSON Schema, YAML)

Key design decisions:

• Pulumi Automation API: the user installs no Pulumi. Clawops installs the CLI the API drives into ~/.clawops/.pulumi-cli, pinned to the bundled SDK, without editing $PATH (ADR 0010); Pulumi home is sandboxed to ~/.clawops/.pulumi; stack programs are inline TypeScript closures
• State in cloud blob storage: GCS (gs://), S3 (s3://), Azure Blob, no local state files, no pulumi.yaml
• SSH via ssh2: never shells out to /usr/bin/ssh; TOFU host verification against ~/.clawops/known_hosts; connection pool with 5-min idle TTL
• Plan → apply discipline: every non-local deployment goes through generatePlan() → review → applyPlan(); destructive changes always require human review of the plan JSON
• MCP-first: every CLI operation has a typed MCP tool; schemas generated from spec/mcp-tools.yaml; all destructive tools use elicitation

See docs/architecture.md for a full narrative, and docs/decisions/ for ADRs.

Cloud provider stacks

Each cloud provider is an inline Pulumi program that creates the resources below. All three share the same outputs (publicIp, gatewayUrl, sshHost, sshPort, sshUser) consumed by the SSH and config-overlay layers.

AWS

flowchart LR
    subgraph NET["Networking"]
        VPC["VPC (10.0.0.0/16)"]
        IGW[Internet Gateway]
        SUBNET["Subnet (10.0.1.0/24)"]
        RT[Route Table]
        SG["Security Group (ports 22, 18789)"]
    end
    subgraph IAM["IAM"]
        ROLE[IAM Role]
        SSM[SSM Policy Attachment]
        BED["Bedrock Policy Attachment (optional)"]
        IP[Instance Profile]
    end
    subgraph COMPUTE["Compute"]
        KP[EC2 Key Pair]
        EC2["EC2 Instance (Ubuntu 22.04, IMDSv2)"]
        EIP[Elastic IP]
    end

Detailed diagram →

GCP

flowchart LR
    subgraph NET["Networking"]
        NW[VPC Network]
        SN["Subnetwork (10.0.0.0/24)"]
        FW1["Firewall: SSH port 22 (conditional)"]
        FW2["Firewall: Gateway port 18789 (conditional)"]
        ADDR[Static External IP]
    end
    subgraph COMPUTE["Compute"]
        VM["Compute Instance (Debian 12, 20 GB)"]
    end

Detailed diagram →

Azure

flowchart LR
    RG[Resource Group]
    subgraph NET["Networking"]
        VNET["Virtual Network (10.0.0.0/16)"]
        SUBNET["Subnet (10.0.1.0/24)"]
        NSG["Network Security Group (ports 22, 18789)"]
        PIP["Public IP Address (Static)"]
        NIC[Network Interface]
    end
    subgraph COMPUTE["Compute"]
        VM["VM (Ubuntu 22.04, managed identity)"]
    end
    subgraph KV["Key Vault (optional)"]
        VAULT["Key Vault (RBAC, name max 24 chars)"]
        RA["Role Assignment (Secrets User)"]
        SECRET["Secret: gateway-token"]
    end

Detailed diagram →

---

Development

Setup

git clone https://github.com/dfridkin/clawops.git
cd clawops
# Node 22+ required; use nvm: nvm use
pnpm install
pnpm dev doctor        # verify toolchain

Scripts

pnpm dev                   # run CLI from src/ via tsx
pnpm build                 # tsup → dist/
pnpm test                  # vitest (2122 tests, ~13s)
pnpm test:changed          # vitest --changed (fast edit loop)
pnpm test:integration      # Docker-based SSH integration tests
pnpm test:e2e:local        # builds, then bootstrap, the host-touching MCP tools and a 1.x migration, in systemd containers
pnpm typecheck             # tsc --noEmit
pnpm lint                  # eslint src/ tests/ scripts/ (--max-warnings=0)
pnpm gen:schemas           # regenerate src/providers/types.ts + src/mcp/tools/_generated.ts
pnpm gen:schemas --check   # CI guard: committed generated files match spec
pnpm graph                 # local coupling report (--base <ref> for this branch's delta)
pnpm verify:pack           # install the packed tarball elsewhere and run it (CI gate)
pnpm sync:server-json      # write package.json's version into server.json
pnpm changeset             # record a release note before merging

Project layout

Code generation

Two files are generated from spec/ and must not be hand-edited:

• src/providers/types.ts. ProviderAdapter interface from spec/providers.schema.json
• src/mcp/tools/_generated.ts. Zod schemas and type exports from spec/mcp-tools.yaml

Run pnpm gen:schemas after modifying either spec file. CI enforces this with --check.

Adding a provider

Use the /add-provider skill in Claude Code, or follow src/providers/CLAUDE.md. Every adapter must satisfy ProviderAdapter in src/providers/types.ts. Do not relax the schema to fit the adapter.

Adding an MCP tool

Use the /mcp-tool skill. The skill adds the tool to spec/mcp-tools.yaml, runs pnpm gen:schemas, creates the handler in src/mcp/tools/<toolset>/<name>.ts, and wires it into the registry. All four annotation hints (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) are required on every tool.

Conventional commits

feat(scope): description
fix(scope): description
docs / refactor / chore / test / perf / ci

Use pnpm changeset to record a release note before merging a feat or fix.

---

What's new in 2.4

A host agent: clawops on the gateway host, for one OpenClaw agent that only you can reach. It reads everything about its own host and changes nothing. A destructive request comes back to you as the exact command to run (ADR 0014). Upgrade note for GCP: the next clawops up stops and starts the VM (see below).

Host agent

• clawops agent install --stack prod --agent ops --operator telegram:12345
  • Checks first. It refuses before writing anything unless the gateway's routing lets only you reach that agent.
  • Denies the rest. It removes clawops from every other agent and checks that the gateway kept those entries.
  • Then installs a pinned, checksum-verified Node runtime and your own clawops build. It runs as clawops-agent.service on the Docker bridge, and the gateway is wired to it.
  • Uninstalling is clawops agent uninstall.
• It reads, and hands off. 12 read tools run locally, with no SSH, Pulumi state or cloud credentials on the host. The destructive tools you name with --allow change nothing. Instead, each returns the clawops command for you to run on your machine, where it asks for confirmation as usual. yes: true is ignored. clawops_destroy, clawops_stacks_delete and clawops_migrate are refused outright.
• Pending requests show in clawops status, ready to copy. Running the command clears its request, and requests left alone lapse after 7 days. clawops_status reports them too.
• Re-checked on every call. If the gateway's configuration changes so that anyone else can reach the agent, every call is refused until it is fixed. A group binding or a new agent without the deny are examples. Nothing needs reinstalling.
• Other agents in the gateway container. On a default deployment every agent can run commands and read files there, including the host agent's token and transcripts. Install and clawops_status name those agents; --strict refuses while any remain. See operations and the disclosure review.

GCP hosts have no service account

The VM ran as the project's default compute service account. That account has the cloud-platform scope and, on most projects, the Editor role, so any process on the host could act on the whole project. Nothing on the host calls a Google API, so the VM now has none. On an existing stack, the next clawops up removes it. That stops and starts the VM; the boot disk is untouched.

Fixes

• clawops_logs_tail reads the gateway's own logs again. Since 2.0.1 it had fallen back to container output on every host, saying the gateway was not answering when it was. clawops logs was not affected.
• clawops config set|unset --restart restarts the gateway the way gateway restart does. Its own restart brought a gateway published on every interface back on loopback only. It also fell back to the moving stable tag when it could not read the image, and reported success before the gateway had started.

What's new in 2.3.1

A security fix. Upgrade if you set gateway config through MCP.

• Before: clawops_config_set wrote the value you set to the audit log (~/.clawops/mcp-audit.log) in clear and redacted the config path instead. Setting models.providers.openai.apiKey through an agent therefore logged the API key. The confirmation prompt showed the value too.
• Now: the value is redacted whenever its path names a secret, and secret fields inside a JSON object value are redacted one by one. Paths are logged as written. See redaction.
• Existing logs are not rewritten. If you used clawops_config_set for a secret before 2.3.1, check your audit log and rotate that secret.

What's new in 2.3

Spending limits that an agent cannot lift, and a run of fixes from the backlog.

Spending limits

• An optional policy block in ~/.clawops/config.json limits the server sizes clawops may deploy on each provider and the number of deployments it may manage. plan, apply and up refuse a size outside the list; init refuses a stack beyond the cap.
• Every MCP tool that deploys is held to the same limits, in the same words, and no tool can change them. Confirmation is something an agent can answer for itself; this is not.
• clawops setup asks whether to set them, then offers only the sizes you allowed. See Spending limits.

Fixes

• The setup wizard's plan asked the cloud for a machine called small. It wrote the clawops size where the provider's own type belongs. It now maps it, as clawops plan does.
• clawops_workflow_recover runs the stack's health checks, and recommends only real tools. It ran two of the four steps it described and finished by suggesting clawops refresh, which does not exist.
• The MCP audit log redacts credential arguments. GOOGLE_APPLICATION_CREDENTIALS was named sensitive in spec/errors.yaml and logged in the clear. A test now fails when the spec and the code disagree on an error class, its exit code, or a redaction pattern (#185).

---

What's new in 2.2

Recovery is a flag, agents can reach every command they need, and SSH failures say what failed. 2.2.1 follows with the fix below it.

Restore puts a backup into service

• clawops backup restore --file <archive> --activate swaps the restored state in, restarts the gateway on it, and checks that it answers. Without --activate, a restore still verifies and expands into a staging directory and touches nothing live.
• The state it replaces is kept, not deleted. If the gateway does not come up, clawops puts the old state back and restarts again; the state that failed is kept as .failed-restore-<timestamp>, as evidence.
• The restored state lands on the host, beside the directory it replaces. Before, it stayed in the container's /tmp, where the next gateway restart destroyed it.
• Free space is checked before an archive is expanded.
• clawops backup --help no longer says restore is unavailable. It has worked since 2.0.

Every command an agent needs is an MCP tool

• Ten new tools bring the catalog to 30: backup create and restore (with activate), gateway status and update, one agent's logs, migrate, stacks delete, and secret list, audit and delete. Each calls the same code as its command, so both refuse the same things in the same words.
• clawops ssh and clawops secret set / rotate stay CLI-only on purpose: a root shell or a secret value does not belong in an agent's hands or its transcript. The secret tools never return values.

SSH failures name the cause

• A timeout says nothing came back, which on a clawops stack usually means the security group no longer admits your address. The message prints the re-plan and apply that fix it.
• A refused connection says the host is up and sshd is not. A rejected key names the key clawops offered. A name that does not resolve, and a handshake with no algorithm in common, each say what they are. ssh2's own words are kept in every message.
• clawops doctor --stack <name> prints the same advice on its own line.

Fixes found by running every tool against a real host

The new tools were driven end to end over MCP against a systemd host, a 1.x deployment made by clawops 1.7.9, and AWS. That found defects the unit tests could not, several in the CLI too:

• clawops gateway update works. Every update since the upgrade gate shipped refused before touching anything, because the state snapshot was given a host path inside a container that cannot create it.
• Local-provider hosts no longer race systemd. The gateway runs there as the openclaw unit with Restart=always, which undid a restart, an update, a migration or a restore about five seconds after clawops made it. clawops now changes the gateway through the unit.
• clawops gateway, agents, config and logs work on local stacks. Each failed with "The local provider does not use Pulumi stacks" while its MCP tool worked.
• clawops migrate refuses a stack already on 2.x, which it would have given a fresh minimal config; asks before it runs, as --yes always claimed; and pulls the 2.x image before stopping 1.x, so the downtime is a restart rather than a multi-gigabyte download.
• A secret name can no longer reach outside the secrets directory. clawops secret delete ../config.json deleted the clawops config.
• clawops_gateway_restart keeps a gateway published on every interface where it was, instead of moving it to loopback.
• A stack whose state cannot be read says why, instead of Pulumi's code: -2, and names the usual cause for an MCP server: credentials missing from its client config's env block.

Other fixes

• Streaming Docker commands, such as a backup upload or a log follow, no longer reuse a sudo decision learned from an unrelated command. On AWS, where the login user is not in the docker group, a backup upload failed with "permission denied" after the backup had been taken.
• The backup and upgrade-rollback guides describe --activate instead of a manual procedure, and CI follows every in-repo Markdown link and anchor (pnpm verify:docs).
• The local provider's bootstrap runs for real in its e2e suite, against a container with systemd as PID 1, instead of being mocked. The same suite now drives the host-touching MCP tools and a 1.x migration (pnpm test:e2e:local, nightly and on PRs labelled e2e), and E2E_MCP=1 pnpm test:cloud <cloud> backs up and restores over MCP on a real cloud host.
• clawops.fyi carries structured data, an /llms.txt, a FAQ and a comparison page.

2.2.1

• clawops config validate and config set check against the schema the pinned OpenClaw release (2026.9.2) really has. The schema clawops shipped had been captured from a different build, and the weekly check that compares them found the drift every week and then failed to report it, on a missing issue label. It reports now. In practice: messages.suppressToolErrors is refused, as the gateway refuses it, and transcripts.autoStart[].whenOccupied is accepted.
• On OpenClaw 2026.9.2, agents can read each other's sessions by default. Cross-agent session access (tools.agentToAgent) and collector-mode subagents (tools.swarm) are on unless turned off. If agents on one gateway should not see each other's sessions: clawops config set tools.agentToAgent.enabled false, or give it an allow list.

---

What's new in 2.1

Private networking, hardening on every cloud, and two fixes to commands that could not start. 2.1.1 follows with the fixes below it.

Reach a stack over your tailnet

Documentation truncated — see the full README on GitHub.