Bug type

Regression / local gateway connectivity

Summary

On WSL2, OpenClaw 2026.4.26 starts the local gateway service and binds 127.0.0.1:18789, but local clients fail to complete the WebSocket pre-auth/connect handshake. The gateway port is listening, and the service reports active (running), but CLI/dashboard/WebSocket clients time out or close before connect.

This appears related to the current gateway WebSocket handshake path rather than a missing binary, invalid config, or WSL being down.

Environment

• OpenClaw: 2026.4.26 (be8c246)
• OS: WSL2 Ubuntu 24.04.4 LTS on Windows
• Kernel: 6.6.87.2-microsoft-standard-WSL2
• Install method: npm global (~/.npm-global/bin/openclaw)
• Gateway mode: local loopback
• Gateway target: ws://127.0.0.1:18789
• Service: systemd user service openclaw-gateway.service
• Node used by service: /usr/bin/node

Symptoms

openclaw --version works:

OpenClaw 2026.4.26 (be8c246)

The config validates:

Config valid: ~/.openclaw/openclaw.json

The gateway service is active and logs that the HTTP server is listening:

Service: systemd (enabled)
Command: /usr/bin/node /home/venka/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Gateway: bind=loopback (127.0.0.1), port=18789
Runtime: running (... state active ...)
...
[gateway] http server listening (...; 35.0s)
[gateway] starting channels and sidecars...

But local connectivity checks fail:

Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/venka/.openclaw/openclaw.json
Bind: loopback

Gateway closed (1006 abnormal closure (no close frame)): no close reason

curl to the dashboard endpoint can also hang despite the port being bound:

curl: (28) Operation timed out after 10032 milliseconds with 0 bytes received

Gateway log evidence

Representative logs after restart:

[gateway] loading configuration…
[gateway] resolving authentication…
[gateway] starting...
[gateway] starting HTTP server...
[canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/
[health-monitor] started
[gateway] agent model: openrouter/tencent/hy3-preview:free
[gateway] http server listening (...; 35.0s)
[gateway] log file: /tmp/openclaw/openclaw-2026-04-28.log
[gateway] starting channels and sidecars...
[hooks] loaded 4 internal hook handlers
[ws] handshake timeout conn=... peer=127.0.0.1:<ephemeral>->127.0.0.1:18789 remote=127.0.0.1
[ws] closed before connect conn=... peer=127.0.0.1:<ephemeral>->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=http://127.0.0.1:18789 host=127.0.0.1:18789 ua=Mozilla/... code=1000 reason=n/a

The service can also become hard to stop gracefully:

Stopping openclaw-gateway.service...
openclaw-gateway.service: State 'stop-sigterm' timed out. Killing.
openclaw-gateway.service: Main process exited, code=killed, status=9/KILL
openclaw-gateway.service: Failed with result 'timeout'.

What was ruled out

• WSL itself is running (wsl -l -v shows Ubuntu running under WSL2).
• The OpenClaw binary exists and runs from ~/.npm-global/bin/openclaw.
• openclaw --version succeeds.
• openclaw config validate succeeds.
• The gateway service is active and binds 127.0.0.1:18789.
• This is not simply “port not listening”; the port is bound, but HTTP/WS readiness is broken.

Possible related issues / PRs

This may overlap with one or both of these current lines of work:

• [Bug]: Regression — channel sidecar startup again blocks for ~3 min after ready on v2026.4.25 (recurrence of #63450) #72846: v2026.4.25 regression where channel sidecar startup blocks after ready and local WS handshakes time out during that window.
• feat(gateway): make handshake timeout configurable via gateway.handshakeTimeoutMs #51282: open PR for configurable gateway.handshakeTimeoutMs; current 2026.4.26 source supports OPENCLAW_HANDSHAKE_TIMEOUT_MS but no config-file key.
• fix(gateway,proxy): bypass Windows proxy for localhost gateway connections #73474: open PR for Windows proxy env vars inherited by WSL breaking local gateway WebSocket connections. This environment is WSL, so inherited proxy behavior may be relevant, but the observed failure also occurs against literal 127.0.0.1.

Expected behavior

Local loopback clients should complete the gateway WebSocket connect challenge reliably once the gateway reports listening, or the gateway should not report itself as ready/listening until it can complete local WS handshakes.

Actual behavior

The gateway binds and appears active, but local HTTP/WS clients hang, hit handshake timeout, or close before connect. This makes CLI/dashboard usage unreliable or unusable while the service appears running.

Suggested investigation

• Confirm whether the v2026.4.25 sidecar startup blocker reported in [Bug]: Regression — channel sidecar startup again blocks for ~3 min after ready on v2026.4.25 (recurrence of #63450) #72846 is still present in v2026.4.26.
• Check whether channel/sidecar startup or runtime-context/chat-history work can block the WS pre-auth/connect challenge path after HTTP server bind.
• For WSL specifically, verify whether inherited Windows proxy env vars can still affect local loopback gateway clients in 2026.4.26, even with ws://127.0.0.1:18789.
• Consider a lightweight readiness probe that verifies the WebSocket connect challenge path, not just port bind / HTTP server creation.

Temporary workarounds to validate

Potential workarounds under investigation:

OPENCLAW_HANDSHAKE_TIMEOUT_MS=30000 openclaw status

and, for WSL/proxy suspicion:

env -u HTTP_PROXY -u HTTPS_PROXY -u ALL_PROXY -u http_proxy -u https_proxy -u all_proxy \
  openclaw status

No durable workaround has been confirmed yet for this exact 2026.4.26 WSL setup.