Protocol Mismatch

[rriggs]

Autensa logs show the following when attempting to connect to OpenClaw v2026.5.9-beta1

[OpenClaw] Connecting to: ws://127.0.0.1:18789/?token=***
[OpenClaw] Token in URL: true
[OpenClaw] WebSocket opened, waiting for challenge...
[OpenClaw] Cache cleanup: removed 1 entries (size: 126 -> 125)
[OpenClaw] Received: ...
[OpenClaw] Challenge received, responding...
[OpenClaw] Device identity prepared: {
  deviceId: '...,
  hasSignature: true,
  nonce: '...'
}
[OpenClaw] Sending challenge response
[OpenClaw] Received: res:914d165c
[OpenClaw] Disconnected from Gateway (code: 1002, reason: "protocol mismatch", wasClean: true)

On the gateway we see the following logged:

{
  "0": "{\"subsystem\":\"gateway/ws\"}",
  "1": {
    "cause": "protocol-mismatch",
    "handshake": "failed",
    "durationMs": 6,
    "lastFrameType": "req",
    "lastFrameMethod": "connect",
    "lastFrameId": "1e6fc9b2-b8cd-4f8a-9c73-0da6f45ceb8f",
    "host": "127.0.0.1:18789",
    "remoteAddr": "127.0.0.1",
    "remotePort": 54548,
    "localAddr": "127.0.0.1",
    "localPort": 18789,
    "endpoint": "127.0.0.1:54548->127.0.0.1:18789",
    "minProtocol": 3,
    "maxProtocol": 3,
    "expectedProtocol": 4,
    "client": "cli",
    "mode": "ui",
    "version": "1.0.1",
    "platform": "linux"
  },
  "2": "closed before connect conn=22de2480-105b-48ce-a75d-41108ef40e18 peer=127.0.0.1:54548->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1005 reason=n/a",
  "_meta": {
    "runtime": "node",
    "runtimeVersion": "22.22.2",
    "hostname": "unknown",
    "name": "{\"subsystem\":\"gateway/ws\"}",
    "parentNames": [
      "openclaw"
    ],
    "date": "2026-05-12T18:58:59.759Z",
    "logLevelId": 4,
    "logLevelName": "WARN",
    "path": {
      "fullFilePath": "file:///home/openclaw/openclaw/dist/subsystem-Dk7fl3Q1.js:149:51",
      "fileName": "subsystem-Dk7fl3Q1.js",
      "fileNameWithLine": "subsystem-Dk7fl3Q1.js:149",
      "fileColumn": "51",
      "fileLine": "149",
      "filePath": "openclaw/dist/subsystem-Dk7fl3Q1.js",
      "filePathWithLine": "openclaw/dist/subsystem-Dk7fl3Q1.js:149",
      "method": "logToFile"
    }
  },
  "time": "2026-05-12T11:58:59.759-07:00",
  "hostname": "diamond",
  "message": "closed before connect conn=22de2480-105b-48ce-a75d-41108ef40e18 peer=127.0.0.1:54548->127.0.0.1:18789 remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1005 reason=n/a"
}

This seems to be the relevant bit:

    "minProtocol": 3,
    "maxProtocol": 3,
    "expectedProtocol": 4,

[crshdn]

Looks like a new OpenClaw change caused this. Im on it.

[crshdn]

Hi @rriggs — thanks for the detailed report (the gateway log line expectedProtocol: 4 made this unambiguous).

Root cause: OpenClaw v2026.5.9-beta.1 bumped its WebSocket gateway protocol from v3 to v4 (their CHANGELOG calls out "move Canvas/A2UI clients to gateway protocol v4 plugin surfaces"). Mission Control's connect handshake was hardcoded to advertise only minProtocol: 3, maxProtocol: 3, so the v4 gateway closes every connection with code 1002 / "protocol mismatch" before it ever processes the connect request.

Fix: Draft PR #138 (fix/openclaw-protocol-v4) widens MC's advertised range to [3, 4] so it connects against both stable v3 and the v4 beta. I diffed the v3 vs v4 OpenClaw bundles and verified the wire contract for every RPC MC sends is unchanged across versions, so this should be a clean drop-in.

Asking for your help to verify before we merge:

git fetch origin
git checkout fix/openclaw-protocol-v4
npm install
npm run dev

Then point Mission Control at your OpenClaw v2026.5.9-beta.1 gateway and try:

1. The initial WebSocket connection (the original failure mode)
2. Listing sessions / agents
3. Anything else you'd normally exercise

If it connects and basic functionality works, drop a comment here and we'll merge to main. If anything still breaks, gateway logs from the failing operation would help — there could be something in v4 we haven't caught.

Thanks again for the report and for running a beta gateway!

[CameronVetter]

I dont think thats a complete fix, but its a start. This version bump does allow some communication to resume, but it seems like some aspects of the communication are not working correctly. What I'm seeing:

1. mission-control dispatches work to openclaw
2. Openclaw creates a session and gets to work (like normal)
3. mission control eventually ends up in a "Dispatch blocked" state. Dispatch did not start a tracked session.
4. In a chat initiated work scenario, I eventually saw this in the logs:

I also saw a response in the chat of the card, but it still stayed stuck. My versions:
Openclaw 2026.5.12
mission-control direct from branch - fix/openclaw-protocol-v4