Platforms overview
Windows
OpenClaw unterstützt sowohl natives Windows als auch WSL2. WSL2 ist der stabilere Weg und wird für die vollständige Erfahrung empfohlen — CLI, Gateway und Tooling laufen mit vollständiger Kompatibilität innerhalb von Linux. Natives Windows funktioniert für die Kernnutzung von CLI und Gateway, mit einigen unten aufgeführten Einschränkungen.
Native Windows-Begleit-Apps sind geplant.
WSL2 (empfohlen)
- Erste Schritte (innerhalb von WSL verwenden)
- Installation und Updates
- Offizielle WSL2-Anleitung (Microsoft): https://learn.microsoft.com/windows/wsl/install
Status unter nativem Windows
CLI-Flows unter nativem Windows werden verbessert, aber WSL2 ist weiterhin der empfohlene Weg.
Was heute unter nativem Windows gut funktioniert:
- Website-Installer über
install.ps1 - lokale CLI-Nutzung wie
openclaw --version,openclaw doctorundopenclaw plugins list --json - eingebetteter lokaler Agent/Provider-Smoke-Test wie:
openclaw agent --local --agent main --thinking low -m "Reply with exactly WINDOWS-HATCH-OK."
Aktuelle Einschränkungen:
openclaw onboard --non-interactiveerwartet weiterhin ein erreichbares lokales Gateway, sofern Sie nicht--skip-healthübergebenopenclaw onboard --non-interactive --install-daemonundopenclaw gateway installversuchen zuerst Windows Scheduled Tasks- wenn das Erstellen eines Scheduled Task verweigert wird, fällt OpenClaw auf ein Login-Element im Startup-Ordner des aktuellen Benutzers zurück und startet das Gateway sofort
- wenn
schtasksselbst hängen bleibt oder nicht mehr reagiert, bricht OpenClaw diesen Pfad jetzt schnell ab und verwendet den Fallback, statt unbegrenzt zu hängen - Scheduled Tasks werden weiterhin bevorzugt, wenn sie verfügbar sind, weil sie einen besseren Supervisor-Status bereitstellen
Wenn Sie nur die native CLI ohne Installation des Gateway-Dienstes möchten, verwenden Sie eines hiervon:
openclaw onboard --non-interactive --skip-health
openclaw gateway run
Wenn Sie einen verwalteten Start unter nativem Windows möchten:
openclaw gateway install
openclaw gateway status --json
Wenn das Erstellen eines Scheduled Task blockiert ist, startet der Fallback-Dienstmodus nach der Anmeldung weiterhin automatisch über den Startup-Ordner des aktuellen Benutzers.
Gateway
Gateway-Dienst installieren (CLI)
Innerhalb von WSL2:
openclaw onboard --install-daemon
Oder:
openclaw gateway install
Oder:
openclaw configure
Wählen Sie Gateway-Dienst, wenn Sie dazu aufgefordert werden.
Reparieren/migrieren:
openclaw doctor
Gateway-Autostart vor der Windows-Anmeldung
Stellen Sie bei Headless-Setups sicher, dass die vollständige Boot-Kette auch dann läuft, wenn sich niemand bei Windows anmeldet.
1) Benutzerdienste ohne Anmeldung weiterlaufen lassen
Innerhalb von WSL:
sudo loginctl enable-linger "$(whoami)"
2) OpenClaw-Gateway-Benutzerdienst installieren
Innerhalb von WSL:
openclaw gateway install
3) WSL beim Windows-Start automatisch starten
In PowerShell als Administrator:
schtasks /create /tn "WSL Boot" /tr "wsl.exe -d Ubuntu --exec /bin/true" /sc onstart /ru SYSTEM
Ersetzen Sie Ubuntu durch den Namen Ihrer Distribution aus:
wsl --list --verbose
Startkette überprüfen
Prüfen Sie nach einem Neustart (vor der Windows-Anmeldung) aus WSL:
systemctl --user is-enabled openclaw-gateway.service
systemctl --user status openclaw-gateway.service --no-pager
Erweitert: WSL-Dienste über das LAN verfügbar machen (portproxy)
WSL hat ein eigenes virtuelles Netzwerk. Wenn ein anderer Rechner einen Dienst erreichen muss, der innerhalb von WSL läuft (SSH, ein lokaler TTS-Server oder das Gateway), müssen Sie einen Windows-Port an die aktuelle WSL-IP weiterleiten. Die WSL-IP ändert sich nach Neustarts, daher müssen Sie die Weiterleitungsregel möglicherweise aktualisieren.
Beispiel (PowerShell als Administrator):
$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
Lassen Sie den Port durch die Windows-Firewall zu (einmalig):
New-NetFirewallRule -DisplayName "WSL SSH $ListenPort" -Direction Inbound `
-Protocol TCP -LocalPort $ListenPort -Action Allow
Aktualisieren Sie den portproxy nach WSL-Neustarts:
netsh interface portproxy delete v4tov4 listenport=$ListenPort listenaddress=0.0.0.0 | Out-Null
netsh interface portproxy add v4tov4 listenport=$ListenPort listenaddress=0.0.0.0 `
connectaddress=$WslIp connectport=$TargetPort | Out-Null
Hinweise:
- SSH von einem anderen Rechner zielt auf die Windows-Host-IP (Beispiel:
ssh user@windows-host -p 2222). - Remote-Knoten müssen auf eine erreichbare Gateway-URL zeigen (nicht
127.0.0.1); verwenden Sieopenclaw status --allzur Bestätigung. - Verwenden Sie
listenaddress=0.0.0.0für LAN-Zugriff;127.0.0.1hält ihn nur lokal. - Wenn Sie dies automatisieren möchten, registrieren Sie einen Scheduled Task, der den Aktualisierungsschritt bei der Anmeldung ausführt.
Schrittweise WSL2-Installation
1) WSL2 + Ubuntu installieren
Öffnen Sie PowerShell (Admin):
wsl --install
# Or pick a distro explicitly:
wsl --list --online
wsl --install -d Ubuntu-24.04
Starten Sie neu, wenn Windows Sie dazu auffordert.
2) systemd aktivieren (für die Gateway-Installation erforderlich)
In Ihrem WSL-Terminal:
sudo tee /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
EOF
Dann aus PowerShell:
wsl --shutdown
Öffnen Sie Ubuntu erneut und prüfen Sie dann:
systemctl --user status
3) OpenClaw installieren (innerhalb von WSL)
Folgen Sie für eine normale Ersteinrichtung innerhalb von WSL dem Linux-Flow für Erste Schritte:
git clone https://github.com/openclaw/openclaw.git
cd openclaw
pnpm install
pnpm build
pnpm ui:build
pnpm openclaw onboard --install-daemon
Wenn Sie statt des ersten Onboardings aus dem Quellcode entwickeln, verwenden Sie den Source-Dev-Loop aus Einrichtung:
pnpm install
# First run only (or after resetting local OpenClaw config/workspace)
pnpm openclaw setup
pnpm gateway:watch
Vollständige Anleitung: Erste Schritte
Windows-Begleit-App
Wir haben noch keine Windows-Begleit-App. Beiträge sind willkommen, wenn Sie helfen möchten, sie umzusetzen.
Git- und GitHub-Konnektivität (Mitwirkende)
Einige Netzwerke blockieren oder drosseln HTTPS zu GitHub. Wenn git clone mit Timeouts
oder Verbindungsabbrüchen fehlschlägt, versuchen Sie ein anderes Netzwerk, ein VPN oder einen HTTP/HTTPS-Proxy, den Ihre
Organisation bereitstellt.
Wenn gh auth login während des Browser-Device-Flows fehlschlägt (zum Beispiel durch ein Timeout
beim Erreichen von github.com:443), authentifizieren Sie sich stattdessen mit einem persönlichen Zugriffstoken:
- Erstellen Sie ein Token mit mindestens dem
repo-Scope (klassischer PAT) oder entsprechendem fein abgestuftem Zugriff. - In PowerShell für die aktuelle Sitzung:
$env:GH_TOKEN="<your-token>"
gh auth status
gh auth setup-git
- Wenn
gh auth statusvor fehlendemread:orgwarnt, erstellen Sie ein Token, das diesen Scope enthält, und weisen Sie die Variable erneut zu:
$env:GH_TOKEN="<your-token-with-repo-and-read:org>"
gh auth status
gh auth refresh -s read:org gilt nur, wenn Sie sich über gh auth login
authentifiziert haben und gespeicherte Anmeldedaten zum Aktualisieren vorhanden sind (nicht bei Verwendung von GH_TOKEN).
Committen Sie niemals Tokens und fügen Sie sie nicht in Issues oder Pull Requests ein.