Startup log:

[gateway] auth mode=none explicitly configured; all gateway connections are unauthenticated.
[canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root /root/.openclaw/canvas)
[heartbeat] started
[health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
[gateway] agent model: moonshot/kimi-k2.5
[gateway] listening on ws://127.0.0.1:18789, ws://[::1]:18789
[browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=off)

Failing websocket log:

[ws] closed before connect conn=... remote=127.0.0.1 fwd=... origin=https://<redacted>.ts.net host=<redacted>.ts.net ua=Mozilla/5.0 (...) code=1008 reason=pairing required

Before adding trustedProxies, logs showed:

Proxy headers detected from untrusted address. Connection will not be treated as local.

After adding:

"trustedProxies": [
  "127.0.0.1/32",
  "::1/128"
]

that proxy trust message disappeared, but pairing required remained.

CLI local loopback also failed:

gateway connect failed: Error: pairing required

[openclaw] Failed to start CLI: Error: gateway closed (1008): pairing required
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /root/.openclaw/openclaw.json

**Impact and severity**

Affected: Remote Control UI users accessing OpenClaw through Tailscale Serve on a remote host
Severity: High (blocks chat usage remotely)
Frequency: 100% repro in this setup
Consequence: Dashboard loads, but remote chat is unusable and the apparent pairing approval path is also blocked

Additional information

This appears to be specific to remote Control UI / remote browser device behavior.

Local OpenClaw on my PC works normally on the same version (`2026.3.8`), so this may be a regression or a remote-pairing-specific bug rather than a general gateway failure.

I also tested:
- `gateway.mode = remote`
- `gateway.mode = local`
- `gateway.auth.mode = token`
- `gateway.auth.mode = none`

The issue persisted after disabling gateway auth entirely and after fixing proxy trust.

Open question: is this expected behavior for remote Control UI chat over Tailscale, or is the pairing path broken/regressed in this scenario?