OpenClaw prend en charge à la fois Windows natif et WSL2. WSL2 est le chemin le plus stable et recommandé pour l’expérience complète : la CLI, le Gateway et l’outillage s’exécutent dans Linux avec une compatibilité totale. Windows natif fonctionne pour l’utilisation de base de la CLI et du Gateway, avec certaines réserves indiquées ci-dessous. Les applications compagnon Windows natives sont prévues.Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
WSL2 (recommandé)
- Premiers pas (à utiliser dans WSL)
- Installation et mises à jour
- Guide officiel de 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 sur Windows natif aujourd’hui :- programme d’installation du site web via
install.ps1 - utilisation locale de la CLI, comme
openclaw --version,openclaw doctoretopenclaw plugins list --json - test de validation rapide de l’agent/fournisseur local intégré, comme :
openclaw onboard --non-interactiveattend toujours un Gateway local accessible, 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 par utilisateur dans le dossier de démarrage et démarre immédiatement le 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 suspendu indéfiniment - les tâches planifiées restent privilégiées lorsqu’elles sont disponibles, car elles fournissent un meilleur état de supervision
Gateway
Installation du service Gateway (CLI)
Dans WSL2 :Démarrage automatique du Gateway avant la connexion Windows
Pour les configurations sans interface, assurez-vous que toute la chaîne de démarrage s’exécute même lorsque personne ne se connecte à Windows.1) Maintenir les services utilisateur en cours d’exécution sans connexion
Dans WSL :2) Installer le service utilisateur du 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 s’exécutant dans WSL (SSH, un serveur TTS local ou le Gateway), vous devez transférer 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 transfert. Exemple (PowerShell en tant qu’administrateur) :- 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 de Gateway accessible (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 local. - Si vous voulez que cela soit automatique, enregistrez une tâche planifiée pour exécuter l’étape d’actualisation à la connexion.
Installation WSL2 étape par étape
1) Installer WSL2 + Ubuntu
Ouvrez PowerShell (administrateur) :2) Activer systemd (requis pour l’installation du Gateway)
Dans votre terminal WSL :3) Installer OpenClaw (dans WSL)
Pour une configuration initiale normale dans WSL, suivez le flux Linux Premiers pas :Application compagnon Windows
Nous n’avons pas encore d’application compagnon Windows. Les contributions sont les bienvenues si vous voulez aider à la concrétiser.Connectivité Git et GitHub (contributeurs)
Certains réseaux bloquent ou limitent HTTPS vers GitHub. Sigit clone échoue avec des délais d’attente
ou des réinitialisations de connexion, essayez un autre réseau, un VPN ou un proxy HTTP/HTTPS fourni par votre
organisation.
Si gh auth login échoue pendant le flux d’appareil du navigateur (par exemple avec un délai d’attente
pour atteindre github.com:443), authentifiez-vous plutôt avec un jeton d’accès personnel :
- Créez un jeton avec au moins la portée
repo(PAT classique) ou un accès finement granulaire équivalent. - Dans PowerShell pour la session actuelle :
- Si
gh auth statusavertit queread:orgest manquant, créez un jeton qui inclut cette portée et réaffectez la variable :
gh auth refresh -s read:org s’applique uniquement lorsque vous vous êtes authentifié via gh auth login
et que vous avez des identifiants stockés à actualiser (pas lorsque vous utilisez GH_TOKEN).
Ne commettez jamais de jetons et ne les collez jamais dans des issues ou des pull requests.