# OpenClaw keeps the assistant on your hardware and the tools on your host

> OpenClaw runs a local Gateway that answers you inside Discord, Slack, Teams, Telegram, WhatsApp, iMessage and 20+ more channels, with state and credentials on your own machine. The same binary is pitched for solo and team use and the stated difference between them is configuration alone, which is also where the sharp edges sit.

**openclaw/openclaw** — Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞 

- Repository: https://github.com/openclaw/openclaw
- Website: https://openclaw.ai
- Stars: 390,780 · Forks: 82,185
- Language: TypeScript
- License: NOASSERTION
- Published: 2026-08-17 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/openclaw-openclaw

## One Gateway, and configuration is the only difference between solo and team

The Gateway is the local control plane: it owns sessions, tools, events, and channel connections, and the Control UI, the CLI, and the TUI are clients of it. Channels carry the assistant into WhatsApp, Telegram, Slack, Discord, Google Chat, Signal, and iMessage, plus 20+ more services, and companion apps and nodes add voice, Canvas, camera, screen, and device-local actions on supported platforms. The same Gateway runs as a personal assistant on a laptop or as a shared team deployment, and the difference the project names between those two is configuration alone.

That framing has a cost for anyone expecting a hosted multi-tenant product. Nothing in the README describes per-member scopes, per-user quotas, or per-user credential separation, so opening the Gateway to other people does not move the trust boundary into a per-user runtime. State, memory, and credentials live on your hardware, which is exactly why the boundary does not move. If your requirement is separate visibility or separate data retention per person, you have to build it, because the deployment story stops at the Gateway.

## Two installers, and the npm path carries a flag older npm does not have

The shell installer covers macOS, Linux, and WSL2 and provisions a supported Node.js runtime when it needs one:

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

PowerShell gets a separate script:

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

If you already manage Node.js, install the published package instead, on Node 24.16+ or 26.1+, with Node 26 recommended:

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

The flag is conditional and that is the part worth reading twice. It is for npm 12 or npm 11.16+; on npm 11.15 and earlier you omit `--allow-scripts=openclaw`. So the one documented install line either works or errors depending on your npm version, and a machine on an older npm gets no message about the Node requirement unless you catch the parenthetical. The installer scripts also start onboarding for you on a fresh install; a direct npm, pnpm, or Bun install leaves you to run it yourself:

```bash
openclaw onboard --install-daemon
```

Onboarding verifies model access, creates the workspace, and configures the Gateway, and the next two commands check it and open the Control UI:

```bash
openclaw gateway status
openclaw dashboard
```

Docker, Nix, and the other deployment paths live in the installation guide, so a container or Nix based setup is a documentation trip rather than a line you can copy from the README.

## Tools run on your host until you go configure sandboxing

OpenClaw states its security model in two sentences: treat inbound messages as untrusted input, and tools run on the host for the main session unless you configure sandboxing. DM-capable channels pair unknown senders by default, and a request is approved with:

```bash
openclaw pairing approve <channel> <code>
```

What this cannot do is protect you after approval. Pairing is a manual gate on the sender, not a sandbox on the work. Once a sender is paired, the tool calls the model decides to make run against your filesystem with your account permissions, and the README routes you to a security guide, an exposure runbook, and a sandboxing guide before connecting other users or exposing the Gateway remotely.

The practical consequence is a sequencing one. If you install, onboard, and connect a messaging channel before reading the sandboxing guide, what your machine has is an assistant with host tool access reachable from a chat client, and no default in the repository turns that off. The main session is the exposed case, and sandboxing is a configuration step you have to go find, not a mode the installer asks you about during onboarding.

## One config key is all that stands between the defaults and no version call

Outbound traffic is a short list and you can shorten it yourself. Prompts go to the model provider and chat platforms you configure, plus any diagnostics export you enable. Otherwise, by default OpenClaw phones home for a daily version check, anonymous feature statistics are opt-in, and one key turns off both: `update.checkOnStart: false`.

The project is stewarded by the OpenClaw Foundation, an independent 501(c)(3), and has no paid tier, hosted service, or token. Its architecture argument is written as trusted gateway, untrusted execution, deterministic policy. Here is what that model cannot do for you: it cannot make the default install silent. With the default configuration the process still reaches out on start, so a reader who needs zero outbound calls, an air-gapped host, or a compliance answer of none has to apply that key before the first start and then confirm it, not assume it. That daily check is also the mechanism the appcast files in the repository root (appcast.xml, appcast-arm64.xml, appcast-x86_64.xml) have something to announce. What is actually sent is documented separately under gateway telemetry, which the README links rather than restates.

## Env precedence can quietly outrank the token you think you set

Configuration arrives from four places and the order sits in .env.example: process env, then ./.env, then ~/.openclaw/.env, then the `env` block in openclaw.json. Two consequences follow. Existing non-empty process variables are not overridden by dotenv loading, so a token exported once in a shell profile outlives your later edits to .env. And direct config keys, for example `gateway.auth.token` or channel tokens in openclaw.json, are resolved separately from environment loading and often take precedence over env fallbacks. Setting `OPENCLAW_GATEWAY_TOKEN` in .env is therefore not a dependable way to change the effective token if the same value also lives in openclaw.json.

The variable is required if the gateway binds beyond loopback. Leave it blank and OpenClaw auto-generates a token on first start, or supply your own using `openssl rand -hex 32`. The same file warns that the gateway will refuse to start if the variable is set to the documented example placeholder, so a value copied verbatim out of docs or a tutorial fails loudly instead of quietly. For a reader the failure mode is a gateway that will not start, or clients that cannot authenticate, and the first place to look is not the file you just edited. There is an alternative auth mode in `OPENCLAW_GATEWAY_PASSWORD`, but it is token or password, not both at once.

## Why docker-compose.yml hardcodes /home/node paths

The Compose file pins the container side of every path rather than trusting the environment file:

```yaml
      OPENCLAW_STATE_DIR: /home/node/.openclaw
      OPENCLAW_CONFIG_PATH: /home/node/.openclaw/openclaw.json
      OPENCLAW_CONFIG_DIR: /home/node/.openclaw
      OPENCLAW_WORKSPACE_DIR: /home/node/.openclaw/workspace
      OPENCLAW_GATEWAY_PORT: "18789"
```

`HOME` and `OPENCLAW_HOME` are set to /home/node as well, and the reason is written in a comment next to the override. Without it, a macOS host path like /Users/<you>/.openclaw/... imported from .env caused first-reply `mkdir '/Users'` EACCES failures in Linux Docker, tracked as issue #77436. .env is still loaded and marked required: false, and it controls host publishing, while the in-container listener is fixed at 18789. What this cannot do is line up with a loose volume mount. A volume that exposes only the paths named in your .env will not match where the container actually keeps state, and the visible symptom is a container that looks like a fresh install each time you start it.

Bonjour has the same shape. `OPENCLAW_DISABLE_BONJOUR` empty means auto, and Bonjour disables itself in detected containers; set 0 only on host, macvlan, or mDNS-capable networks, and 1 to force it off. Telemetry export is outbound OTLP over HTTP from the Gateway, while Prometheus reuses the existing authenticated Gateway route and so needs no extra port.

## Docker builds bake extensions in and pin base images by digest

The image is a multi-stage build whose runtime layer carries no build tools, no source code, and no Bun, and it works with Docker, Buildx, and Podman. Build stages use full bookworm while the runtime image is always bookworm-slim, and every base is pinned to a SHA256 digest rather than a floating tag: node:24-bookworm, node:24-bookworm-slim, and oven/bun:1.4.2 by manifest-list digest. The Dockerfile says why, so the pins are deliberate: Dependabot refreshes the blessed digests and release builds consume a reviewed base snapshot instead of mutating distro state on every build.

Optional plugin dependencies are compiled in, not mounted, through a build argument:

```bash
docker build --build-arg OPENCLAW_EXTENSIONS="diagnostics-otel,matrix" .
```

Ids are space or comma separated, and existing source directory names are accepted too. What this cannot do is let you change the plugin set without a rebuild. A build without the argument ships the default set, so one more channel or one more diagnostics exporter is a new image and a new digest rather than a volume mount or an env var. Other knobs also land at build time, since `OPENCLAW_DOCKER_BUILD_NODE_OPTIONS` defaults to `--max-old-space-size=8192` and the declaration step is skipped by default with `OPENCLAW_DOCKER_BUILD_SKIP_DTS=1`. The dependency manifest stages extract only package.json files, which is what keeps unrelated source edits from invalidating the main build layer.

## Calendar version numbers and two different license answers

Version numbers are date strings. Recent tags include v2026.9.7, v2026.9.6, and v2026.8.33, while the manifest in the repository still reads 2026.9.6 and carries an `updateAdmissionProtocol` of 1. Configuration schema is versioned on a separate track, with state at 19 and agent at 24, so a config file written against one release is carrying an explicit compatibility question into the next one. The last push on the repository is 2026-09-29 and release tags landed on 2026-09-30, so this ships continuously rather than on a maintenance cadence.

Two smaller things are worth settling before you depend on it. The package manifest declares the license as MIT and lists the OpenClaw Foundation as author, while the repository's own license metadata reports no assertion, so anyone who needs a definitive answer for compliance has to resolve it from the LICENSE file rather than from either automated signal. And on install, the package asks for permission to run its own lifecycle scripts, which is why the npm line needs `--allow-scripts=openclaw` on recent npm at all: older npm releases have no equivalent gate to grant it with, and the lifecycle script contract itself is documented in the installation guide rather than in the README.

## Conclusion

OpenClaw fits a reader who wants an assistant they control on hardware they own and will meet in the chat apps they already live in. It does not fit a reader who needs per-member isolation, zero outbound traffic on defaults, or a sandbox on day one. Before connecting other people or exposing the Gateway remotely, configure sandboxing, turn off the start check if the default version call is unacceptable, and confirm which token the running Gateway actually reads, because direct config keys can outrank the environment variables you edit.

## FAQ

### What can OpenClaw actually do?

It runs an AI assistant on your own computer that meets you in the channels you already use, including Discord, iMessage, Slack, Teams, Telegram, and WhatsApp, plus 20+ more, with native apps for macOS, iOS, Android, Windows, and Linux. One Gateway serves sessions, tools, events, and channel connections, and companion apps and nodes add voice, Canvas, camera, screen, and device-local actions.

### Is OpenClaw AI free?

There is no paid tier, hosted service, or token, and the project is stewarded by the OpenClaw Foundation, an independent 501(c)(3). The cost that remains is on your side: prompts go to whichever model provider you configure, and a daily version check is on by default until you set update.checkOnStart to false.

### How safe is OpenClaw?

The project tells you to treat inbound messages as untrusted input, and DM-capable channels pair unknown senders by default, approved with openclaw pairing approve <channel> <code>. The gap is that tools run on the host for the main session unless you configure sandboxing, so pairing alone does not contain what the model runs.

### how to install openclaw on windows

The installer supports Windows through PowerShell with iwr -useb https://openclaw.ai/install.ps1 | iex, and it provisions a supported Node.js runtime when needed. If you already manage Node, npm install -g openclaw@latest --allow-scripts=openclaw works on Node 24.16+ or 26.1+ and on npm 12 or npm 11.16+; on npm 11.15 and earlier omit the allow-scripts flag.

### how to use openclaw in whatsapp

WhatsApp is one of the supported channels, alongside Telegram, Slack, Discord, Google Chat, Signal, and iMessage. Complete onboarding, which verifies model access, creates the workspace, and configures the Gateway, then check it with openclaw gateway status and openclaw dashboard. Channel setup and troubleshooting are covered in the getting started guide.

### how to use openclaw with claude

Models and agent harnesses, including Claude, Codex, and local models, are plugins you can swap without changing anything else. OpenClaw works with both hosted and local model providers, and configuration for models, auth, and providers is documented under the model providers pages in the docs.

## Sources

- [Official documentation](https://openclaw.ai)
- [Official README](https://github.com/openclaw/openclaw#readme)
- [Project repository](https://github.com/openclaw/openclaw)
- [Release notes](https://github.com/openclaw/openclaw/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/openclaw-openclaw