Summary

On WSL2, the OpenClaw gateway starts, binds, and accepts TCP connections, but never responds to HTTP/probe/control requests. This reproduces even with a clean HOME, --dev, loopback bind, and under both Node 25 and Node 22.

Environment

• OpenClaw: 2026.3.13 (61d171a)
• OS: WSL2 on Windows
• Node tested:
  • v25.6.1
  • v22.x via Homebrew node@22
• Install style:
  • npm global / Homebrew-backed Node

Observed behavior

Gateway appears to start normally and logs healthy startup, including:

• canvas host mounted
• heartbeat started
• health-monitor started
• browser server started
• listening on ws://127.0.0.1:18789

However:

• openclaw gateway probe times out
• openclaw gateway call health times out
• curl http://127.0.0.1:18789/ connects at TCP level, then hangs until timeout
• openclaw tui cannot connect

So the listener binds and accepts TCP, but never returns bytes or completes the control-plane handshake.

Expected behavior

• openclaw gateway probe should report reachable
• openclaw gateway call health should return a response
• curl http://127.0.0.1:18789/ should return some HTTP response instead of hanging
• TUI should connect to the local gateway

Minimal repro

mkdir -p /tmp/openclaw-clean-home
HOME=/tmp/openclaw-clean-home openclaw gateway run --dev --bind loopback --port 18789 --verbose

In another shell:

openclaw gateway probe
openclaw gateway call health
curl --max-time 5 http://127.0.0.1:18789/

Result

• openclaw gateway probe:
  • local loopback target ws://127.0.0.1:18789
  • connect failed: timeout
• openclaw gateway call health:
  • gateway timeout after 10000ms
• curl:
  • TCP connect succeeds
  • no bytes returned
  • times out after 5s

What was ruled out

• Not user config corruption:
  • reproduced with HOME=/tmp/openclaw-clean-home
  • reproduced with --dev
• Not service-manager only:
  • reproduced with foreground openclaw gateway run
  • not just the systemd unit
• Not TUI-specific:
  • gateway probe and gateway call health fail too
• Not bind mode:
  • tested with loopback
• Not only Node 25:
  • reproduced under Node 22 as well
• Not channel complexity / existing loaded state:
  • reproduced in minimal dev setup

Additional notes

• Foreground logs show apparently normal startup and no immediate crash.
• The process remains alive and can continue logging other runtime activity.
• Failure mode looks like:
  • listener binds
  • socket accepts
  • request/control handling never responds

Hypothesis

This looks like a gateway control-plane/request-handling wedge on WSL2, even in minimal dev mode.