openclaw - 💡(How to fix) Fix Android setup-code import rewrites wss Gateway URL to https

Summary

Android setup-code import appears to normalize a Gateway WebSocket endpoint from wss:// to https://, then fails to connect with a protocol mismatch because the Gateway endpoint expects WebSocket.

Environment

• Gateway/runtime: 2026.5.22
• Android App version: 2026.4.5
• Gateway config: gateway.tailscale.mode=serve, gateway.bind=loopback, token auth
• Tailscale Serve endpoint: as-mac-mini.dzo-bee.ts.net
• Android app: OpenClaw Android app, setup-code flow

What I observed

On the gateway machine, a fresh setup code generated with:

openclaw qr --remote --setup-code-only

Decodes to a payload with the correct WebSocket URL:

{
  "url": "wss://as-mac-mini.dzo-bee.ts.net",
  "hasBootstrapToken": true
}

A gateway probe to that URL succeeds:

openclaw gateway probe --url wss://as-mac-mini.dzo-bee.ts.net --json

The probe reports ok: true / rpcOk: true.

But when the Android app uses the setup code, it resolves/displays the endpoint as:

https://as-mac-mini.dzo-bee.ts.net

Then the app fails with a gateway protocol mismatch, identifying the protocol as https instead of wss.

Expected behavior

The Android app should preserve and connect to the setup-code url exactly as a Gateway WebSocket URL:

wss://as-mac-mini.dzo-bee.ts.net

If the UI wants to display an HTTPS origin for readability, the actual connection layer should still use wss://.

Actual behavior

Setup-code import appears to turn the endpoint into https://..., and the connection fails because the Gateway node transport is WebSocket-only.

Workaround

Manual/advanced Android connection works when using:

wss://as-mac-mini.dzo-bee.ts.net

or host as-mac-mini.dzo-bee.ts.net, port 443, TLS enabled, assuming the app does not rewrite the scheme.

Notes

This does not look like a setup-code generation bug. The generated setup-code payload contains wss://...; the mismatch happens after Android imports/resolves it.