OpenClaw on WSL, Claude Code on Windows: The Stable Bridge Without the Yak Shaving

The Problem Everyone Is Hitting This Week

A very specific OpenClaw failure mode is suddenly showing up in public: people have Claude Code installed on Windows, OpenClaw running inside WSL, and a setup that feels like it should work, but does not.

The symptoms are boring in the worst possible way. Commands work in one shell but not the other. OpenClaw can see files under Linux paths, Claude Code expects Windows paths, and environment variables exist in one world but vanish in the next. Then Anthropic policy turbulence enters the chat, people start swapping providers or changing access patterns, and the whole stack turns into “I swear this worked yesterday.”

The good news is that this is not an OpenClaw architecture problem. It is a boundary problem. Once you define the boundary clearly, the setup becomes predictable.

The short version:

That is the whole game.

---

Why This Breaks in the First Place

WSL is good, but it is not “Linux inside Windows with zero seams.” It is a Linux environment sharing a machine with Windows. Those seams matter a lot for agent tooling.

OpenClaw cares about a few things:

1. Where commands run

2. What files are visible from that runtime

3. Which credentials are available in that runtime

4. Whether child processes inherit the right environment

5. Whether path assumptions are consistent from end to end

A mixed Windows plus WSL setup introduces ambiguity on every single one.

Typical examples:

If you treat this like one flat machine, you lose hours. If you treat it like two environments with a controlled bridge, it becomes manageable.

---

The Architecture That Actually Works

The cleanest pattern is this:

If you can install Claude Code directly inside WSL, do that. It removes a whole category of pain.

If you cannot, or you specifically want to keep Claude Code managed on Windows, then create a thin wrapper instead of relying on accidental interoperability.

Conceptually, the wrapper does three jobs:

1. Accept a call from WSL

2. Convert the working directory into a Windows path

3. Invoke Claude Code on Windows with explicit arguments

The important part is not the wrapper language. Bash, PowerShell, Python, whatever. The important part is that the bridge is explicit.

Example shape:

<pre><code># From WSL, call a Windows-side command intentionally

/mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe -ExecutionPolicy Bypass -File C:Usersyouinclaude-bridge.ps1 -ProjectPath "$(wslpath -w "$PWD")" -Prompt "Summarize this repo and propose next steps"

</code></pre>

Notice what is missing: guesswork. We are not hoping Windows understands a Linux path. We are converting it on purpose.

---

The Three Checks to Run Before You Touch OpenClaw Config

Do these before you blame the agent.

1. Can WSL call the Windows binary at all?

From WSL:

<pre><code>/mnt/c/Windows/System32/cmd.exe /c where claude

</code></pre>

If that fails, stop there. OpenClaw will not magically fix missing executables.

2. Can you pass the current repo path across the boundary?

From the repo root in WSL:

<pre><code>wslpath -w "$PWD"

</code></pre>

If the output is nonsense or points to a mounted path with broken permissions, fix your repo location first. For active coding work, the WSL filesystem is usually more reliable than working directly inside <code>/mnt/c</code>.

3. Are your credentials present where OpenClaw runs?

Do not assume Windows env vars bleed into WSL. They often do not in the way you expect.

Check inside WSL:

<pre><code>echo "$ANTHROPIC_API_KEY"

echo "$OPENROUTER_API_KEY"

echo "$GOOGLE_API_KEY"

</code></pre>

If these are empty, your agent runtime does not have what it needs, even if PowerShell does.

---

Recommended Setup: Keep the Working Copy in WSL

This is the highest leverage fix.

Put your real agent-facing repos under the Linux filesystem, not under the Windows mount. For example:

<pre><code>~/projects/my-app

~/.openclaw/workspace

</code></pre>

Why this matters:

If Claude Code must stay on Windows, let the bridge convert from WSL path to Windows path at call time. That is much cheaper than making your entire project live in a compromise directory.

---

How to Configure OpenClaw Without Making It Fragile

Your goal is not “make every tool available everywhere.” Your goal is “make the orchestrator able to launch the specific things it needs consistently.”

That means:

A sane pattern is to define one stable command that OpenClaw can call, for example <code>claude-bridge</code>, and let that script handle the Windows hop.

Then your agent instructions can stay boring:

Boring is good here.

---

Add a Fallback Model Now, Not During an Incident

This part matters more after the recent Anthropic drama.

A mixed OpenClaw setup should never have a single brittle dependency. If your preferred coding path is Claude Code on Windows, great. Keep it. But add at least one fallback path for when auth changes, provider access wobbles, or the bridge breaks.

Practical fallback options:

The strategic point is simple: OpenClaw is strongest when orchestration is stable even if one model path is not.

---

Common Failure Modes and the Real Fix

“Claude works in PowerShell but not from OpenClaw”

That usually means OpenClaw cannot see the executable or the key in WSL.

Fix: test the command from the same runtime OpenClaw uses, not from a random terminal that happens to work.

“The repo opens, but tools fail on files”

That is usually a path translation issue.

Fix: keep the repo in WSL, convert path only at the bridge boundary.

“It broke after I changed model provider settings”

You probably mixed two problems: model access and runtime plumbing.

Fix: verify the bridge first with a trivial prompt, then verify the provider separately.

“It only fails on mounted drives under /mnt/c”

Not shocking.

Fix: move active development work into the Linux filesystem unless you have a very strong reason not to.

---

A Good Mental Model

Think of OpenClaw as the conductor, not the entire orchestra.

WSL is where the conductor stands. Windows can still contain powerful instruments, including Claude Code, GPU workloads, or other native tools. But the conductor needs a clean score and clear cues. If every command crosses the OS boundary in an ad hoc way, timing falls apart.

Once you make the bridge explicit, the setup stops feeling haunted.

And that is really the whole lesson from this week’s wave of “my OpenClaw plus Claude setup broke” posts. Most of these systems are recoverable without a rewrite. They just need someone to separate orchestration from execution, normalize the boundary, and stop pretending Windows and WSL are one undifferentiated blob.

If you do that, OpenClaw remains what it is supposed to be: the layer that keeps your agent system operational even when the model landscape shifts under your feet.

TL;DR: Run OpenClaw inside WSL, keep repos in the WSL filesystem, bridge to Windows Claude Code intentionally with path conversion, and keep a fallback model configured. Most “Windows plus WSL OpenClaw is broken” reports are boundary bugs, not architecture failures.