openclaw - 💡(How to fix) Fix v2026.5.22 regression: nativeHook.invoke 'native hook relay not found' breaks Telegram voice flow + downgrade blocked by forward-incompat config

Summary

Two related regressions in OpenClaw 2026.5.22 affecting Telegram-channel voice-note processing and the ability to downgrade to recover.

Bug 1 — nativeHook.invoke: native hook relay not found on Telegram inbound

After upgrading from 2026.5.20 → 2026.5.22, Telegram inbound voice notes routed through a configured persona (in our case clordlethird — a channels.telegram.accounts entry) return "Something went wrong while processing your request. Please try again." to the user.

Gateway log (~/Library/Logs/openclaw/gateway.log) shows the cause:

2026-05-25T20:02:27.209+01:00 [ws] ⇄ res ✗ nativeHook.invoke 2ms errorCode=INVALID_REQUEST errorMessage=native hook relay not found conn=0a06fd94…2c0d id=70b1bb92…d291
[…7 more identical errors in a 25ms window across different conn ids…]
2026-05-25T20:10:19.885+01:00 [ws] ⇄ res ✗ nativeHook.invoke 0ms errorCode=INVALID_REQUEST errorMessage=native hook relay not found conn=43ffc24f…3da0 id=a29f4143…e575
2026-05-25T20:17:42.052+01:00 [ws] ⇄ res ✗ nativeHook.invoke 0ms errorCode=INVALID_REQUEST errorMessage=native hook relay not found conn=fd3774ac…9bea id=0db2fa71…57d4

Bursts coincide with inbound voice notes arriving on the configured telegram persona. The error suggests something in the message-processing pipeline calls nativeHook.invoke for a hook ID that the relay registry doesn't have registered.

Same config on 2026.5.20 works without these errors — verified on a peer machine that downgraded successfully.

Environment

• macOS 26 Tahoe (Mac mini, arm64)
• OpenClaw 2026.5.22 installed via npm install -g [email protected]
• 3 telegram personas configured: default, clawdiboi2, clordlethird
• Codex ChatGPT-OAuth (gpt-5.5, thinking=xhigh)
• OPENCLAW_CODEX_COMPACTION_WAIT_TIMEOUT_MS=3600000, NODE_OPTIONS=--max-old-space-size=8192
• Compaction provider spoof active (model_provider=openai-custom, related to issue #86019)

Bug 2 — 5.20 binary refuses to start against 5.22-written config (forward-incompat schema)

When attempting to downgrade after Bug 1:

$ npm install -g [email protected]  # succeeds
$ openclaw gateway restart
Gateway restart blocked: Refusing to restart the gateway service because this OpenClaw binary (2026.5.20) is older than the config last written by OpenClaw 2026.5.22.
Tip: Set OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 only for an intentional downgrade or recovery action.

$ OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 openclaw gateway restart
Service runtime: status=stopped, state=active
Gateway port 18789 status: free.
Gateway restart failed after 14s: service stayed stopped and health checks never came up.

Gateway then enters EX_CONFIG (exit 78) respawn death-loop:

2026-05-25T20:18:35.351+01:00 [gateway] loading configuration…
2026-05-25T20:18:46.111+01:00 [gateway] loading configuration…
[…every ~11s, never progressing past config-load…]

So the OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 bypass lets 5.20 TRY to start but a real schema-format incompatibility prevents it. The forward-incompat field is non-trivial.

Recovery: reinstalled 5.22, gateway came back. State preserved.

A peer machine with a SIMPLER config (only 1 telegram persona, fewer plugins) downgraded successfully without hitting Bug 2 — suggesting the forward-incompat field is in one of the additional channels/agents/plugins my busier config carries.

Asks

1. Identify which native hook ID is being requested but missing in v2026.5.22. Likely a plugin registered a hook differently in v5.22 vs v5.20.

2. Document or implement a migration path for the forward-incompat config schema change so users can downgrade after hitting a regression.

3. Suggested API: openclaw config downgrade --to <version> that strips/migrates fields that won't validate against the older binary.

Related

• #86019 (compaction issue — still OPEN, awaiting maintainer decision)
• This is a separate regression introduced in 5.22.

cc maintainers — happy to provide more log excerpts, config snippets, or live repro if useful.