OpenClaw: a self-hosted AI gateway that lives in your chat apps

The problem OpenClaw solves: one assistant, every channel

Most assistant setups are per-app. You have a chat window in one product, a CLI in another, and a browser tab for a third, and none of them share context or tools. OpenClaw inverts that: it runs a Gateway on a machine you control and treats messaging services as front ends to it. WhatsApp, Telegram, Slack, Discord, Google Chat, Signal and iMessage are all listed as supported channels, and the Control UI, CLI and TUI connect to the same Gateway.

The README frames the audience explicitly. The same gateway "runs as a personal assistant on one laptop or as a shared team deployment, and configuration is the only difference." That is a real design commitment, not marketing: it means the team case is not a separate product tier but a configuration surface. The repository also carries a VISION.md, a taxonomy.yaml and a custodian-skills directory, which suggests the maintainers think about scope boundaries rather than shipping every possible integration.

Who it is for, concretely: someone who already lives in a messaging client, wants an assistant there rather than in a new tab, and is comfortable running a Node.js service. The package description on npm is "Multi-channel AI gateway with extensible messaging integrations," which is a more honest summary than the banner copy.

Gateway, channels, nodes: how the pieces fit together

The Gateway is the local control plane. According to the README it owns sessions, tools, events and channel connections. Everything else is a client of it: the Control UI, the CLI, the TUI, and the messaging channels themselves. Model providers are pluggable, and the docs distinguish hosted from local providers, so the same Gateway can route to a hosted API or to a local runtime depending on configuration.

Tools, skills and plugins extend what the assistant can do. Companion apps and nodes add voice, Canvas, camera, screen and device-local actions on supported platforms. The repository layout matches this: there are apps/, packages/, extensions/, skills/, deploy/ and a separate extensions directory referenced by the Dockerfile build argument OPENCLAW_BUNDLED_PLUGIN_DIR.

The security posture is stated plainly and is the most important architectural fact. Inbound messages are treated as untrusted input, and "tools run on the host for the main session unless you configure sandboxing." That is a deliberate default: capability first, isolation opt-in. If you connect a channel that strangers can reach, the pairing flow is what stands between them and your host. DM-capable channels pair unknown senders by default, and approval is a CLI action.

Installing OpenClaw on macOS, Linux or Windows

The installer covers macOS, Linux and Windows and provisions a Node.js runtime when one is missing. On macOS, Linux or WSL2 the README gives a single curl command that pipes the install script into bash. The script starts onboarding automatically on a fresh install, so expect a wizard rather than a silent install.

# macOS / Linux / WSL2
curl -fsSL https://openclaw.ai/install.sh | bash

On Windows the equivalent is a PowerShell one-liner that downloads and executes the install script.

# Windows PowerShell
iwr -useb https://openclaw.ai/install.ps1 | iex

If you already manage Node.js yourself, install the published package instead. The README states the supported runtime range as Node 22.22.3+, 24.15+ or 25.9+, and the flag below is required on npm 12 or npm 11.16+ because the package ships a lifecycle script. On npm 11.15 and earlier, omit the flag.

npm install -g openclaw@latest --allow-scripts=openclaw

After a package install, onboarding is a separate step. It verifies model access, creates the workspace and configures the Gateway. Then you check that the Gateway is up and open the Control UI.

openclaw onboard --install-daemon
openclaw gateway status
openclaw dashboard

The last command opens the Control UI; sending a message there is the README's suggested way to confirm the assistant actually works. If you are coming from the search phrase "how to use OpenClaw on Windows," the PowerShell path above is the whole story, plus channel setup in the getting started guide.

Running the Gateway in Docker and what the compose file pins

The repository ships a docker-compose.yml with a single openclaw-gateway service built from the local Dockerfile. The compose file is worth reading before you run it, because it documents a real failure mode in its comments: a macOS host path such as /Users/<you>/.openclaw imported from .env caused first-reply mkdir '/Users' EACCES failures inside Linux Docker. The fix is to pin the container-side paths explicitly.

The compose file sets OPENCLAW_STATE_DIR, OPENCLAW_CONFIG_PATH, OPENCLAW_CONFIG_DIR and OPENCLAW_WORKSPACE_DIR under /home/node/.openclaw, and pins OPENCLAW_GATEWAY_PORT to 18789. It also passes OPENCLAW_GATEWAY_TOKEN through from the environment. Bonjour discovery is disabled automatically in detected containers unless OPENCLAW_DISABLE_BONJOUR is set to 0 or 1. OpenTelemetry export is described as outbound OTLP/HTTP from the Gateway, while Prometheus reuses the authenticated Gateway route and needs no extra port.

The Dockerfile is a multi-stage build that produces a runtime image without build tools, source code or Bun, and pins its base images to SHA256 digests for reproducibility. Plugin dependencies are opt-in through the OPENCLAW_EXTENSIONS build argument, which accepts manifest ids or source-directory names.

The default that should make you pause: host-executed tools

The README says tools run on the host for the main session unless you configure sandboxing. Combined with the instruction to treat inbound messages as untrusted input, that is the central risk of the default configuration. An assistant that can run tools on your machine and reads messages from a channel is a plausible path from a stranger's text to your filesystem, and no amount of onboarding polish changes that arithmetic.

The mitigation is documented rather than automatic. The README points at a security guide, an exposure runbook and a sandboxing guide, and says to read them before connecting other users or exposing the Gateway remotely. Pairing is the second control: DM-capable channels pair unknown senders by default.

openclaw pairing approve <channel> <code>

A second constraint is operational. The .env.example warns that the Gateway refuses to start if OPENCLAW_GATEWAY_TOKEN is set to the documented example placeholder, and that direct config keys such as gateway.auth.token often take precedence over environment fallbacks. Env precedence is documented as process env, then ./.env, then ~/.openclaw/.env, then the openclaw.json env block, with existing non-empty process variables not overridden. If you debug auth by editing .env and nothing changes, that precedence order is why.

When OpenClaw is the wrong tool, and what to use instead

OpenClaw is a gateway, not an IDE assistant. If your work is editing a repository and you want a coding agent scoped to that repository, a tool like Claude Code is aimed at that job: it runs in your terminal against a project directory, and its unit of work is a code change. OpenClaw's unit of work is a conversation arriving over a channel, and its surface area is sessions, tools, channels and device nodes. The search phrase "openclaw vs claude code" is really a question about two different categories, and the answer is that they overlap only where you ask OpenClaw to write code and hand it a shell.

The other real alternative is doing nothing and using the assistant that already ships inside your messaging app or your model provider's own client. That costs less attention: no Gateway to patch, no token to rotate, no host tools to sandbox. You give up local control, provider choice and the ability to point the same assistant at several channels at once.

There is also a cost question in the search data ("Is OpenClaw free", "OpenClaw pricing"). The repository is MIT licensed, so the software itself carries no licence fee, and the README does not describe a paid tier. Model usage is a separate matter: you supply provider credentials, and hosted providers bill for what the assistant consumes. Local providers change that equation but not the hardware cost.

Licence, maintenance and upgrade cost

The package.json declares the license as MIT, and the author is listed as the OpenClaw Foundation. The repository's LICENSE file is the canonical text; the GitHub API reports the licence as NOASSERTION, which usually means the file exists but is not matched to a known SPDX template. If licence terms matter to your organisation, read LICENSE and THIRD_PARTY_NOTICES.md directly rather than trusting a badge.

The repository is not archived, and the last push was on 2026-08-28. The most recent release at that time is tagged v2026.9.1-beta.1, and the two before it are also betas (v2026.8.1-beta.3 and v2026.8.1-beta.2). The published package version in package.json is 2026.9.4. That gap between a 2026.9.4 package and a 2026.9.1-beta.1 release tag is worth understanding before you pin a version: the release channel you follow determines what you get.

Upgrade cost is not zero. The package.json carries schema versions for state (17) and agent (20), which means persisted data has a versioned shape. The docs list an updating page and a release-channels page, and the repository ships node-runtime-update.mjs and node-runtime-recovery.mjs at the top level, which suggests runtime upgrades are treated as a managed operation rather than a manual npm bump. The README does not document rollback, so decide your own before you upgrade a Gateway that holds state you care about.

Editorial conclusion

Adopt OpenClaw if you want one assistant reachable from the chat apps you already use and you are willing to read the security, exposure and sandboxing guides before connecting anyone else. Do not adopt it if you need a hosted service where someone else owns the auth, the uptime and the model bill, or if you want a coding agent scoped to a repository rather than a messaging gateway. Verify first that your Node.js version satisfies the published range, that your chosen model provider credentials work, and that you understand what OPENCLAW_GATEWAY_TOKEN protects before you bind the Gateway beyond loopback.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes