Description

v2026.2.19 introduced a hard security check in isSecureWebSocketUrl() that throws SECURITY ERROR for any ws:// connection to a non-loopback address. This completely breaks CLI commands (openclaw status, openclaw devices, openclaw doctor, etc.) for users who run gateway.bind: "lan" with Tailscale.

Environment

• OpenClaw: v2026.2.19-2
• OS: Windows 10 (10.0.19045)
• Node: v24.6.0
• Tailscale: active, IP 100.94.193.120

Steps to Reproduce

1. Set gateway.bind: "lan" (needed for phone node access over Tailscale)
2. Update to v2026.2.19
3. Run any CLI command: openclaw status, openclaw devices, etc.

Expected Behavior

CLI connects to the gateway. Tailscale traffic is WireGuard-encrypted end-to-end, so ws:// over Tailscale is effectively as secure as wss://.

Actual Behavior

SECURITY ERROR: Gateway URL "ws://100.94.193.120:18789" uses plaintext ws:// to a non-loopback address.
Both credentials and chat data would be exposed to network interception.

Even --url ws://localhost:18789 is ignored — the check still resolves the LAN IP from config.

Impact

• All CLI commands are broken (status, devices, doctor, security audit, etc.)
• Gateway itself runs fine (Discord/messaging works)
• The --url override doesn't bypass the check
• No config option to allowlist trusted networks

Suggested Fix

One or more of:

1. Detect Tailscale IPs (100.64.0.0/10 CGNAT range) and treat them as trusted (WireGuard-encrypted)
2. Add gateway.security.allowInsecureWs: true config override for advanced users
3. Honor --url override and skip the auto-detected LAN IP check
4. Make this a warning instead of a hard error, with --force to proceed

Workaround

Switching to Tailscale Serve mode may work but is a significant config change. Rolling back to v2026.2.17 restores full functionality.