Windows Setup and Support

OpenClaw provides a native Windows Hub companion application as well as Windows CLI support. For a desktop experience with setup, tray status, chat, Command Center diagnostics, and Windows node features, Windows Hub is the right choice. The PowerShell installer handles the CLI and Gateway directly, while WSL2 offers the closest match to a Linux Gateway runtime.

Recommended: Windows Hub

Windows Hub serves as the native WinUI companion app for Windows 10 20H2 and later, plus Windows 11. No administrator rights are needed for installation, and both signed x64 and ARM64 installers are available from its dedicated release page.

The release cadence for Windows Hub is independent of the OpenClaw CLI and Gateway. Grab the newest stable Hub installer from the Windows Hub releases page or use the direct links via releases/latest/download:

Should any of those links return a 404, head to the Windows Hub releases page and pick the latest stable Windows Hub release. The regular OpenClaw stable releases also carry a pinned, release-validated Windows Hub build, though that mirror may trail a newer standalone Hub release.

Once installed, launch OpenClaw Companion from the Start menu or the system tray. Shortcuts for Gateway Setup, Chat, Settings, Check for Updates, and uninstall are added by the installer as well.

What Windows Hub includes

Tray icon status and automatic startup at login.
Guided first-run setup for a local, app-managed WSL Gateway.
Connection options covering local, remote, and SSH-tunneled Gateways.
A built-in chat window, with browser-based Control UI access.
Command Center diagnostics spanning sessions, usage, channels, nodes, pairing, and repair operations.
Windows node mode handling screen, camera, notifications, device status, talk, and managed system.run.
Local MCP server mode for MCP clients like Claude Desktop, Claude Code, and Cursor.

First launch

When Windows Hub starts for the first time and no usable saved Gateway exists, setup appears automatically. The quickest route is Set up locally, which provisions an app-owned OpenClawGateway WSL distro, installs the Gateway within it, and pairs the app. Your existing Ubuntu distro is left untouched and unmodified.

If you already have a Gateway, pick Advanced setup or go to the Connections tab. Connections can be made to:

a Gateway running locally on this machine
a WSL-based Gateway on this machine
a remote Gateway using a URL plus token or setup code
a Gateway reachable via an SSH tunnel

After setup completes, the tray icon changes to green. From the tray, open Command Center to verify connection, pairing, node status, and channel health.

Windows node mode

Windows Hub is able to register as an OpenClaw node, letting the agent use declared Windows-native capabilities through the Gateway. Node commands only execute after being declared by the node and permitted by Gateway policy; the full allow/deny model is described in Nodes.

Common commands:

Family	Commands
Screen	`screen.snapshot`; `screen.record` requires explicit opt-in
Camera	`camera.list`; `camera.snap`, `camera.clip` require explicit opt-in
System	`system.notify`, `system.run`, `system.run.prepare`, `system.which`
Device	`location.get`, `device.info`, `device.status`
Talk	`talk.ptt.start`, `talk.ptt.stop`, `talk.ptt.cancel`, `talk.ptt.once`, `talk.speak`

Gateway pairing is a prerequisite for node mode. When a pairing request appears in the app, approve it from the Gateway host:

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

Commands are forwarded by the Gateway only when the node declares them and server policy allows. Privacy-sensitive operations such as screen.record, camera.snap, and camera.clip demand explicit gateway.nodes.commands.allow opt-in.

Local MCP mode

The same Windows-native capability registry can be exposed by Windows Hub as a local MCP server on loopback. This lets local MCP clients drive Windows capabilities without needing a running OpenClaw Gateway.

Look for the developer/advanced section in Windows Hub Settings to enable it. Once active, the app displays the loopback endpoint and bearer token.

Mode matrix:

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

Native Windows CLI and Gateway

For those who prefer the terminal, OpenClaw installs from PowerShell:

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

Verify with:

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

Windows Scheduled Tasks power managed startup when they are available. The readable gateway.cmd script stays in the OpenClaw state dir, but the task invokes it through a generated gateway.vbs WScript wrapper, so the background Gateway avoids showing a visible console window. If task creation gets denied, OpenClaw falls back to a per-user Startup-folder login item.

Install the Gateway service:

openclaw gateway install
openclaw gateway status --json

For CLI-only usage without a managed Gateway service:

openclaw onboard --non-interactive --accept-risk --skip-health
openclaw gateway run

WSL2 Gateway

On Windows, WSL2 remains the Gateway runtime with the best Linux compatibility. Windows Hub can create an app-owned WSL Gateway automatically, or you can install manually within your own distro.

Manual setup:

wsl --install
# Or pick a distro explicitly:
wsl --list --online
wsl --install -d Ubuntu-24.04

Turn on systemd inside WSL:

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

Restart WSL from PowerShell:

wsl --shutdown

After that, install OpenClaw inside WSL using the Linux quickstart:

curl -fsSL https://openclaw.ai/install.sh | bash
openclaw gateway status

For headless WSL configurations, confirm the entire boot chain runs even when no user is logged into Windows.

Inside WSL:

sudo apt-get install -y dbus-x11
sudo loginctl enable-linger "$(whoami)"
openclaw gateway install

In PowerShell as Administrator:

schtasks /create /tn "WSL Boot" /tr "wsl.exe -d Ubuntu --exec dbus-launch true" /sc onstart /ru "$env:USERNAME"

Swap Ubuntu for your distro name, which you can find from:

wsl --list --verbose

Note

Two differences from older recipes:

dbus-launch true in place of /bin/true: on WSL >= 2.6.1.0 a regression (microsoft/WSL #13416) idle-terminates the distro 15-20 seconds after the last client exits, even with linger enabled. dbus-launch true keeps a child-of-init process alive as a workaround (community discussion, microsoft/WSL #9245).

/ru "$env:USERNAME" in place of /ru SYSTEM: per-user WSL distros (the default setup) are not visible to the SYSTEM account, so the task appears to run but the distro never starts. Running as your own account avoids this; Windows prompts for your password when the task is created.

After a reboot, verify from WSL:

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

Expose WSL services over LAN

WSL operates on its own virtual network. To let an external machine reach a service running inside WSL, map a Windows port to the WSL instance's current IP address. Since that IP can shift after a reboot, update the port forwarding rule whenever necessary.

Run this in PowerShell with administrator privileges:

$Distro = "Ubuntu-24.04"
$ListenPort = 2222
$TargetPort = 22

$WslIp = (wsl -d $Distro -- hostname -I).Trim().Split(" ")[0]
if (-not $WslIp) { throw "WSL IP not found." }

netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=$ListenPort `
  connectaddress=$WslIp connectport=$TargetPort

New-NetFirewallRule -DisplayName "WSL SSH $ListenPort" -Direction Inbound `
  -Protocol TCP -LocalPort $ListenPort -Action Allow

Points to remember:

When connecting via SSH from another machine, use the Windows host IP, such as ssh user@windows-host -p 2222.
For remote nodes, the Gateway URL must be reachable, so avoid 127.0.0.1.
Choose listenaddress=0.0.0.0 when accessing over LAN, or 127.0.0.1 if only local access is needed.

Troubleshooting

The tray icon does not appear

Look in Task Manager for OpenClaw.Tray.WinUI.exe. When it appears, reveal the hidden tray-icons section and pin it there. Otherwise, launch OpenClaw Companion from the Start menu.

Local setup fails

Check the setup log via Windows Hub, or look at:

notepad "$env:LOCALAPPDATA\OpenClawTray\Logs\Setup\easy-setup-latest.txt"

Typical culprits include a disabled WSL, virtualization being blocked, stale WSL state owned by the app, or a network problem during Gateway package installation.

The app says pairing is required

Accept the operator or node request through the Gateway:

openclaw devices list
openclaw devices approve <requestId>

If a token already existed on the device, reconnect from the Connections tab once approval is complete.

Web chat cannot reach a remote Gateway

Remote web chat requires HTTPS or localhost. With self-signed certificates, either trust the certificate within Windows or set up an SSH tunnel pointing to a localhost URL.

`screen.snapshot`, camera, or audio commands fail

Verify Windows permissions for camera, microphone, screen capture, and notifications. Packaged installs declare the protected capabilities, yet Windows might still ask for consent the first time a command accesses them.

Git or GitHub connectivity fails

Certain networks block or slow down HTTPS traffic to GitHub. If git clone or gh auth login does not succeed, switch networks, use a VPN, or route through an HTTP/HTTPS proxy.

For token-based gh authentication in the active session:

$env:GH_TOKEN="<your-token>"
gh auth status
gh auth setup-git

Never store tokens in commits, and avoid pasting them into issues or pull requests.