鼎享会 | OpenClaw WS 首次配对失败避坑实录

```json{  "type": "pairing",  "value": {    "message": "Device pairing required",    "requestId": "<REQUEST_ID>",    "deviceId": "<DEVICE_ID>",    "approveCommand": "openclaw devices approve <REQUEST_ID>"  }}```

则 ~/.openclaw/devices/pending.json 中原本等待授权的请求会被替换成新的 pending 记录，导致原来的 WebSocket 配对流程失效。

1. 清理设备授权状态，确保当前设备尚未完成配对。

2. 通过 WebSocket 首次连接 OpenClaw。

3. 收到 Device pairing required，记录返回的 requestId 和 approveCommand。

4. 在不执行授权命令的前提下，执行：

```bashopenclaw gateway status --json```

5. 再次查看~/.openclaw/devices/pending.json。

6. 会发现 pending 中的记录发生变化，原本 WS 连接对应的授权请求被新的请求替换。

7. 此时再执行最初返回的 approveCommand，通常无法让最初那条 WebSocket 连接继续完成授权。

– WebSocket 客户端发起连接时使用的客户端标识是：

   · clientId = webchat-ui

   · clientMode = ui

– 但在问题发生后，pending.json 中出现的新记录往往是：

   · clientId = cli

   · clientMode = probe

这说明替换原 pending 请求的，并不是原始 WebSocket 连接本身，而更像是一次 CLI 层的状态探测行为。

首次设备授权流程不稳定。

– 用户在看到授权提示后，如果系统内部或手动又执行了 openclaw gateway status，可能会导致当前授权流程失效。

– 前端看起来会表现为“明明已经拿到授权命令，但执行后当前 WS 连接仍然无法建立”。

从现象上看，openclaw gateway status 不只是只读状态检查，它在未授权场景下可能会触发新的设备探测或新的配对请求。

如果网关内部只保留一个 pending 配对请求，或者新的 probe 请求会覆盖旧请求，就会出现：

1. WS 首次连接生成一个待授权请求。

2. gateway status 再生成一个新的待授权请求。

3. 新请求覆盖旧请求。

4. 原来的 approveCommand 失效。

如果 OpenClaw 的预期是 gateway status 只做状态检查，那么这个行为更像是一个 bug，或者至少是一个不符合直觉的设计问题。

当前本地项目里存在一个后台状态轮询，会每 2 秒执行一次状态查询：

```bashopenclaw gateway status --json```

因此在首次授权尚未完成时，这个轮询会持续触发，从而明显放大上述问题。

– 在首次设备授权成功之前，不要执行 openclaw gateway status。

– 如果应用内部存在状态轮询，建议在未配对完成前暂停轮询。

– 完成设备授权后，再恢复状态查询或其他探测逻辑。

这个问题本质是 OpenClaw 在“首次设备授权”与“gateway 状态探测”之间存在冲突：

– WS 首次连接会创建待授权请求

– gateway status 也可能创建新的待授权请求

– 新请求会替换原请求

– 最终导致首次 WS 授权流程被打断

对我们正在做的 DingOS 生态扩展、本地研发提效场景来说，这个小坑会直接影响接入稳定性，短期通过调整轮询策略、增加状态判断可快速规避；长期需推动 OpenClaw 底层逻辑优化，并结合鼎道业务特性重构设备授权与状态查询的交互流程。后续我们会基于这份复现步骤和现象，向 OpenClaw 官方反馈，也会在自己的工程里做更健壮的状态保护逻辑，把首次接入体验做稳。