openclaw - 💡(How to fix) Fix Protocol mismatch spam after rollback: local client still identifies as cli v2026.5.12 against 2026.5.7 gateway [2 pull requests]

Summary

After updating to 2026.5.12 and later rolling back to 2026.5.7, the local gateway continues to receive loopback connections from a client identifying as cli v2026.5.12, causing continuous protocol mismatch spam roughly once per second.

This persists even though:

• openclaw --version is 2026.5.7
• the running gateway is 2026.5.7
• the gateway was restarted successfully

This appears to be a stale local OpenClaw-managed client/helper/runtime surviving rollback.

Related context

I previously reported the 2026.5.12 Codex embedded timeout issue that was fixed in PR #82142.

This new issue appeared in the same update/rollback window, but seems to be a different failure mode:

• PR #82142: Codex accepted-turn timeout/watchdog issue
• this report: stale local client still presenting as cli v2026.5.12 after rollback, repeatedly hitting the 2026.5.7 gateway

Environment

• macOS 26.2
• Gateway bind: 127.0.0.1:18789
• OpenClaw gateway version: 2026.5.7
• openclaw --version: 2026.5.7
• Gateway running via LaunchAgent

Symptoms

Gateway error log continuously shows loopback protocol mismatches like:

2026-05-17T09:49:07.286+08:00 [ws] protocol mismatch ... client=cli cli v2026.5.12
2026-05-17T09:49:07.298+08:00 [ws] closed before connect ... code=1002 reason=protocol mismatch

This repeats about once per second with changing local ephemeral ports.

Also seen occasionally:

code=1008 reason=connect failed

Timeline

• Friday update/rollback window appears to be when this started
• Update-related restarts were recorded on 2026-05-15
• By Sunday 2026-05-17, the repeated local protocol mismatch traffic was still active

What I verified

• openclaw --version returns 2026.5.7
• global package version on disk is 2026.5.7
• LaunchAgent plist/env also indicate 2026.5.7
• running gateway process is 2026.5.7
• no obvious second OpenClaw install tree under /usr/local/lib/node_modules
• no useful stale version markers found under ~/Library/Application Support/OpenClaw

What I tested / ruled out

1. Restarted the gateway successfully

   • old gateway PID changed to a new PID
   • mismatch spam resumed immediately against the new gateway process

2. Closed Chrome / dashboard

   • no change

3. Killed openclaw-logs

   • no change

4. Killed parent openclaw wrapper/session process

   • no change

5. Killed continuous obsidian-headless sync process

   • no change

6. Confirmed the issue persists after rollback with:

   • gateway at 2026.5.7
   • CLI on disk at 2026.5.7

Impact

• Gateway otherwise remains functional
• But the logs get spammed continuously
• Deep status/audit/probe behavior becomes noisy/confusing because the local retrying incompatible client is always present

Expected behavior

After rollback to 2026.5.7, no local OpenClaw-managed helper/client/runtime should continue identifying as cli v2026.5.12 or repeatedly attempting incompatible loopback connections to the gateway.

Likely bug area

This looks like one of:

• stale local OpenClaw helper/client runtime surviving rollback
• background reconnect loop not version-aligned after downgrade
• hidden/managed local client process retaining newer protocol version state in memory or cache

Extra evidence

At one point during tracing, loopback traffic was seen from OpenClaw-related helper processes, but killing those did not eliminate the root problem, which suggests the retrying source is deeper than the obvious visible helper wrappers.

If useful, I can provide more sanitized log excerpts / timestamps from the local investigation.