2026 OpenClaw on Windows: reproducible PowerShell setup, WSL2 trade-offs, Gateway persistence, and tiered PATH / doctor troubleshooting (FAQ)

Windows is still a common desk OS for GUI-first operators. OpenClaw’s CLI, optional Gateway, and token-backed channels are manageable once PATH, elevation, and “who starts the daemon” are explicit. Here we focus on reproducible installs: PowerShell scripting patterns, WSL2 trade-offs, how Windows Gateway persistence differs from Linux systemd, and tiered PATH / doctor triage so tickets stay comparable across hosts.

Reproducible install: PowerShell “one shot” patterns

Capture the happy path in a script that pins assumptions: execution policy for the current process, a dedicated install directory, a single Node major, and an append-only log. Idempotency beats brevity — reruns after partial failure must not duplicate PATH entries or orphan side-by-side copies.

# Run in Windows PowerShell 5.1 or pwsh — pick one and stick to it in docs
$ErrorActionPreference = 'Stop'
$installRoot = "$env:LOCALAPPDATA\openclaw-toolchain"
$log = "$installRoot\install.log"
New-Item -ItemType Directory -Force -Path $installRoot | Out-Null
"--- $(Get-Date -Format o) ---" | Out-File -FilePath $log -Append
# fetch / verify checksum / unpack exactly here — then:
$bin = "$installRoot\current\bin"
$userPath = [Environment]::GetEnvironmentVariable('Path','User')
if ($userPath -notlike "*$bin*") {
  [Environment]::SetEnvironmentVariable('Path', "$userPath;$bin", 'User')
}

Document whether operators need a new terminal after PATH changes — many “CLI vanished” tickets are stale handles. Ship a tiny manifest (Node major, OpenClaw build id, Gateway port) so support can diff hosts without a call.

PowerShell on Windows vs WSL2: where to run OpenClaw

WSL2 offers a Linux-shaped tree and syscalls, so curl | bash examples feel familiar. You pay for split DNS, an extra hop, and two PATH universes: Ubuntu success does not imply a Windows Scheduled Task calling the Win32 binary will behave the same. Pick one primary runtime per role — e.g. native Windows for desk operators, WSL2 only for staff already container-first.

For parity with what we ship on servers, compare this matrix to our Linux VPS walkthrough: 2026 OpenClaw Linux cloud VPS hands-on: curl install vs Docker, environment checks, and common errors FAQ.

Gateway persistence: Windows is not Linux

On Linux, always-on Gateway is usually systemd with Restart=on-failure and journald. Windows uses the Service Control Manager, Task Scheduler, or wrappers — each with different credentials, cwd, and env blocks. Common pitfall: a service as LOCAL SERVICE without the same user PATH the admin used in an elevated PowerShell test.

Reuse the same mental checklist: binary path, config path, writable data dir, bind interface, outbound HTTPS, token file ACLs. Linux-side log, port, and probe tiers are spelled out in 2026 OpenClaw Linux production troubleshooting: systemd, openclaw logs, gateway port probes — tiered FAQ; on Windows, swap journald for Event Log, task history, and logs you wire yourself.

PATH and doctor: tiered triage so tickets stay comparable

We label steps L0–L3 so two engineers see the same ticket state. L0: which shell — profile, elevation, WSL vs PowerShell tab. L1: Get-Command openclaw / where.exe openclaw plus openclaw --version. L2: shipped doctor checks — config path, Node ABI, outbound probe, optional bind self-test. L3: redacted env, firewall snippet, last 200 lines of the install log.

Version doctor severity in your runbook when checks flip warning → error so dashboards stay consistent. On domain-joined PCs, note GPOs that rewrite PATH — that alone explains many “it worked Friday” regressions.