2026 — OpenClaw sous Windows et Linux : double parcours PowerShell et WSL2, proxy HTTPS d’entreprise, versions Node et passerelle macOS distante (runbook + FAQ)

2. Matrice : PowerShell vs WSL2 vs Linux bureau

Choisissez un environnement principal par ingénieur pour les flux client OpenClaw, documentez-le et imposez la parité Node via .nvmrc ou engines dans package.json. Utilisez le tableau ci-dessous à l’onboarding ou lors d’audits poste.

Pour la stabilité 7×24 côté Mac une fois le tunnel en place : 2026 — OpenClaw Gateway 7×24 : déconnexions et dépannage du démon.

3. Déploiement en sept étapes (reproductible)

Étape 1 — Figez la branche Node cible

OpenClaw 2026.x suit en général Node 22 LTS dans les notes de version. Committez 22.x dans .nvmrc et une plage engines.node dans l’espace qui consomme la CLI.

Étape 2 — Installez Node uniquement dans le shell choisi

Windows PowerShell (exemple fnm) :

winget install Schniz.fnm
fnm install 22
fnm use 22
node -v

WSL2 / Ubuntu :

curl -fsSL https://fnm.vercel.app/install | bash
source ~/.bashrc
fnm install 22 && fnm use 22
node -v

Étape 3 — Variables proxy et listes de contournement

Uniformisez les variables en majuscules. Exemple (hôte/port à adapter) :

export HTTPS_PROXY=http://proxy.corp.example:8080
export HTTP_PROXY=http://proxy.corp.example:8080
export NO_PROXY=localhost,127.0.0.1,::1,.corp.example,169.254.0.0/16

Sous Windows, persistance possible avec setx ou les propriétés système ; redémarrez le terminal ensuite.

Étape 4 — Faire confiance à la chaîne d’AC d’entreprise

Exportez la chaîne émettrice en PEM. Pour Node sous Linux/WSL2, définissez NODE_EXTRA_CA_FILES=/chemin/vers/corp-ca-bundle.pem dans le même profil shell qu’OpenClaw. Sous Windows natif, importez dans Autorités de certification racines/de confiance et redémarrez les shells ; vérifiez avec npm ping ou un petit script node -e "https.get('https://registry.npmjs.org')".

Étape 5 — Installer la CLI OpenClaw et afficher les versions

Suivez le nom de paquet et les drapeaux de votre miroir interne (Artifactory, etc.). Joignez openclaw --version, Node et la build OS à chaque ticket support — cela trie près de la moitié des « déconnexions mystérieuses ».

Étape 6 — Atteindre la passerelle macOS avec une discipline de tunnel unique

Créez le forward SSH -L depuis le même environnement que la CLI. Exemple : ssh -N -L 18787:127.0.0.1:18787 user@mac-hôte (adaptez les ports au bind de la passerelle). Avec Tailscale Serve, validez d’abord les sondes santé en localhost sur le Mac avant d’exposer des URL aux clients.

Étape 7 — Vérifier avec curl depuis ce shell

Exécutez curl -v http://127.0.0.1:18787/health (ou le chemin documenté) et comparez les en-têtes avec un curl sur le Mac contre 127.0.0.1. Les écarts pointent presque toujours vers une mauvaise adresse de bind, un mauvais port ou un tunnel créé dans l’autre sous-système.

4. Chiffres et leviers de politique

5. FAQ et dépannage par symptôme

Installer sur PowerShell ou sur WSL2 ?

Voir la matrice (section 2). La mauvaise réponse est « les deux sans pinning ». Si la sécurité impose les magasins Windows, partez sur PowerShell ; si votre automatisation est bash-first, engagez-vous sur WSL2 et exécutez-y les tunnels.

Erreurs TLS uniquement dans npm/pnpm

Le navigateur fait confiance au MITM via le magasin OS ; Node ne le fait pas automatiquement. Corrigez l’import CA pour le runtime, pas seulement le navigateur. Gardez strict-ssl=false hors production sauf capture réseau ciblée.

PowerShell atteint la passerelle, WSL2 non

Le forward a été créé sous Windows alors que la CLI tourne dans WSL2 (ou l’inverse). Recréez le tunnel dans le sous-système qui héberge le processus OpenClaw, ou redirigez vers l’adresse « vue depuis WSL » documentée pour votre build Windows.

HTTP 502 ou UI vide via le tunnel

Prouvez d’abord la passerelle sur le Mac avec curl localhost. Si ça échoue, redémarrez le service et consultez les journaux launchd. Si le Mac-local est sain, revérifiez l’ordre -L, les collisions de port local et si vous supposiez HTTPS alors que la passerelle parle HTTP sur le saut loopback.

6. Pourquoi une passerelle Mac physique sur Apple Silicon

Le travail client décrit ici n’est que la moitié du récit : la passerelle OpenClaw sous macOS profite de la bande passante mémoire unifiée d’Apple Silicon pour des charges d’agents concurrentes, d’un ordonnancement 7×24 compatible launchd et d’une toolchain Unix alignée sur la plupart des automatisations CI. Une machine de classe Mac mini consomme environ 4 W au repos tout en restant prête pour forwards SSH et sondes — plus facile à justifier qu’une tour bruyante dans un placard.

macOS empile Gatekeeper, SIP et FileVault, ce qui réduit le risque de malware opportuniste par rapport à de nombreux postes Windows d’entreprise — un point sensible lorsque des jetons longue durée cohabitent avec la passerelle. Si vous voulez que le chemin distant de la section 3 reste d’une banale stabilité, hébergez la passerelle sur du matériel Apple silencieux et efficace, et gardez Windows/Linux comme clients contrôlés.

Pour standardiser des passerelles distribuées, des nœuds Mac mini M4 offrent latence prévisible et coût d’exploitation contenu — découvrez les nœuds ZoneMac lorsque vous alignerez ce runbook sur des hôtes macOS de production.