$ ssh clawdbot.space --loading...
$ ssh clawdbot.space --loading...
Run OpenClaw natively on Windows using WSL2 — full Linux performance without dual-boot.
Windows Subsystem for Linux 2 (WSL2) gives you a real Linux kernel on Windows with near-native performance. This is the recommended way to run OpenClaw on Windows — no virtual machines, no dual boot, no compromises. This guide takes you from zero to a fully working OpenClaw instance in about 30 minutes.
wsl --install
wsl --set-default-version 2
wsl --update
Restart your PC after installation. On first launch, Ubuntu will ask you to create a username and password.
sudo apt update && sudo apt upgrade -y
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash - sudo apt install -y nodejs
node --version && npm --version
npx openclaw@latest
openclaw status
openclaw config set gateway.bind 127.0.0.1
Store OpenClaw data in ~/openclaw, NOT in /mnt/c/. The Windows filesystem through WSL is 5-10x slower.
Create .wslconfig in your Windows home directory to set memory limits. Default may be too low.
Add [boot] systemd=true to /etc/wsl.conf for proper service management and cron jobs.
Windows Terminal provides tabs, themes, and proper Unicode support. Much better than cmd.exe.
[wsl2] memory=4GB processors=2 swap=2GB localhostForwarding=true
WSL2 localhost forwarding works automatically. Visit http://localhost:18789 from Windows.
Use Tailscale inside WSL2 for secure remote access. Or set up port forwarding in Windows firewall.
Bots work directly from WSL2 — outbound internet access is automatic.
Windows is the platform where this choice matters most, because the three options differ in how they behave when you are not logged in. That is usually the property people care about and rarely the one they check first.
| Approach | Runs before login | Trade-off |
|---|---|---|
| Native PowerShell install | Yes, as a Scheduled Task | Simplest. Windows path semantics and tooling differences occasionally surprise Linux-oriented skills. |
| WSL2 | Only with linger plus a boot task | The most Linux-compatible runtime. Needs the extra setup below or it stops when your shell closes. |
| Windows Hub desktop app | N/A — it is a desktop app | Fine for interactive use, not for an always-on agent. |
Choose native PowerShell if you have no particular reason to want a Linux userland. Choose WSL2 if you are following Linux instructions, running tooling that expects POSIX paths, or want the same setup as your servers. The difficulty in WSL2 is not installation, it is persistence.
Two things need to be true before OpenClaw can run as a service in WSL: systemd has to be enabled, which is not the default on older installs, and the distro has to survive your shell closing.
wsl --install # or pin a distro: wsl --install -d Ubuntu-24.04
Pinning the distro is worth doing on a machine you will keep. The default changes over time and instructions that assume Ubuntu behave differently on other distributions.
sudo tee /etc/wsl.conf >/dev/null <<'EOF' [boot] systemd=true EOF
Without this, `gateway install` has no service manager to register with. This is the single most common reason the install "works" but nothing persists.
wsl --shutdown
Editing wsl.conf does nothing until the distro restarts. `wsl --shutdown` from the Windows side is the reliable way to do it.
curl -fsSL https://openclaw.ai/install.sh | bash openclaw gateway status
From here the Linux instructions apply unchanged — this is the reason to use WSL2 in the first place.
This is the part that is specific to WSL and the part that is usually missing when someone reports the gateway dying overnight. Two mechanisms are needed together: linger keeps the user's services running without a login session, and a boot task keeps the distro itself alive.
sudo apt-get install -y dbus-x11 sudo loginctl enable-linger "$(whoami)" openclaw gateway install
`enable-linger` is what allows a user service to keep running when you are not logged in. Without it, systemd tears down your services the moment your session ends.
# In an ADMINISTRATOR PowerShell on the Windows side: schtasks /create /tn "WSL Boot" ^ /tr "wsl.exe -d Ubuntu --exec dbus-launch true" ^ /sc onstart /ru "$env:USERNAME"
This must run in an Administrator PowerShell. It starts the distro at boot, before anyone logs in, which is what makes the gateway reachable from a cold start.
# On WSL 2.6.1.0 and newer use `dbus-launch true`, not `/bin/true`. # /bin/true exits immediately and WSL treats the distro as idle, # then terminates it — taking the gateway with it.
This is a real trap on WSL 2.6.1.0 and newer. `/bin/true` returns immediately, WSL concludes the distro is idle, and terminates it — so the boot task appears to work and the gateway still disappears.