Viele Teams nutzen auf Windows-Desktops WSL2 für eine Linux-nahe Toolchain und lassen Builds und Signierung auf echten Macs bei MacCloud laufen. Läuft OpenClaw in WSL, nerven oft nicht die Fachlogik, sondern Pfad-Interop, Zeilenenden und der Netzwerkstack.

1. Distribution und Kernel

Bevorzugen Sie Ubuntu 22.04 / 24.04 LTS und führen Sie sudo apt update && sudo apt upgrade aus. Halten Sie den WSL2-Kernel aktuell; alte Kernel neigen auf der virtuellen NIC zu sporadischen Disconnects und DNS-Timeouts.

2. Repo-Standort: ~/ vs. /mnt/c

Legen Sie Repos im nativen WSL-Dateisystem (z. B. ~/projects) ab, nicht unter /mnt/c—I/O und File-Watcher sind deutlich angenehmer. Bei Zugriff auf Windows-Dateien können Berechtigungen und Executable-Bits abweichen; verlassen Sie sich nicht blind auf chmod +x.

Faustregel: schnelle Build-Caches liegen immer im WSL-Dateisystem.

3. SSH zu MacCloud

Erzeugen Sie SSH-Keys innerhalb WSL und tragen Sie den Public Key in authorized_keys auf dem Cloud-Mac ein. Für VS Code Remote konfigurieren Sie Erweiterungen und Key-Pfade getrennt für Windows und WSL, damit keine „Key existiert, Extension findet ihn nicht“-Effekte entstehen.

4. DNS, VPN, Firmennetz

Bei Resolver-Problemen prüfen Sie die DNS-Richtlinie von WSL und ob resolv.conf überschrieben wird. Mit Firmen-VPN sollte der Host Split-Tunneling o. Ä. bereitstellen, damit WSL stabile Routen erbt. „Zuhause ging es“ reicht nicht als Beweis.

5. Bezug zu Linux- und macOS-Dokumentation

WSL verhält sich wie Linux für Dienstbetrieb; siehe Linux-Deployment. GUI- oder Xcode-Schritte gehören auf den Mac—lesen Sie macOS-Setup und MacCloud in der Praxis.

6. Selbstcheckliste

  • Zeigt pwd im aktuellen Shell einen Pfad auf dem nativen WSL-Datenträger?
  • Nutzt ssh -v zu MacCloud den erwarteten Schlüssel?
  • Wurden ping/curl mit und ohne VPN verglichen?

WSL als Orchestrierungs- und Skriptseite, MacCloud als echte Builder-Seite zu definieren, beschleunigt die Fehlersuche.