Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

The browser Control UI still advertises Gateway protocol range 4..4 while current Gateway expects protocol 5, so the Gateway rejects the browser handshake with code=1002 reason=protocol mismatch.

Steps to reproduce

1. Run a current source checkout where src/gateway/protocol/version.ts defines PROTOCOL_VERSION = 5.
2. Start the Gateway on loopback port 18789.
3. Run pnpm ui:dev and open the Control UI served by Vite.
4. Let the browser Control UI connect to ws://127.0.0.1:18789.

Expected behavior

The Control UI should advertise the shared Gateway client protocol range and complete the connect handshake against the current Gateway protocol.

Actual behavior

The Gateway rejects repeated browser Control UI handshakes because the client advertises minProtocol: 4 and maxProtocol: 4 while the Gateway expects protocol 5.

OpenClaw version

Current main source checkout at 549a0ea313104d213bbe90e924acd6027bbd84c7.

Operating system

Windows browser client; Gateway log user agent reports Windows NT 10.0 / Win64.

Install method

Source checkout with pnpm ui:dev against a locally running Gateway.

Model

NOT_ENOUGH_INFO

Provider / routing chain

NOT_ENOUGH_INFO

Additional provider/model setup details

NOT_ENOUGH_INFO

Logs, screenshots, and evidence

Observed browser dev-server repro:
pnpm ui:dev
Vite served http://localhost:5173/
Opening the UI against ws://127.0.0.1:18789 produced repeated Gateway closes:
code=1002 reason=protocol mismatch

Redacted Gateway log excerpt:
protocol mismatch remote=127.0.0.1 client=openclaw-control-ui webchat vcontrol-ui
closed before connect remote=127.0.0.1 origin=http://localhost:5173 host=localhost:18789 code=1002 reason=protocol mismatch

Structured handshake details from the same log class:
cause=protocol-mismatch
handshake=failed
lastFrameType=req
lastFrameMethod=connect
host=localhost:18789
origin=http://localhost:5173
minProtocol=4
maxProtocol=4
expectedProtocol=5
minimumProbeProtocol=5
client=openclaw-control-ui
mode=webchat
version=control-ui
platform=Win32

Current source:
src/gateway/protocol/version.ts:
export const PROTOCOL_VERSION = 5 as const;
export const MIN_CLIENT_PROTOCOL_VERSION = 5 as const;
export const MIN_PROBE_PROTOCOL_VERSION = 5 as const;

ui/src/ui/gateway.ts before the fix:
export type GatewayConnectParams = { minProtocol: 4; maxProtocol: 4; ... }
private buildConnectParams(...) { return { minProtocol: 4, maxProtocol: 4, ... } }

Impact and severity

Affected: browser Control UI users connecting to a Gateway after the protocol 5 bump.
Severity: High; the browser operator UI cannot connect.
Frequency: At least 6 repeated rejected handshakes were observed in the same local Gateway log window, plus the pnpm ui:dev repro.
Consequence: Chat, config, nodes, logs, and device approval surfaces in the browser Control UI are unavailable.

Additional information

Related earlier protocol-mismatch issues exist for stale protocol 3/4 clients and macOS appcast publishing, but this is a current-main protocol 4/5 mismatch in the browser Control UI source. The current source still hardcodes protocol 4 in ui/src/ui/gateway.ts while the Gateway protocol constants are 5.