False negative from openclaw gateway probe on Windows #45940
Description
Bug type
Regression (worked before, now fails)
Summary
After updating to OpenClaw 2026.3.13, openclaw gateway probe reports the local gateway as unreachable, but the gateway is actually working.
Environment
- OpenClaw:
2026.3.13 (61d171a) - OS:
Windows 10.0.26200 x64 - Node:
24.14.0 - Install method: global npm install
- Gateway: local loopback
ws://127.0.0.1:18789 - Service mode: Scheduled Task
The Control UI connects successfully, and openclaw status --deep reports the gateway as reachable.
Steps to reproduce
openclaw gateway start
openclaw gateway probe
openclaw status --deep
### Expected behavior
---
## Expected behavior
```text
If the gateway is operational and serving websocket requests successfully, `openclaw gateway probe` should not report a timeout or unreachable status.
### Actual behavior
`openclaw gateway probe` reports the local gateway as unreachable / timeout, even though the gateway is working, the Control UI connects successfully, and `openclaw status --deep` shows the gateway as reachable.
### OpenClaw version
2026.3.13 (61d171a)
### Operating system
Windows 10.0.26200 x64
### Install method
npm global
### Model
N/A (gateway probe / local gateway issue)
### Provider / routing chain
N/A for reproduction (local gateway / loopback websocket probe)
### Config file / key location
~/.openclaw/openclaw.json
### Additional provider/model setup details
This issue appears unrelated to provider/model routing. Repro is against the local loopback gateway (`ws://127.0.0.1:18789`) using the Windows Scheduled Task gateway service.
Logs, screenshots, and evidence
### Logs, screenshots, and evidence
```shell
`openclaw gateway probe` reports:
Gateway Status
Reachable: no
Probe budget: 3000ms
Targets
Local loopback ws://127.0.0.1:18789
Connect: failed - timeoutImpact and severity
Impact and severity
Affected: local Windows installations using the gateway probe command
Severity: Low to Medium (misleading health signal / false negative)
Frequency: Consistent in this environment
Consequence: makes troubleshooting confusing because `gateway probe` reports failure while the gateway is actually working
### Additional information
This appears to be either a false negative in `openclaw gateway probe`, a Windows-specific websocket handshake timing issue, or an inconsistency between probe logic, health checks, and scope handling (`operator.read`).
I observed:
- `openclaw gateway probe` -> timeout / unreachable
- `openclaw status --deep` -> gateway reachable
- Control UI works normally
- logs show successful websocket activity and successful `health` responses