openclaw - 💡(How to fix) Fix Control UI protocol mismatch in 2026.5.16-beta.4 prevents dashboard entry

Summary

After upgrading to OpenClaw 2026.5.16-beta.4 (38c3a8d), the bundled Control UI could not enter the dashboard even though the gateway itself was healthy.

The immediate handshake failure was a Gateway protocol mismatch: the Control UI bundle advertised protocol 4, while the gateway expected protocol 5.

Environment

• OpenClaw: 2026.5.16-beta.4 (38c3a8d)
• Platform: macOS, local LaunchAgent gateway
• Gateway URL: http://127.0.0.1:18789/
• Browser UA from the failed connect attempt included: Codex/26.513.31313 Chrome/148.0.7778.97 Electron/42.0.1

Symptoms

openclaw gateway status and openclaw health reported the gateway as running/OK, but the Control UI failed during WebSocket handshake.

Observed log detail:

protocol mismatch ... minProtocol:4 maxProtocol:4 expectedProtocol:5 minimumProbeProtocol:5

The installed npm package showed the mismatch directly:

• dist/control-ui/assets/index-DNE1hUq_.js contained minProtocol:4,maxProtocol:4
• dist/version-CSUXetqM.js contained PROTOCOL_VERSION = 5 and MIN_CLIENT_PROTOCOL_VERSION = 5

Expected behavior

The Control UI bundle shipped in the npm package should advertise the same Gateway protocol levels as the gateway runtime in the same package.

Actual behavior

The package shipped a stale Control UI bundle advertising protocol 4, while the bundled gateway runtime required protocol 5, so the dashboard could not complete the connection handshake.

Workaround used locally

Patching the installed Control UI bundle to advertise protocol 5 moved the failure past the protocol mismatch. After that, opening the token-authenticated dashboard URL from openclaw dashboard --no-open was required for auth.

Proposed fix

I opened a PR that adds a release-package guard so release:openclaw:npm:check rejects npm packages whose packed Control UI JS advertises minProtocol/maxProtocol values that differ from src/gateway/protocol/version.ts.