OpenClaw on Windows: three setup paths and how to pick the right one

By Jeff, Windows & Microsoft Ecosystem

If you have been waiting for a clean, native way to run OpenClaw on Windows, the wait is over. OpenClaw now ships three officially supported paths on Windows 10 and Windows 11: a signed Windows Hub desktop app, a PowerShell CLI/Gateway installer, and a full WSL2 Gateway for the most Linux-compatible runtime. Each path lands on the same Gateway, so you can start with the Hub and later switch to PowerShell, or vice versa, without rebuilding your world.

This post walks through the three options, when each makes sense, and the small but important details that keep first-run setup smooth.

The TL;DR

Want a desktop app? Use Windows Hub. It installs without admin rights, adds a system tray icon, and can provision its own app-owned WSL Gateway behind the scenes.
Live in PowerShell or Windows Terminal? Use the PowerShell installer. One line gets you the same CLI and Gateway that macOS and Linux users run.
Need the most Linux-compatible runtime? Use WSL2. Run the Linux installer inside your distro for full systemd service support.

All three require a supported Node runtime: Node 26 is recommended, with Node 25.9+, 24.15+, and 22.22.3+ also supported. Node 23 is not supported.

Path 1: Windows Hub (best for most people)

Windows Hub is the newest and most Windows-native option. It is a signed WinUI companion app that publishes independently from the OpenClaw CLI and Gateway, so it can move faster on Windows-specific features.

Download the x64 or ARM64 installer from the official Windows Hub releases page:

The installer is per-user and does not require administrator privileges. After launch, the tray icon gives you quick access to Chat, Settings, Command Center diagnostics, and Check for Updates.

On first run, if no Gateway is configured, Hub opens Set up locally. This creates a dedicated OpenClawGateway WSL distro, installs the Gateway inside it, and pairs the app automatically. It does not touch your existing Ubuntu or other WSL distros, so your developer environment stays intact.

If you already have a Gateway running elsewhere, use Advanced setup or the Connections tab to point Hub at:

a local Gateway on the same PC,
a WSL Gateway you manage yourself,
a remote Gateway by URL and token or setup code,
or a Gateway reached through an SSH tunnel.

Once the tray icon turns green, open Command Center to confirm the connection, pairing status, node health, and channel state before you add Telegram, WhatsApp, Discord, Microsoft Teams, or other channels.

Windows node mode and local MCP mode

Windows Hub can register the PC as an OpenClaw node, which lets the agent use Windows-native capabilities through the Gateway. The available surface includes screen snapshots, camera access, system notifications, device status, text-to-speech, and controlled system.run execution. Commands must be declared by the node and allowed by Gateway policy, and privacy-sensitive commands such as screen.record, camera.snap, and camera.clip require an explicit opt-in.

Hub can also expose the same capability registry as a local MCP server on loopback. That means Claude Desktop, Claude Code, and Cursor can drive Windows capabilities without a running OpenClaw Gateway at all. The mode matrix is simple:

Node mode	MCP server	Behavior
off	off	Operator-only desktop app
on	off	Gateway-connected Windows node
off	on	Local MCP server only
on	on	Gateway node plus local MCP server

If you pair Hub with a Gateway and the Gateway asks for approval, use the Gateway host:

openclaw devices list
openclaw devices approve <requestId>
openclaw nodes status

Path 2: PowerShell CLI + Gateway (best for terminal-first users)

If you already spend your day in PowerShell or Windows Terminal, this path keeps you in familiar territory. It installs the same OpenClaw CLI and Gateway used on macOS and Linux, but uses the official PowerShell installer and a Windows Scheduled Task for managed background startup.

Open a new PowerShell window and run:

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

The installer detects Windows, provisions a supported Node runtime if needed, installs the stable OpenClaw package, and launches onboarding. If you manage Node yourself, keep it in the supported range.

After installation, open a new PowerShell window so PATH updates take effect, then verify:

openclaw --version
openclaw doctor
openclaw gateway status --json

The Gateway runs as a Windows Scheduled Task with no visible console window. The task launches a generated gateway.vbs WScript wrapper, which in turn runs the readable gateway.cmd script stored in your OpenClaw state directory. If Windows Scheduled Tasks are unavailable or denied, OpenClaw falls back to a per-user Startup folder login item.

A quick tip from the docs: if you ever edit gateway.cmd to redirect output, quote the entire target. For example:

>> "%USERPROFILE%\.openclaw\logs\gateway-stdout.log" 2>&1

Unquoted environment expansions can leave stray filename fragments in the Gateway's arguments, which leads to confusing ownership checks.

Path 3: WSL2 Gateway (best for Linux-native tooling)

WSL2 is the right choice when you want the most Linux-compatible Gateway runtime, systemd service support, and the exact same tooling your Linux teammates use.

Inside your WSL2 distro, run the Linux installer:

curl -fsSL --proto '=https' --tlsv1.2 https://openclaw.ai/install.sh | sh

Then verify and start the Gateway:

openclaw --version
openclaw doctor
openclaw gateway up

This path behaves almost identically to a native Linux install. You get systemd service management, the standard Linux state directory layout, and the same shell installer flags. If you run into OAuth or Git integration issues that seem WSL-specific, switching to the native PowerShell path or Windows Hub often clears them up, because those paths run the Gateway directly on Windows rather than inside the WSL networking boundary.

Common first-run gotchas

Node version mismatch. The most common Windows install failure is a Node version that looks recent but is not in the supported range. Node 23, for example, is not supported. If openclaw doctor complains about Node, use a version manager like nvm-windows or fnm, or let the installer provision Node 26 for you.

PowerShell Execution Policy. The installer may fail if your execution policy blocks unsigned scripts. You can inspect your current policy with Get-ExecutionPolicy and, if necessary, run the installer from a session that allows remote signed scripts. The official OpenClaw docs have a dedicated troubleshooting page for this scenario.

PATH not refreshed. After installation, open a new PowerShell or terminal window. The openclaw command will not be available in the same shell session that ran the installer.

WSL OAuth quirks. A few users have reported that GitHub OAuth flows fail inside WSL because of networking or browser-launch differences. If that happens, the Windows Hub or native PowerShell path is the simpler fix.

Confusing device pairing with node approval. Remember that device pairing and node surface approval are separate steps. Approve the device request first, then reconnect, and then approve the node request. The two IDs are different.

How to choose

You want...	Recommended path
A normal desktop app with tray status	Windows Hub
The fastest path from download to chat	Windows Hub
Scriptable, reproducible, terminal-first setup	PowerShell installer
Same runtime as macOS/Linux teammates	WSL2 Gateway
Windows-native screen, camera, and MCP access	Windows Hub
No WSL at all	Windows Hub or PowerShell installer

Bottom line

Windows is no longer a second-class OpenClaw citizen. Whether you want a polished desktop companion, a PowerShell-native CLI, or a full WSL2 Gateway, there is now a first-party path that fits. Start with the one that matches how you work, run openclaw doctor to confirm everything is healthy, and then connect your first channel. The agent will meet you where you already are: on Windows.

Have a favorite Windows + OpenClaw tip? Drop it in the comments. I read every one.