🦞AIClawGuide
Community Guide

Install OpenClaw on Windows

The practical Windows path for OpenClaw: use WSL2, enable systemd, install the Gateway inside Linux, and avoid the common Windows-first mistakes.

Mar 19, 2026

OpenClaw on Windows is currently best treated as a Linux install running inside Windows.

That is not a workaround. It is the recommended path in the official platform docs because it keeps the runtime, tooling, and service model consistent with the rest of the project.

The practical rule is simple:

  • use WSL2
  • use Ubuntu unless you already know you need another distro
  • run the CLI and Gateway inside Linux

If you fight that model, you usually create problems that are not really OpenClaw problems.

Why WSL2 is the right default

WSL2 solves the parts that are awkward in native Windows-first setups:

  • Node, pnpm, Bun, and Linux tooling behave normally
  • systemd user services work the way the docs expect
  • browser, skills, and gateway operations match the main docs better
  • future debugging is much easier because you are closer to the standard install path

If your goal is “get OpenClaw working reliably,” WSL2 is the shortest route.

Before you start

Confirm these assumptions first:

  • your Windows machine supports WSL2
  • you are willing to use Ubuntu or another Linux distro inside WSL
  • Node 22 or newer will be installed inside WSL, not only on Windows
  • you want the Gateway to run inside WSL

If you are still at the very beginning, read the root install guide first:

Step 1: Install WSL2 and a Linux distro

From PowerShell as Administrator:

wsl --install

If you want to choose a distro explicitly:

wsl --list --online
wsl --install -d Ubuntu-24.04

After setup, open the Linux terminal and continue the rest of the install there.

Step 2: Enable systemd inside WSL

OpenClaw’s service install on Linux and WSL2 depends on systemd user services. If systemd is disabled, the daemon experience will feel broken even when the binary itself works.

Inside WSL:

sudo tee /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
EOF

Then from PowerShell:

wsl --shutdown

Open WSL again and verify:

systemctl --user status

Step 3: Install OpenClaw inside WSL

Once you are inside Linux, follow the normal supported setup flow:

curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon

That matters because the onboarding wizard is the real setup path. It handles:

  • auth and model setup
  • workspace creation
  • Gateway install
  • health checks
  • optional channel setup

If you prefer the slower but more explicit route, the official docs also describe from-source setup inside WSL. For most users, start with the normal install flow first.

Step 4: Verify the Gateway from inside WSL

Before you touch channels or remote exposure, make sure the base install is healthy:

openclaw gateway status
openclaw status
openclaw doctor
openclaw dashboard

What you want to confirm:

  • the Gateway is running
  • the service install succeeded
  • the Control UI works
  • diagnostics do not show an obvious config problem

If this stage is unstable, keep debugging inside WSL first. Do not jump ahead to Windows networking.

How service install works on Windows

Inside WSL2, OpenClaw uses the Linux service model, not a native Windows service model.

That means:

  • the Gateway service is a systemd user unit
  • openclaw onboard --install-daemon or openclaw gateway install is the right path
  • the service health should be checked from inside WSL

That is normal. Think “Linux service hosted by Windows,” not “Windows app with Linux attached.”

Auto-start before Windows login

If you want a more headless setup, the official platform docs describe a boot chain that works before user login.

Inside WSL:

sudo loginctl enable-linger "$(whoami)"
openclaw gateway install

Then in PowerShell as Administrator:

schtasks /create /tn "WSL Boot" /tr "wsl.exe -d Ubuntu --exec /bin/true" /sc onstart /ru SYSTEM

After reboot, verify again inside WSL:

systemctl --user is-enabled openclaw-gateway
systemctl --user status openclaw-gateway --no-pager

Only do this if you really need the service before interactive login. For many users, normal WSL startup is enough.

Exposing WSL services over your LAN

WSL uses its own virtual network. If another machine needs to reach a service running inside WSL, you cannot rely on 127.0.0.1 from the other machine.

The official docs recommend using Windows port forwarding when necessary.

The operational lesson is simple:

  • use loopback when access should stay local
  • use Windows port proxy only when another machine truly needs access
  • point remote nodes at a reachable host, not 127.0.0.1

If you are not sure you need LAN access yet, do not add it during the first install.

Common Windows mistakes

Installing only on Windows and not inside WSL

That leaves you with a mismatch between the supported runtime model and the machine you are actually operating.

Forgetting systemd

Without systemd, service install and restart behavior will not match the docs.

Treating the first install like a networking project

First make the Gateway work inside WSL. Only then think about port proxy, remote access, or public exposure.

Using 127.0.0.1 where another device needs a reachable host

This is one of the most common WSL networking mistakes.

FAQ

Is Windows supported?

Yes, through WSL2. That is the recommended path today.

Do I need to run OpenClaw natively on Windows?

No. The preferred model is to run the CLI and Gateway inside Linux under WSL2.

Should I use the onboarding wizard on Windows?

Yes. Use it inside WSL after the CLI is installed. It is still the recommended setup path.

Is there a native Windows companion app?

Not as the main supported route today. The current docs frame Windows primarily through WSL2.

Where to go next