Sur le bureau Windows, beaucoup d’équipes utilisent WSL2 pour une toolchain proche de Linux et confient builds et signature à de vrais Mac sur MacCloud. Quand OpenClaw tourne dans WSL, ce qui pique est souvent l’interop des chemins, les fins de ligne et la pile réseau, pas le code métier.

1. Distribution et noyau

Privilégiez Ubuntu 22.04 / 24.04 LTS, puis sudo apt update && sudo apt upgrade. Gardez le noyau WSL2 à jour ; les noyaux anciens posent plus souvent des coupures et des timeouts DNS sur la NIC virtuelle.

2. Où placer le dépôt : ~/ ou /mnt/c

Placez le dépôt sur le système de fichiers natif WSL (ex. ~/projects), pas sur /mnt/c—I/O et surveillance de fichiers y sont bien meilleurs. En lecture croisée Windows, permissions et bit d’exécution peuvent différer ; ne vous fiez pas aveuglément à chmod +x.

Règle : les caches de build rapides restent dans le FS WSL.

3. SSH vers MacCloud

Générez des clés SSH dans WSL et ajoutez la clé publique dans authorized_keys sur le Mac cloud. Pour VS Code Remote, séparez extensions et chemins de clés entre Windows et WSL pour éviter l’effet « la clé existe mais l’extension ne la voit pas ».

4. DNS, VPN, réseau d’entreprise

Si la résolution est instable, inspectez la politique DNS de WSL et l’écrasement de resolv.conf. Avec un VPN d’entreprise, préférez un split tunneling côté hôte pour des routes stables héritées par WSL. Ne concluez pas sur « ça marche chez moi » seul.

5. Lien avec les guides Linux et macOS

WSL se comporte comme Linux pour l’hébergement de services : voir déploiement Linux. Les étapes GUI ou Xcode restent sur Mac—lisez installation macOS et MacCloud en pratique.

6. Auto-contrôle

  • pwd pointe-t-il vers un chemin sur le disque natif WSL ?
  • ssh -v vers MacCloud utilise-t-il la clé attendue ?
  • Avez-vous comparé ping/curl avant/après activation du VPN ?

Traiter WSL comme le côté orchestration/scripts et MacCloud comme le côté builder réel clarifie le débogage.