OpenClaw unter WSL, Claude Code unter Windows: die stabile Bridge ohne Frickelei
Das Problem, über das diese Woche plötzlich alle stolpern
Gerade taucht ein sehr spezifischer OpenClaw-Fehler überall auf: Claude Code ist unter Windows installiert, OpenClaw läuft in WSL, und das Setup fühlt sich so an, als müsste es eigentlich funktionieren, tut es aber nicht.
Die Symptome sind auf die unerquicklichste Art banal. Befehle funktionieren in der einen Shell und in der anderen nicht. OpenClaw sieht Dateien unter Linux-Pfaden, Claude Code erwartet Windows-Pfade, und Umgebungsvariablen existieren in einer Welt, verschwinden aber in der anderen. Dann kommt noch die aktuelle Anthropic-Unruhe dazu, Leute wechseln den Provider oder den Zugriffsweg, und plötzlich heißt es nur noch: „Gestern lief das doch noch.“
Die gute Nachricht: Das ist kein Architekturproblem von OpenClaw. Es ist ein Boundary-Problem. Sobald du diese Grenze sauber definierst, wird das Setup berechenbar.
Die Kurzfassung:
Genau darum geht es.
---
Warum das überhaupt kaputtgeht
WSL ist gut, aber nicht „Linux in Windows ohne jede Naht“. Es ist eine Linux-Umgebung, die sich eine Maschine mit Windows teilt. Und genau diese Nahtstellen sind für Agent-Tooling entscheidend.
OpenClaw interessiert sich im Kern für ein paar Dinge:
1. Wo Befehle laufen
2. Welche Dateien in dieser Runtime sichtbar sind
3. Welche Credentials in dieser Runtime verfügbar sind
4. Ob Kindprozesse die richtige Umgebung erben
5. Ob Pfadannahmen vom Anfang bis zum Ende konsistent sind
Ein gemischtes Windows-plus-WSL-Setup erzeugt bei jedem einzelnen Punkt Mehrdeutigkeit.
Typische Beispiele:
Wenn du das Ganze wie eine einzige flache Maschine behandelst, verlierst du Stunden. Wenn du es wie zwei Environments mit einer kontrollierten Bridge behandelst, wird es beherrschbar.
---
Die Architektur, die wirklich funktioniert
Das sauberste Muster ist dieses:
Wenn du Claude Code direkt in WSL installieren kannst, mach das. Dadurch verschwindet eine ganze Klasse von Problemen.
Wenn das nicht geht oder du Claude Code bewusst unter Windows verwalten willst, dann bau einen dünnen Wrapper statt dich auf zufällige Interoperabilität zu verlassen.
Konzeptionell erledigt dieser Wrapper drei Dinge:
1. Einen Aufruf aus WSL entgegennehmen
2. Das Working Directory in einen Windows-Pfad umwandeln
3. Claude Code unter Windows mit expliziten Argumenten starten
Entscheidend ist nicht die Sprache des Wrappers. Bash, PowerShell, Python, egal. Entscheidend ist, dass die Bridge explizit ist.
Beispielstruktur:
<pre><code># Aus WSL bewusst einen Windows-Befehl aufrufen
/mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe -ExecutionPolicy Bypass -File C:Usersduinclaude-bridge.ps1 -ProjectPath "$(wslpath -w "$PWD")" -Prompt "Fasse dieses Repo zusammen und schlage nächste Schritte vor"
</code></pre>
Auffällig ist hier vor allem, was fehlt: Ratespiel. Wir hoffen nicht, dass Windows irgendwie einen Linux-Pfad versteht. Wir konvertieren ihn absichtlich.
---
Die drei Checks, bevor du überhaupt OpenClaw konfigurierst
Mach diese Checks, bevor du dem Agenten die Schuld gibst.
1. Kann WSL das Windows-Binary überhaupt aufrufen?
Aus WSL:
<pre><code>/mnt/c/Windows/System32/cmd.exe /c where claude
</code></pre>
Wenn das schon fehlschlägt, kannst du hier aufhören. OpenClaw wird ein fehlendes Executable nicht magisch reparieren.
2. Kannst du den aktuellen Repo-Pfad sauber über die Grenze geben?
Im Repo-Root unter WSL:
<pre><code>wslpath -w "$PWD"
</code></pre>
Wenn die Ausgabe Unsinn ist oder auf einen gemounteten Pfad mit kaputten Rechten zeigt, dann repariere zuerst den Repo-Standort. Für aktive Coding-Arbeit ist das WSL-Dateisystem meist verlässlicher als direkt unter <code>/mnt/c</code> zu arbeiten.
3. Sind deine Credentials dort vorhanden, wo OpenClaw wirklich läuft?
Nimm nicht an, dass Windows-Umgebungsvariablen automatisch in WSL auftauchen. Tun sie oft nicht so, wie man denkt.
In WSL prüfen:
<pre><code>echo "$ANTHROPIC_API_KEY"
echo "$OPENROUTER_API_KEY"
echo "$GOOGLE_API_KEY"
</code></pre>
Wenn das leer ist, hat deine Agent-Runtime schlicht nicht, was sie braucht, auch wenn PowerShell korrekt aussieht.
---
Empfohlenes Setup: Working Copy in WSL halten
Das ist der Fix mit dem höchsten Hebel.
Lege die echten agentenseitigen Repos im Linux-Dateisystem ab, nicht im Windows-Mount. Zum Beispiel:
<pre><code>~/projects/meine-app
~/.openclaw/workspace
</code></pre>
Warum das so wichtig ist:
Wenn Claude Code auf Windows bleiben muss, dann lass die Bridge erst beim Aufruf vom WSL-Pfad in einen Windows-Pfad übersetzen. Das ist viel günstiger, als das gesamte Projekt in einem Kompromiss-Verzeichnis leben zu lassen.
---
OpenClaw so konfigurieren, dass es nicht fragil wird
Dein Ziel ist nicht: „Jedes Tool überall verfügbar machen.“ Dein Ziel ist: „Der Orchestrator muss die Dinge, die er wirklich braucht, konsistent starten können.“
Das heißt konkret:
Ein vernünftiges Muster ist, genau einen stabilen Befehl zu definieren, den OpenClaw aufrufen kann, zum Beispiel <code>claude-bridge</code>, und dieses Skript den Windows-Hop erledigen zu lassen.
Dann bleiben auch die Agent-Anweisungen herrlich langweilig:
Langweilig ist hier gut.
---
Jetzt ein Fallback-Modell ergänzen, nicht erst im Incident
Dieser Teil ist nach der jüngsten Anthropic-Unruhe noch wichtiger.
Ein gemischtes OpenClaw-Setup sollte nie von genau einer fragilen Abhängigkeit abhängen. Wenn dein bevorzugter Coding-Pfad Claude Code auf Windows ist, okay. Behalte ihn. Aber richte mindestens einen Fallback-Weg ein, falls sich Authentifizierung ändert, der Provider wackelt oder die Bridge bricht.
Praktische Fallbacks:
Der strategische Punkt ist simpel: OpenClaw ist dann am stärksten, wenn die Orchestrierung stabil bleibt, auch wenn ein Modellpfad es gerade nicht ist.
---
Häufige Fehlerbilder und der echte Fix
„Claude funktioniert in PowerShell, aber nicht aus OpenClaw heraus“
Das bedeutet fast immer, dass OpenClaw das Executable oder den Key in WSL nicht sieht.
Fix: Teste den Befehl aus genau der Runtime, die OpenClaw benutzt, nicht aus irgendeinem Terminal, das zufällig funktioniert.
„Das Repo öffnet sich, aber Tools scheitern an Dateien“
Das ist meist ein Problem der Pfadübersetzung.
Fix: Repo in WSL halten, Pfad erst an der Bridge-Grenze konvertieren.
„Es ging kaputt, nachdem ich die Provider-Einstellungen geändert habe“
Dann vermischst du wahrscheinlich zwei Probleme: Modellzugriff und Runtime-Plumbing.
Fix: Erst die Bridge mit einem trivialen Prompt verifizieren, dann den Provider separat.
„Es scheitert nur auf gemounteten Laufwerken unter /mnt/c“
Überraschung: gar nicht so überraschend.
Fix: Aktive Entwicklungsarbeit ins Linux-Dateisystem verschieben, außer du hast einen wirklich guten Grund dagegen.
---
Das richtige mentale Modell
Denk an OpenClaw als Dirigenten, nicht als gesamtes Orchester.
WSL ist der Ort, an dem der Dirigent steht. Windows kann weiterhin mächtige Instrumente enthalten, inklusive Claude Code, GPU-Workloads oder anderer nativer Tools. Aber der Dirigent braucht eine saubere Partitur und klare Einsätze. Wenn jeder Befehl ad hoc die OS-Grenze überquert, zerfällt das Timing.
Sobald du die Bridge explizit machst, fühlt sich das Setup nicht mehr heimgesucht an.
Und genau das ist die eigentliche Lehre aus der aktuellen Welle von „mein OpenClaw-plus-Claude-Setup ist kaputt“-Posts. Die meisten dieser Systeme sind ohne Rewrite rettbar. Man muss nur Orchestrierung und Ausführung trennen, die Grenze normalisieren und aufhören so zu tun, als wären Windows und WSL eine einzige undifferenzierte Masse.
Wenn du das tust, bleibt OpenClaw das, was es sein soll: die Schicht, die dein Agent-System am Laufen hält, selbst wenn sich die Modelllandschaft unter deinen Füßen verschiebt.
TL;DR: OpenClaw in WSL betreiben, Repos im WSL-Dateisystem halten, Windows-Claude-Code bewusst mit Pfadkonvertierung bridgen und ein Fallback-Modell konfigurieren. Die meisten Berichte à la „Windows plus WSL OpenClaw ist kaputt“ sind Boundary-Bugs, keine Architekturfehler.