Sunday, March 22, 2026
Breaking
Linux Foundation announces $500M open-source infrastructure fund Rust 2.0 release candidate now available for testing GitHub reports 200 million repositories milestone EU passes landmark open-source sovereignty legislation OpenClaw AI orchestration framework passes 50K GitHub stars Linux Foundation announces $500M open-source infrastructure fund Rust 2.0 release candidate now available for testing GitHub reports 200 million repositories milestone EU passes landmark open-source sovereignty legislation OpenClaw AI orchestration framework passes 50K GitHub stars
Article

OpenClaw Fixes WSL2 Ollama Connection Failures for Good

A new OpenClaw fix forces IPv4 when running Ollama under WSL2, ending the cryptic 'TypeError: fetch failed' errors that plagued Windows users running local models.

Cody
Cody
OpenClaw Fixes WSL2 Ollama Connection Failures for Good

If you've been running OpenClaw inside WSL2 with Ollama on the Windows host side, you've almost certainly hit it: a terse TypeError: fetch failed that appears at random, with no hint of what's actually wrong. A merge landed today that permanently fixes this by detecting the WSL2 environment and forcing IPv4 connections to Ollama.

PR #55435 by @kinfey lands three targeted fixes across the Ollama networking stack.

The Root Cause

WSL2 on Windows uses a virtual network interface that supports both IPv4 and IPv6. Node.js's undici HTTP client has an autoSelectFamily option that, when enabled, tries IPv6 first. This is perfectly fine on a standard Linux machine — but inside WSL2, the IPv6 path to the Windows host (where Ollama listens) is frequently unstable or unreachable, causing connections to silently fail.

The fix is precise: when isWSL2Sync() returns true and autoSelectFamily would otherwise be enabled, OpenClaw now overrides it to false, forcing IPv4. IPv4 routing to the Windows host is reliable in WSL2, so Ollama requests land correctly every time.

Better Error Diagnostics

Even when the fix isn't triggered, the error surface has improved significantly. Previously, undici-wrapped errors only showed the top-level TypeError: fetch failed — the nested error.cause.message that contains the actual networking detail was swallowed.

Two files now surface that inner cause:

  • ollama-stream.ts — the user-visible error now appends the cause message, so you see something like TypeError: fetch failed — ECONNREFUSED 127.0.0.1:11434 instead of a bare type error
  • models-config.providers.discovery.ts — Ollama provider discovery failures log the same nested cause, making it easier to diagnose why model listing fails during startup

Does This Affect You?

This fix applies if:

  1. You're running OpenClaw inside WSL2 (not native Linux, not macOS)
  2. Ollama is installed on the Windows host (the common setup, not inside WSL2 itself)
  3. You've seen intermittent TypeError: fetch failed during model streaming or provider discovery

If all three match, this fix will make those errors disappear. If you're running Ollama natively inside WSL2 (less common), the IPv4 override doesn't apply and nothing changes for you.

When to Expect It

The change is merged to main and will be included in the next OpenClaw release. If you're running from a main build or want the fix immediately, you can pull the latest and rebuild. Otherwise, watch the releases page — it'll arrive in the next numbered build.

WSL2 + Ollama is one of the most popular local-model setups for Windows developers, and this fix has been a long time coming. If you've been working around it with manual IPv4 binding, you can drop that workaround once the release ships.

Daily Briefing

Get the Open-Source Briefing

The stories that matter, delivered to your inbox every morning. Free, no spam, unsubscribe anytime.

Join 45,000+ developers. No spam. Unsubscribe anytime.