2026 OpenClaw Windows/WSL2
et Gateway Mac cloud permanent

OpenClaw couvre en 2026 macOS, Linux et Windows (souvent via WSL2). Les incidents Windows superposent trois couches : version Node, session utilisateur systemd capable de lancer le Gateway et occupation fantôme du port 18789. Les réduire à « réinstaller » provoque des boucles de crash de 30 à 50 secondes sur des builds comme 2026.4.24 alors que le blocage réel reste la double inscription Gateway au niveau utilisateur et système. Classez d'abord le ticket par signature avant de libérer des ports, de rétrograder un dist-tag ou de déplacer le Gateway de production vers un Mac cloud.

En exploitation, un runbook à cases aide : transport (ping, statut Tailscale), processus (gateway status, journalctl --user -u openclaw-gateway -n 50), configuration (doctor, channels probe). Si les trois sont verts mais que le nœud coupe encore, la cause est presque toujours la couche remote — pas le pare-feu Windows. Pour les audits, n'exportez que des extraits de journaux anonymisés : les lignes Gateway peuvent contenir des identifiants de chat issus des adaptateurs de canaux. Définissez des durées de conservation conformes à votre politique de données personnelles avant de charger des logs dans des outils hébergés hors UE.

Après étiquetage, ajustez le routage des modèles. Si le master tourne déjà sur Mac cloud, lisez nœud distant, Tailscale et migration. Si le Gateway n'a jamais été validé sur l'hôte cloud, suivez d'abord la check-list SSH première heure avant d'empiler les démons WSL — sinon vous multipliez le bruit de redémarrage sur un master instable. Les équipes multi-OS doivent tenir un schéma d'architecture : quel hôte détient quels secrets, où les jetons tournent et quelle région minimise la latence vers vos utilisateurs finaux.

Le consensus 2026 n'est pas « Windows ne peut pas OpenClaw », mais placer plan de contrôle 7×24 et webhooks de canaux sur un hôte stable. Le tableau aligne expérimentation portable, Gateway auto-hébergé en WSL et topologie recommandée « master Mac cloud + nœud Windows ». Pour la bibliothèque d'incidents complète, voir déploiement Gateway et reprise.

Documentez après choix du split : quel Mac cloud porte quels webhooks, si Windows n'utilise que openclaw node run --remote wss://.... WSL peut temporairement héberger un Gateway pour comparaison — ne liez pas le même jeton de canal en parallèle sur le master, sinon double consommation et pertes silencieuses. Conteneur vs bare metal : Docker vs install.sh ; versions : mise à niveau et rollback. Le dépôt Git sur l'instance Mac reste un arbre de travail classique, distinct de l'état Gateway.

Les comparatifs de coût oublient souvent l'exploitation : un portable Windows comme Gateway économise la location mais augmente les interruptions (mises à jour, batterie, VPN partagé). Un Mac cloud dans la région cible réduit la latence vers les API Telegram et Discord et rend les redémarrages LaunchAgent prévisibles. Si plusieurs développeurs partagent la même distribution WSL, séparez les comptes Unix ou les conteneurs pour éviter les collisions npm et OPENCLAW_HOME. La topologie split sépare aussi les données de canaux (sur le master) de l'exécution d'outils (sur Windows), ce qui simplifie les registres de traitement lorsque les exports de journaux restent minimaux.

Avant un openclaw onboard --install-daemon productif en WSL : Node ≥ 22.16 (24 recommandé) et systemd=true dans /etc/wsl.conf. Certains builds 2026.4.24 sur WSL2 affichaient : journal Gateway « démarré », Control UI inaccessible, EADDRINUSE toutes les 30–50 s — atténuation fréquente : épinglage 2026.4.22 et suppression des unités en double. Les journaux Gateway peuvent contenir des identifiants de canaux ; pour les tickets, exportez des extraits minimaux conformes à votre politique de conservation des données personnelles.

grep -q 'systemd=true' /etc/wsl.conf || echo '[boot]' >> /etc/wsl.conf && echo 'systemd=true' >> /etc/wsl.conf
node -v
curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon
systemctl --user status openclaw-gateway
lsof -i :18789
openclaw doctor
openclaw gateway status

Si lsof montre 18789 occupé alors que gateway status est stopped, traitez d'abord les processus openclaw orphelins et les unités parallèles sous /etc/systemd/system versus ~/.config/systemd/user. Conservez une seule unité utilisateur, systemctl --user daemon-reload, redémarrage. Si la boucle persiste, documentez openclaw --version et évaluez le rollback depuis 2026.4.24 ; fenêtre de maintenance avec openclaw doctor --fix. Débogage Control UI local sur le portable : pare-feu limité à 18789 sur la machine de dev — production via Tailscale Serve vers le master Mac cloud, pas d'exposition publique du portable.

Pour les équipes mixtes, ordonnez la maintenance : figer d'abord le master Mac cloud (channels probe vert), désactiver ensuite le démon WSL, migrer enfin les clients Node. Le rollback suit l'ordre inverse — jamais redémarrage master et onboard WSL simultanés. Si vous testez PowerShell natif, documentez les écarts avec install.sh pour que le support n'applique pas des commandes WSL sur l'hôte. Tenez une fiche de compatibilité 2026.4.x : build, noyau WSL, version Node, résultat de doctor --fix.

Chaque étape mérite un champ ticket : date, version, région, résultat de sonde. Les équipes distribuées gagnent des heures de support car les opérateurs Windows n'ont plus à interpréter chaque journal Gateway du master. La discipline de documentation évite aussi de mélanger incidents WSL, de version et de canal dans un même fil de discussion.

Après l'étape 06, exécutez un test de charge léger : deux sessions Node depuis des postes Windows distincts, un message canal réel, un outil long. Surveillez la RAM du Mac cloud et vérifiez si WSL régénère EADDRINUSE — signe qu'un démon Gateway local tourne encore. Documentez les ACL Tailscale : seuls les groupes développeurs doivent joindre le WSS du master. Faites tourner les jetons de canal dans un change séparé de la bascule Node pour isoler les causes.

Ancrer le Gateway sur un portable Windows réintroduit veille, mises à jour fonctionnelles et gel WSL. Les VPS Linux bon marché s'éloignent de l'automatisation navigateur macOS et de la notarisation. Mac cloud bare metal en master, Windows en nœud ou UI combine proximité toolchain Apple, discipline loopback et fenêtres de location prévisibles à Singapour, Tokyo, Séoul, Hong Kong, USA Est et Ouest. Pour des canaux 7×24 sans parier sur du matériel grand public, la location Mac mini MESHLAUNCH est en général la meilleure base : valider la région cible en location journalière avec les six étapes plus un redémarrage hôte, puis verrouiller le mois.

Dimensionnement : un master multi-canaux avec outils lourds préfère 24 Go de RAM ; plusieurs nœuds clients augmentent la charge WebSocket plus que les pics CPU Xcode. Changez de région via backup/restore plutôt que copie manuelle de JSON isolés. Conservez des captures gateway status et channels probe pour les revues internes. Commande et support : tarifs et centre d'aide.