Windows
OpenClaw prend en charge Windows natif et WSL2. WSL2 est le chemin le plus stable et recommandé pour l’expérience complète — la CLI, la Gateway et l’outillage s’exécutent dans Linux avec une compatibilité totale. Windows natif fonctionne pour l’usage principal de la CLI et de la Gateway, avec quelques limites indiquées ci-dessous. Des applications compagnon Windows natives sont prévues.WSL2 (recommandé)
- Bien démarrer (à utiliser dans WSL)
- Installation et mises à jour
- Guide officiel WSL2 (Microsoft) : https://learn.microsoft.com/windows/wsl/install
État de Windows natif
Les flux CLI Windows natifs s’améliorent, mais WSL2 reste le chemin recommandé. Ce qui fonctionne bien aujourd’hui sur Windows natif :- l’installateur du site via
install.ps1 - l’usage local de la CLI comme
openclaw --version,openclaw doctor, etopenclaw plugins list --json - le smoke local agent/provider intégré, par exemple :
openclaw onboard --non-interactiveattend toujours une passerelle locale joignable sauf si vous passez--skip-healthopenclaw onboard --non-interactive --install-daemonetopenclaw gateway installessaient d’abord les tâches planifiées Windows- si la création de tâche planifiée est refusée, OpenClaw se rabat sur un élément de connexion dans le dossier Startup par utilisateur et démarre immédiatement la Gateway
- si
schtaskslui-même se bloque ou cesse de répondre, OpenClaw abandonne désormais rapidement ce chemin et se rabat au lieu de rester bloqué indéfiniment - les tâches planifiées restent préférées lorsqu’elles sont disponibles car elles fournissent un meilleur état de supervision
Gateway
Installation du service Gateway (CLI)
Dans WSL2 :Démarrage automatique de la Gateway avant la connexion Windows
Pour les configurations headless, assurez-vous que toute la chaîne de démarrage fonctionne même lorsque personne ne se connecte à Windows.1) Garder les services utilisateur actifs sans connexion
Dans WSL :2) Installer le service utilisateur Gateway OpenClaw
Dans WSL :3) Démarrer WSL automatiquement au démarrage de Windows
Dans PowerShell en tant qu’administrateur :Ubuntu par le nom de votre distribution obtenu avec :
Vérifier la chaîne de démarrage
Après un redémarrage (avant la connexion Windows), vérifiez depuis WSL :Avancé : exposer les services WSL sur le LAN (portproxy)
WSL possède son propre réseau virtuel. Si une autre machine doit atteindre un service fonctionnant dans WSL (SSH, un serveur TTS local, ou la Gateway), vous devez rediriger un port Windows vers l’IP WSL actuelle. L’IP WSL change après les redémarrages, vous devrez donc peut-être actualiser la règle de redirection. Exemple (PowerShell en tant qu’administrateur) :- Le SSH depuis une autre machine cible l’IP de l’hôte Windows (exemple :
ssh user@windows-host -p 2222). - Les nœuds distants doivent pointer vers une URL Gateway joignable (pas
127.0.0.1) ; utilisezopenclaw status --allpour confirmer. - Utilisez
listenaddress=0.0.0.0pour l’accès LAN ;127.0.0.1le garde uniquement en local. - Si vous voulez automatiser cela, enregistrez une tâche planifiée pour exécuter l’étape de rafraîchissement à la connexion.