openclaw - 💡(How to fix) Fix [Bug]: unknown requestId during device.pair.approve

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Version: 2026.5.12 (and persists from 2026.5.7) Environment: Linux 6.8.0-111-generic (x64) / Node 24.15.0 (Proxmox VM) Severity: Critical (Blocks new device pairing)

Description: The openclaw devices approve <deviceId> command fails consistently with an unknown requestId error. This is an isolated failure; other WebSocket-based commands (such as openclaw devices list and openclaw gateway health) work perfectly, confirming that the WebSocket connection and general request/response loop are functional.

Steps to reproduce

Steps to Reproduce:

Pair a new device to the gateway (device remains in "pending" state).
Run openclaw devices list to confirm the device is present.
Run openclaw devices approve <deviceId>.
Observe the immediate failure: [openclaw] Reason: unknown requestId.

Expected behavior

Expected Behavior: The Gateway should process the approval and return a success response linked to the original requestId.

Actual behavior

Actual Behavior: The Gateway returns a response that the CLI cannot associate with any active request, or the Gateway fails to include the requestId in its response payload for this specific method.

OpenClaw version

2026.5.12 (and persists from 2026.5.7)

Operating system

Ubuntu 22.04

Install method

npm global

Model

Gemma4:31b

Provider / routing chain

ollama(web)

Additional provider/model setup details

Default is Gemma4:31b - this behave happens after full gateway reset, upgrading as mentioned, and debugging with AI support with full debug\diag logging enabled. No resolution, previously approved devices - some work, some don't.

Logs, screenshots, and evidence

Technical Evidence:

    Gateway Logs: Show the request being received, but the response timing is nearly instantaneous (approx. 4ms), suggesting an immediate failure or a malformed response header.
    CLI Trace: The failure occurs in the ws receiver loop (Receiver.startLoop $\rightarrow$ Receiver._write), indicating the CLI is receiving a message it cannot route back to the caller.
    Isolated to Method: device.pair.approve fails while device.pair.list succeeds.

Impact and severity

No response

Additional information

Suggested Root Cause: There is likely a regression in the device.pair.approve handler where the requestId is either stripped from the response or a internal exception is being caught and returned as a generic failure that doesn't adhere to the expected request/response schema.