OpenClaw setup, step by step
Install, onboarding, the Gateway service, first message
Setting up OpenClaw is one line to install and a handful of commands after it, and the docs promise a working chat in about five minutes. That holds when the machine already has what it needs. The rest of this guide is what each step actually does, where people stall, and which choices you make once and then live with.
Before you start
- Node.js 24.16 or newer, with 26 the runtime the docs recommend. Check it before you begin; the missing-module loop on Windows usually starts here.
- AI access: an existing Claude Code or Codex CLI login, or a provider API key. Onboarding reuses what it finds and verifies it with a real completion before anything else is configured.
- A machine that will stay on, if you want the assistant to answer when you are not at the keyboard. No installer covers this step.
The five steps
- Install: one curl line on macOS and Linux, one PowerShell line on Windows. The installer starts the onboarding wizard on its own.
- Onboard: Quick start reuses detected AI access and opens the web dashboard; Custom setup walks through every option; the classic wizard adds channels, skills and a remote Gateway.
- Install the Gateway service. Quick start leaves the Gateway in the foreground of your terminal, so stop it and install the service: a LaunchAgent on macOS, a systemd user unit on Linux and WSL2, a Scheduled Task on Windows.
- Verify: the status command should show the Gateway listening on port 18789, and the dashboard command opens the Control UI in your browser.
- Send the first message in the Control UI, then connect a channel. Telegram is the fastest, a bot token and nothing else.
Onboarding establishes inference first and only then configures the rest. It never selects an existing subscription on its own, it does not download models, and a fresh local setup defaults to the coding tool profile, which keeps filesystem and runtime tools without the unrestricted full profile. Those three defaults are the ones worth knowing before you change them.
Where people stall
- Missing modules on Windows, one after another. The docs point at WSL2 or the Windows Hub app for exactly that case.
- A Gateway that only runs while the terminal is open, because the service step was skipped.
- A bot that does not answer, because the first pairing request was never approved or the group needs a mention.
The install is one line. Getting it production-stable is a different sport.
If setup does not work
One command turns the state of the install into a diagnosis: triage runs read-only health checks, writes a sanitised prompt describing what it found, and offers to hand it to a coding agent it detects on your machine. Nothing leaves the machine until you choose one, and secrets and raw logs are excluded. OpenClaw not responding is the symptom-first version of the same ladder.
Or skip the machine
The five steps are the same on every platform, and so is the sixth, unwritten one: keeping the Gateway alive, updated and paid for. Hosted OpenClaw on Diali does that part on an isolated instance in the EU, and you start at the first message. If you are on Windows, the Windows guide is the honest map of the three install paths.
- Install, onboard, install the service, verify, message.
- Inference is verified before anything else is configured.
- The machine that stays on is the step you decide, not the installer.
Stop reading about it, build one
Set up an agent, pick a channel, and have it working inside the app you already keep open.
