Windows
OpenClaw unterstützt sowohl natives Windows als auch WSL2. WSL2 ist der stabilere Weg und wird für das vollständige Nutzungserlebnis empfohlen — CLI, Gateway und Tooling laufen innerhalb von Linux mit vollständiger Kompatibilität. Natives Windows funktioniert für die zentrale CLI- und Gateway-Nutzung, mit einigen unten genannten Einschränkungen. Native Windows-Begleit-Apps sind geplant.WSL2 (empfohlen)
- Erste Schritte (innerhalb von WSL verwenden)
- Installation & Updates
- Offizielle WSL2-Anleitung (Microsoft): https://learn.microsoft.com/windows/wsl/install
Status von nativem Windows
Native Windows-CLI-Abläufe 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 - eingebettete lokale Agent-/Provider-Smoke-Tests wie zum Beispiel:
openclaw onboard --non-interactiveerwartet weiterhin ein erreichbares lokales Gateway, sofern Sie nicht--skip-healthübergebenopenclaw onboard --non-interactive --install-daemonundopenclaw gateway installversuchen zuerst Windows-Aufgabenplanung- wenn das Erstellen geplanter Aufgaben verweigert wird, greift OpenClaw auf ein anmeldungsbasiertes Startelement im Startup-Ordner pro Benutzer zurück und startet das Gateway sofort
- wenn
schtasksselbst hängen bleibt oder nicht mehr reagiert, bricht OpenClaw diesen Pfad jetzt schnell ab und nutzt stattdessen den Fallback, anstatt dauerhaft hängen zu bleiben - Geplante Aufgaben werden weiterhin bevorzugt, wenn sie verfügbar sind, weil sie einen besseren Supervisor-Status bereitstellen
Gateway
Installation des Gateway-Dienstes (CLI)
Innerhalb von WSL2:Gateway-Autostart vor der Windows-Anmeldung
Stellen Sie für Headless-Setups sicher, dass die vollständige Startkette läuft, auch wenn sich niemand bei Windows anmeldet.1) Benutzerdienste ohne Anmeldung weiterlaufen lassen
Innerhalb von WSL:2) Den OpenClaw-Gateway-Benutzerdienst installieren
Innerhalb von WSL:3) WSL beim Windows-Start automatisch starten
In PowerShell als Administrator:Ubuntu durch Ihren Distributionsnamen aus:
Startkette überprüfen
Überprüfen Sie nach einem Neustart (vor der Windows-Anmeldung) aus WSL:Erweitert: WSL-Dienste über das LAN verfügbar machen (portproxy)
WSL hat sein 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):
portproxy, nachdem WSL neu gestartet wurde:
- SSH von einem anderen Rechner richtet sich an die IP des Windows-Hosts (Beispiel:
ssh user@windows-host -p 2222). - Remote-Nodes müssen auf eine erreichbare Gateway-URL verweisen (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 es nur lokal. - Wenn Sie dies automatisieren möchten, registrieren Sie eine geplante Aufgabe, um den Aktualisierungsschritt bei der Anmeldung auszuführen.