2026 — OpenClaw multi-plateforme et résident : Windows WSL2 face à Linux (systemd) — check-list comparée, dépannage du démarrage automatique de la passerelle et FAQ workflow hybride SSH avec Mac distant dédié
Vous pouvez faire tourner des passerelles et agents de type OpenClaw sous Windows via WSL2 ou sur du Linux nu / VM avec systemd — mais les modes de défaillance diffèrent : mise en veille de WSL, dérive d'horloge et sémantique d'init ; les serveurs Linux, eux, imposent le durcissement des unités, journald et les reverse proxies. Ce guide propose une check-list comparée, une matrice symptôme → cause → action pour l'autostart de la passerelle, et un schéma hybride où Linux ou WSL héberge le plan de contrôle tandis qu'un Mac distant dédié prend en charge le travail réservé à Apple via SSH. Pour choisir la voie d'installation (install.sh, npm, Docker), voir OpenClaw 2026 : comment choisir son chemin d'installation ? install.sh officiel, npm et Docker Compose — matrice + checklist SSH sans écran ; pour réconcilier les variables OPENCLAW_* après une montée de version, voir OpenClaw 2026 : mise à niveau majeure après le 22.03.2026 — doctor, migration Plugin SDK et variables OPENCLAW_* (SSH Mac distant reproductible).
TL;DR — Points clés
En résumé : considérez WSL2 comme une VM Linux qui s'arrête quand Windows dort — idéal pour le dev, risqué pour le « toujours actif » sans contourner la mise en veille. Linux natif + systemd reste la base par défaut pour une passerelle sans présence humaine : unités déclaratives, politiques de redémarrage et journaux structurés.
- Workflow hybride : HTTP passerelle et outillage léger sur Linux ou WSL ; saut vers un Mac distant dédié en SSH pour Xcode, la signature, la notarisation et les CLI Apple.
- Ordre d'autostart : réglez d'abord l'adresse d'écoute et les collisions de ports avant d'incriminer OpenClaw —
127.0.0.1vs0.0.0.0et les tunnels amont (Tailscale Serve,cloudflared) doivent être alignés. - Hygiène d'environnement : les unités
systemdexigent desEnvironment=ouEnvironmentFile=explicites ; sous WSL, lePATHhérité diffère souvent de votre shell interactif.
1. WSL2 vs Linux natif : check-list comparée (2026)
| Sujet | Windows WSL2 | Linux + systemd |
|---|---|---|
| Cycle de vie | Lié à l'alimentation Windows ; .wslconfig peut mettre les distros en veille. |
Tourne jusqu'à extinction matérielle ; disponibilité prévisible sur images serveur. |
| Init / services | systemd optionnel dans WSL (selon distro) ; démarrages utilisateur ou tâches planifiées Windows appelant wsl.exe. |
Unités systemd de premier ordre, timers, activation par socket. |
| Réseau | vSwitch NAT ; les règles de forward localhost diffèrent des portables Linux. |
Interfaces classiques ; liaison LAN/VPN directe. |
| Horloge & TLS | Reprise de veille peut brièvement décaler l'heure — surveillez les poignées TLS après réveil. | NTP/chrony ; moins de cas « laptop endormi » sur serveurs. |
| Cas d'usage | Poste de dev quotidien, expérimentation locale, couplé à un Mac distant. | VPS, homelab passerelle, workers proches de la CI, endpoints 24/7. |
2. Check-list installation & exécution (les deux plateformes)
2.1 Prérequis à valider en premier
- Node / runtime : alignez-vous sur la LTS supportée par la release OpenClaw ; évitez de mélanger des shells
nvmdanssystemdsans chemin absolu vers le binaire. - Descripteurs de fichiers & ulimits : les passerelles qui multiplexent des WebSockets et des sous-processus peuvent exiger un
LimitNOFILE=plus élevé dans l'unité. - Secrets : préférez un
EnvironmentFileen0600plutôt que des exports dans des profils shell quesystemdne lit pas.
2.2 Linux (systemd) — schéma minimal « toujours actif »
Un motif solide : Type=simple ou notify (si pris en charge), Restart=on-failure, utilisateur de service dédié. Durcissez avec NoNewPrivileges=true, PrivateTmp=true et un WorkingDirectory= explicite. Les journaux passent par journalctl -u votre-unite -f — en cas de sorties silencieuses, montez la verbosité avant de chercher un bug applicatif.
2.3 WSL2 — garder la distro vivante
- Réduisez l'agressivité de la mise en veille côté Windows si vous visez un « quasi 24/7 » ; sinon un petit VPS Linux évite de lutter contre les politiques d'alimentation des portables.
- Si la distro supporte
systemd, activez-le selon la documentation Microsoft ; sinon planifiezwsl -u user -d Distro -- bash -lc 'votre commande'à l'ouverture de session. - Vérifiez quel côté écoute : les outils Windows sur
localhostn'atteignent pas un service lié uniquement dans WSL sans règle de forward de port.
3. Autostart de la passerelle : symptôme → piste → action
| Symptôme | Cause probable | Que faire |
|---|---|---|
EADDRINUSE au démarrage |
Processus obsolète, unité dupliquée ou tunnel déjà lié. | ss -lntp / lsof -i ; stoppez l'ancien PID ; alignez le port amont du tunnel avec la passerelle. |
OK en shell SSH, échec sous systemd |
Variables d'environnement ou PATH différent. |
Recopiez l'environnement exact dans des lignes Environment= ou un EnvironmentFile ; chemins absolus vers node / CLI. |
| Boucle de redémarrage immédiate | Crash avant que réseau ou DNS ne soit prêt. | Ajoutez After=network-online.target et Wants=network-online.target (si pertinent) ; RestartSec= pour temporiser. |
| Flakiness TLS / OAuth après reprise (WSL) | Dérive d'horloge ou pile réseau endormie. | Resynchronisez l'heure ; retardez le démarrage tant que le réseau WSL n'est pas stable ; pour les flux d'identité lourds, préférez un hôte qui ne dort pas. |
403 / erreurs d'auth uniquement via l'URL du tunnel |
En-têtes d'identité du tunnel vs ACL locale incohérents. | Relisez la doc fournisseur pour les proxies de confiance ; gardez la passerelle en loopback ; terminez le TLS au bord du tunnel. |
4. Mac distant dédié + workflow hybride SSH
Dans des configurations proches de la prod, la découpe nette est : Linux ou WSL pour la passerelle toujours joignable, les planificateurs et les API fournisseurs ; le Mac distant comme « îlot Apple » mono-locataire en SSH (clés, AllowUsers, Tailscale optionnel). Les agents invoquent macOS en SSH non interactif (ssh mac 'xcodebuild …') avec des ressources de signature préprovisionnées.
- Isolation : un utilisateur SSH par principal d'automatisation ; paires de clés séparées par environnement (staging vs prod).
- Timeouts : alignez les timeouts HTTP de la passerelle sur des jobs SSH plus longs pour
xcodebuild— ou déportez vers une file et interrogez l'état. - Observabilité : redirigez
log streamou les journaux de build vers des fichiers sous~/Logsavec rotation ; n'attendez jamais de boîtes de dialogue GUI sur Mac headless.
5. FAQ (réponses courtes)
Faut-il faire tourner OpenClaw en prod sur WSL2 ? Seulement si vous acceptez Windows comme domaine de disponibilité. Pour un vrai 24/7, préférez un VPS Linux ou un Mac mini dédié avec launchd.
Une passerelle peut-elle parler à plusieurs Mac ? Oui sur le plan architecture, mais la complexité opérationnelle grimpe — commencez par un Mac distant dédié par équipe ou par environnement.
Où placer les clés API ? Jamais dans la ligne ExecStart= de l'unité ; utilisez un EnvironmentFile et des permissions restrictives.
Pourquoi un Mac mini dédié reste l'ancre de ce schéma hybride
Linux et WSL excellent pour les passerelles HTTP et la colle d'automatisation, mais la chaîne Apple suppose macOS. Un Mac mini en Apple Silicon offre xcodebuild natif, la signature, la notarisation et un shell Unix en SSH sans les surprises de mise en veille d'un poste WSL portable. macOS combine une consommation au repos très faible (souvent quelques watts seulement), un fonctionnement silencieux et un modèle de sécurité abouti — Gatekeeper, SIP et FileVault — ce qui rend une machine de build headless moins exposée qu'une station Windows laissée allumée en permanence.
Si vous voulez que le schéma hybride de cet article devienne « ennuyeusement fiable », placez le côté Apple sur du métal dédié : le Mac mini M4 offre en 2026 un bon équilibre performance, thermique et coût — utilisez les liens ci-dessous pour aligner le matériel sur votre concurrence de jobs et vos besoins de signature.