Windows WSL2 für OpenClaw

Die meisten Windows-Einsteiger scheitern nicht daran, dass OpenClaw schwer wäre. Sie scheitern daran, dass Windows und Linux sich den Schraubenschlüssel gegenseitig aus der Hand ziehen. WSL2 löst das, indem OpenClaw ein echtes Linux-Zuhause bekommt, während dein normaler Windows-Desktop erhalten bleibt.

Stell dir WSL2 wie eine Werkstatt hinter deinem Büro vor. Windows bleibt der Empfang. Linux bedient die Werkzeuge. Wenn du deine Dateien dauernd durch den Flur hin und her schleppst, wird alles langsamer und seltsamer. Wenn du direkt in der Werkstatt arbeitest, wird das Ganze schnell ruhiger.

Was WSL2 für dich eigentlich erledigt

WSL2 bringt einen echten Linux-Kernel in eine leichte virtualisierte Schicht. Für OpenClaw zählt das, weil das Projekt Linux-artige Shells, Rechte, Pfade, Paketmanager und Service-Verhalten erwartet. Du startest weiter auf einem Windows-Rechner, aber die Laufzeit tut nicht mehr so, als wäre sie etwas anderes.

• Bessere Kompatibilität: Weniger Ärger mit Pfaden, Rechten und Shell-Eigenheiten.
• Sauberer Doku-Fit: Die meisten OpenClaw-Beispiele gehen ohnehin von Linux aus.
• Weniger Reibung: Git, Node, pnpm, Python und Shell-Tools verhalten sich planbarer.
• Klare Trennung: Dein KI-Workspace lebt in Linux, ohne dass dein ganzer Windows-Rechner zum Experiment wird.

Wenn du zuerst die offizielle Basis willst, nutze Microsofts WSL-Installationsanleitung. Für Befehle danach ist die WSL-Befehlsreferenz die passende Spickliste.

Mindestens nötig, bevor du OpenClaw anfasst

Du brauchst einen aktuellen Windows-10- oder Windows-11-Build, Admin-Rechte für die erste WSL-Installation und eine Linux-Distribution. Ubuntu ist der einfachste Standard, weil die meisten Community-Beispiele darauf hinauslaufen.

# In einer erhöhten PowerShell ausführen
wsl --install

# Windows neu starten, wenn du dazu aufgefordert wirst

# Danach in PowerShell prüfen
wsl --list --verbose

Öffne nach dem Neustart deine Linux-Distribution, lege deinen Linux-Benutzer an und lass die Ersteinrichtung durchlaufen. Nicht spektakulär, aber genau dort hört dein Windows-Rechner auf, eine feindliche Umgebung für Linux-Tools zu sein.

Wähle den richtigen Ort für deine Dateien

Das ist der Fehler, der am meisten Zeit verbrennt. Lege dein OpenClaw-Repo nicht unter /mnt/c/Users/... ab, wenn du aus der Linux-Shell arbeitest. Das funktioniert gerade gut genug, um dich in Sicherheit zu wiegen, und rächt sich später bei Installationen, Rebuilds und File-Watching.

Speichere das Projekt stattdessen unter deinem Linux-Home:

mkdir -p ~/workspace
cd ~/workspace
git clone https://github.com/openclaw/openclaw.git
cd openclaw

Die Regel ist simpel: Linux-Tools wollen Linux-Dateien. Windows-Tools wollen Windows-Dateien. Du kannst die Grenze überqueren, aber bitte mit Grund und nicht aus Gewohnheit.

Installiere die Werkzeuge in WSL2, nicht halb in jeder Welt

Ein chaotisches WSL2-Setup entsteht fast immer durch Split Brain. Node liegt in Windows, pnpm in Linux, Git meldet sich aus irgendeiner Richtung zuerst, und am Ende tun alle überrascht, wenn Scripts brechen.

Halte deine Kernwerkzeuge in genau der Distribution, in der OpenClaw laufen soll:

• Git
• Node.js
• pnpm
• Python 3 für Hilfstools
• Docker-Integration, falls du den Docker-Weg nutzen willst

Genau da liegt der stille Vorteil von WSL2. Sobald du aufhörst, Umgebungen zu mischen, werden seltsame Fehler wieder langweilig. Langweilig ist gut.

Zwei sinnvolle OpenClaw-Wege auf Windows

Option 1: OpenClaw direkt in WSL2 ausführen

Das ist der sauberere Weg, wenn du ein Entwicklungs-Setup willst und Docker nicht für Isolation brauchst. Du arbeitest in der Linux-Shell, installierst dort die Abhängigkeiten und führst OpenClaw aus, als wäre der Rechner ein normaler Linux-Host.

cd ~/workspace/openclaw
pnpm install
pnpm dev

Nimm diesen Weg, wenn du die schnellste Rückkopplung und die wenigsten beweglichen Teile willst.

Option 2: Docker mit WSL-Integration nutzen

Das ist der bessere Weg, wenn du den offiziell empfohlenen Container-Workflow willst. Entscheidend ist nicht nur Docker Desktop zu installieren. Entscheidend ist, die WSL-Integration für genau die Distribution zu aktivieren, in der dein OpenClaw-Repo liegt, und Docker-Befehle aus genau dieser Distribution zu starten.

cd ~/workspace/openclaw
./docker-setup.sh

Wenn Docker installiert ist, deine Distribution aber nicht mit ihm sprechen kann, hast du meistens ein Integrationsproblem und kein OpenClaw-Problem.

Windows-spezifische Schmerzen, die immer wieder auftauchen

Langsame Installationen und Rebuilds

Wenn sich pnpm install verdächtig langsam anfühlt oder der Dev-Server bei jeder Dateiänderung beleidigt wirkt, prüfe zuerst den Repo-Pfad. Projekte unter /mnt/c sind fast immer der Auslöser.

Port-Verwirrung

Manchmal belegt schon ein Windows-Prozess den Port, den du in WSL2 erwartest. Wenn das Gateway nicht starten will, prüfe beide Seiten, bevor du die App beschuldigst. Windows und Linux sind hier Nachbarn, keine Fremden.

Browser-Automatisierung macht Ärger

Headless-Browser-Flows laufen meist mit weniger Theater als sichtbare Browser. Wenn du einen sichtbaren Browser brauchst, ist Windows 11 mit WSLg deutlich angenehmer als alte X-Server-Bastelei. Wenn dein Fall vor allem Scraping, Formularfüllen oder Login-Wiederverwendung ist, spart dir Headless-Modus oft die Nerven.

GPU- und lokale Modell-Instabilität

WSL2 kann mit lokalen Modellen funktionieren, aber hier wird die Werkstatt-Metapher anstrengend. Wenn GPU-Treiber, große Modelle, Browser-Aufgaben und lang laufende Agenten gleichzeitig dazukommen, wirkt natives Linux plötzlich nicht mehr übertrieben, sondern vernünftig.

Ein praktischer OpenClaw-Workflow, der sauber bleibt

1. Installiere WSL2 und eine Ubuntu-Distribution.
2. Lege dein Repo unter ~/workspace oder einem anderen Linux-Pfad ab.
3. Installiere Node, pnpm, Git und Hilfstools innerhalb von WSL2.
4. Entscheide dich für direkten Runtime-Betrieb oder Docker. Keinen wilden Mischweg ohne Grund.
5. Nutze Windows nur als Host-Desktop, Editor-Oberfläche und Browser-Schicht.

Diese Aufteilung funktioniert, weil jede Seite eine klare Aufgabe bekommt. Windows ist zum Klicken da. Linux ist der Ort, an dem OpenClaw lebt.

Troubleshooting-Checkliste

Wenn sich das Setup verflucht anfühlt, geh diese Liste der Reihe nach durch:

# Innerhalb von WSL2
uname -a
pwd
node -v
pnpm -v
git --version
wsl.exe --status
wsl.exe --list --verbose

• Wenn der Repo-Pfad mit /mnt/ beginnt, verschiebe ihn in dein Linux-Home.
• Wenn Docker-Befehle scheitern, prüfe, ob Docker Desktop läuft und die WSL-Integration für deine Distribution aktiv ist.
• Wenn Browser-Tools scheitern, teste zuerst Headless-Modus und sieh in den Guide zur Browser-Automatisierung.
• Wenn File-Watcher Änderungen verpassen, vermute zuerst Cross-Filesystem-Pfade und nichts Exotisches.
• Wenn alles funktioniert, aber langsam ist, ist die Pfadwahl fast immer der erste Hebel.

Wann du WSL2 lieber überspringst

WSL2 ist stark für einen Entwickler-Arbeitsplatz. Es ist nicht automatisch die Endlösung für jedes ernsthafte Deployment. Wenn du 24/7-Uptime, einfacheres Networking, weniger Windows-Updates mitten in deinen Plänen oder bessere Bedingungen für schwere lokale Modelle willst, nimm lieber einen Linux-Rechner oder VPS.

Kurz gesagt: WSL2 ist hervorragend zum Bauen und Lernen. Für Always-on-Produktion gewinnt Linux immer noch ziemlich klar.