Summary

On OpenClaw 2026.5.6 / Windows, the gateway can be listening and pass gateway health, while gateway probe and doctor still report it as unreachable/not running.

This looks related to earlier reports such as #74279 and #48360, but those conversations are locked, so I am filing a current-stable repro instead of adding there.

Environment

• OpenClaw: 2026.5.6 (c97b9f7)
• Node: v24.15.0
• OS: Windows
• Install: isolated npm install of openclaw@latest
• Profile: imladri-sidequest
• Gateway: loopback 127.0.0.1:18789

Reproduction

openclaw --profile imladri-sidequest gateway run --dev --port 18789 --auth none --bind loopback --force --allow-unconfigured --verbose
openclaw --profile imladri-sidequest gateway health
openclaw --profile imladri-sidequest gateway probe
openclaw --profile imladri-sidequest doctor --non-interactive

Observed

gateway health succeeds:

Gateway Health OK (1327ms)

gateway probe reports unreachable:

Reachable: no
Connect: failed - timeout
Found 0 gateways via Bonjour

doctor --non-interactive reports a contradiction:

• Gateway not running
• but also detects port 18789 in use by the gateway PID and recommends stopping/changing the port

A direct TCP check confirms 127.0.0.1:18789 is listening.

Expected

If the gateway listener is alive and gateway health succeeds, then gateway probe / doctor should either report the gateway as reachable or clearly explain the specific auth/probe-path failure instead of reporting it as not running.

Notes

This run also reproduced the --auth none / device identity required issue tracked in #75780. That may be part of why the probe path fails, but the resulting CLI diagnostics are still misleading for a local user: one built-in command says healthy while another says unreachable/not running.