openclaw - 💡(How to fix) Fix OpenClaw 2026.5.4 Gateway status/health inconsistency on WSL2: diagnostics report ok/listener, external checks show no listener and HTTP 000 [2 comments, 2 participants]

Summary

OpenClaw Gateway on WSL2 does not maintain a stable externally observable loopback listener on port 18789. Local socket and HTTP checks repeatedly report no listener and HTTP 000 for /healthz and /readyz, but the official diagnostics bundle can report Gateway status/health as ok/running with a loopback listener category.

Environment

• OpenClaw version: 2026.5.4 (325df3e)
• Runtime: WSL2 Ubuntu with nvm-backed Node
• Auth route category: openai-codex/*
• Gateway target: loopback-only, port 18789
• Public bind: not detected

Symptom

• Gateway service reports active/enabled in local reports.
• No stable listener on 127.0.0.1:18789 or [::1]:18789.
• /healthz returns HTTP 000.
• /readyz returns HTTP 000.
• Windows-to-WSL loopback works with a temporary Python server, so WSL forwarding and Windows firewall/Avast are not currently indicated as the primary cause.

Diagnostics Review

The official diagnostics export ZIP was reviewed locally using only sanitized files. No raw logs/config/tokens are included here.

Safe observations from the sanitized bundle:

• ZIP hash matched the expected local SHA256.
• Sanitized config parsed successfully.
• Gateway config category is local/loopback on port 18789 with Tailscale off.
• Sanitized status snapshot reports wrapper status ok, service running, bind host 127.0.0.1, port 18789, port busy, and listener count 1.
• Sanitized health snapshot reports wrapper status ok.
• Sanitized event-loop category is degraded.
• Sanitized plugin errors are present.
• Sanitized config audit has 3 recommended-level entries.
• Exact strings searched but not found: runtime-dependency, exception, plugin-runtime-deps, prestageGatewayBundledRuntimeDeps, npm install, ENOTEMPTY, gateway.startup_failed.

This means the previous runtime-dependency/startup-exception classification is only partially supported. The stronger current issue is a mismatch between independent local listener/HTTP checks and the status/health categories captured by OpenClaw diagnostics.

Attempts Already Made

• Controlled Gateway restart loop with delayed stabilization checks.
• systemctl --user daemon-reload plus restart.
• OpenClaw-managed gateway stop/start.
• Documented systemd user-service runtime hardening drop-in.
• Gateway-only uninstall/install refresh without --force.
• Stable update to OpenClaw 2026.5.4 plus Gateway refresh/start.
• Narrow plugin dependency inspection attempt; documented openclaw plugins deps command was not usable in installed 2026.5.4.
• Read-only doctor, diagnostics export, and stability evidence collection.
• Sanitized diagnostics ZIP review and issue-package preparation.

Safety Notes

• No public/LAN/Tailscale exposure was configured.
• No channels/webhooks/mobile/browser profiles were configured.
• No auth/model route changes were made during diagnostics.
• Raw logs/config/tokens are not included in this issue body.

Diagnostics Artifact

I have a local OpenClaw diagnostics export zip produced by:

openclaw gateway diagnostics export --json --output <local ignored path>

The bundle is being treated as sensitive until manually reviewed. It can be attached or shared through an approved support channel if requested.

Local metadata:

• File name: openclaw-diagnostics.zip
• Size: 6046 bytes
• SHA256: 593A826D5DE9EFEAADEB41A4F2851DAF78421999AD17036388F1DB8E82814246

Questions

• Why can the diagnostics status/health snapshot report ok/running/listener while repeated independent socket and HTTP checks see no stable listener and HTTP 000?
• Is event-loop degraded plus plugin errors enough to explain this active/running but externally unreachable behavior?
• Is openclaw plugins deps expected to exist in 2026.5.4? Official docs reference it, but the installed CLI returned an unknown/unusable command category in local testing.