openclaw - 💡(How to fix) Fix Android manual LAN setup parses `ws://` as host `ws` and resolves `http://ws:<port>`

Authorship note: This report was prepared by Otti, Ruben's OpenClaw assistant, at Ruben's request and based on Ruben's reproduced Android onboarding failure.

Summary

OpenClaw Android app v2026.4.5 appears to mishandle the Manual/Advanced setup host field when a private-LAN WebSocket URL is needed. The UI says private LAN ws:// is supported, but entering/attempting to use ws:// in Manual setup is parsed as hostname ws, and the app resolves the endpoint as http://ws:18789 instead of ws://192.168.178.57:18789 or a valid LAN WebSocket endpoint.

This then fails on the onboarding final check with the exact app status/error:

Gateway error: protocol mismatch

This looks related to, but distinct from:

• #85971 — Play Store Android app v2026.4.5 protocol mismatch against Gateway >= v2026.5.12
• #86364 — Android setup-code import rewrites wss Gateway URL to https (closed)
• #84287 — Play Store Android app v2026.4.5 cannot pair against gateways ≥ v2026.5.12 (closed as not planned)

The additional issue here is the Manual setup URL parsing/resolution itself: the app advertises private LAN ws:// support, but the Manual form does not allow users to get to a valid ws://<lan-ip>:<port> endpoint.

Environment

• Android app version: 2026.4.5
• Device: Google Pixel 8a
• Android: 16 (SDK 36)
• Route: same LAN / private LAN
• Gateway: OpenClaw 2026.5.19
• Gateway URL from openclaw qr --json: ws://192.168.178.57:18789
• Gateway address originally tried: http://192.168.178.57:18789
• Pairing/auth: not reached reliably; no new pending pairing request expected at this stage because the endpoint is resolved incorrectly before a valid pairing handshake can be established

What the app shows

On Android onboarding final check / Advanced setup:

Advanced setup
Paste setup code or enter host/port manually. Private LAN ws:// is supported, Tailscale/public hosts need wss://.

Manual selected
HOST: ws://
PORT: 18789
Use TLS: off
RESOLVED ENDPOINT: http://ws:18789

Screenshot evidence shows HOST containing ws:// and RESOLVED ENDPOINT becoming:

http://ws:18789

Final status/error:

Gateway error: protocol mismatch

Expected behavior

For private LAN, the app should either:

1. allow a full WebSocket URL in Manual setup, e.g.

ws://192.168.178.57:18789

and preserve it as the actual Gateway WebSocket endpoint; or

1. clearly separate host from scheme, e.g. HOST=192.168.178.57, PORT=18789, Use TLS=off, and resolve to:

ws://192.168.178.57:18789

At minimum, it should not convert ws:// into host ws and then resolve http://ws:18789.

Actual behavior

The app resolves the manual input to:

http://ws:18789

and the connection fails with:

Gateway error: protocol mismatch

Why this matters

The docs/setup flow state that mobile nodes connect to the Gateway over WebSocket and that private LAN ws:// setup codes are allowed. The Android UI itself also states that private LAN ws:// is supported. But the Manual flow currently gives users no obvious way to enter or preserve a valid LAN WebSocket endpoint.

This also makes diagnosis confusing, because the visible error is protocol mismatch, which looks like the already-reported v3/v4 app/gateway protocol issue, while the screenshot shows an additional URL-scheme/endpoint-resolution bug.

Local command outputs, sanitized

openclaw qr --json reports the expected LAN WebSocket URL:

{
  "gatewayUrl": "ws://192.168.178.57:18789",
  "auth": "token",
  "urlSource": "gateway.bind=custom"
}

openclaw devices list shows an already paired Pixel 8a entry, but this failed onboarding attempt did not produce a new pending pairing request. That is consistent with the endpoint being wrong before pairing/auth completes.

openclaw nodes status shows the Pixel 8a as known/paired but disconnected.

Suggested fix direction

• Treat ws:// and wss:// as connection schemes, not as hostname text.
• If Manual setup expects only a hostname, reject/prompt when the user enters a full URL instead of silently parsing ws:// as host ws.
• Ensure the resolved endpoint displayed to the user matches the actual connection scheme:
  • TLS off/private LAN → ws://host:port
  • TLS on/Tailscale/public → wss://host[:port]
• Consider adding a regression test for Manual endpoint resolution:
  • host 192.168.178.57, port 18789, TLS off → ws://192.168.178.57:18789
  • full URL ws://192.168.178.57:18789 → preserved or normalized to the same WebSocket endpoint, not http://ws:18789