频道 pairing CLI 和 account scope 应该怎么一起看

官方最近把 openclaw pairing 这组命令写得更完整了，尤其把多账号场景和通知行为补清楚之后，中文团队更容易避免一个常见误区：

• 以为 pairing 只是一条 approve 命令

实际上，这组 CLI 现在已经是一套正式的聊天入口授权面。

先记住这组命令在管什么

openclaw pairing 管的是：

• 未知 sender 的待审批请求
• 某个 code 是否被批准
• 某个渠道或某个账号的 pending 队列

它不直接替代 allowFrom，而是和 allowFrom 组成两条并行准入路径。

现在最值得记住的常用动作

根据当前官方文档，更常用的动作已经很清楚：

openclaw pairing list telegram
openclaw pairing approve telegram ABCD1234
openclaw pairing reject telegram ABCD1234
openclaw pairing clear telegram --pending

它们各自对应的是：

• 看当前待审批
• 批准某个 code
• 拒绝某个 code
• 清理当前待处理队列

这说明 pairing 已经不是“偶尔第一次接入才用一次”的边缘命令，而是长期运维里会反复碰到的入口治理动作。

--account 为什么越来越重要

当前官方文档已经把 account scope 明确补出来了。

这意味着在多账号渠道里，你看到的 pairing 队列和你实际批准的对象，可能都属于：

• 某个具体账号实例

更准确地说：

• 不带 --account 时，你看到的是默认账号上下文
• 带 --account <id> 时，你操作的是指定账号的 pairing 队列

如果你接了多个 Telegram bot、多个 WhatsApp 号码，或者多个同类渠道账号，这点非常关键。

allowFrom 文件为什么也要一起看

站里已经有文档提到过，官方现在明确了 ~/.openclaw/credentials/ 下的 scoped 文件名规则：

• 默认账号：<channel>-allowFrom.json
• 非默认账号：<channel>-<accountId>-allowFrom.json

这意味着更稳的心智应该是：

• pairing pending 队列按账号看
• allowFrom 文件也按账号落

如果你只盯着默认 allowFrom 文件，就很容易误判：

• 为什么这个 sender 明明在白名单里，却还是进了 pending
• 或者为什么批准了，却还是没落到预期账号

--notify 在运维上解决什么

官方文档现在还把 --notify 写进了 approve / reject 这类命令。

它的意义不是多一个可选参数，而是：

• 让管理员可以决定是否给对端发回明确结果

这在两个场景里很值：

• 你希望批准后对方立刻知道可以重新发消息
• 你不希望拒绝行为在某些入口里造成额外噪音

它让 pairing 审批更像一个真正的操作面，而不是只能静默改状态。

clear --pending 更适合什么时候用

很多人看到 clear 会担心太重，但当前官方语义其实更接近：

• 清理当前挂着的待审批请求

它更适合这些情况：

• 测试阶段积累了很多失效 pairing code
• 某个渠道被短时间刷了很多无效请求
• 你已经决定切到 allowFrom，不再继续人工批准这批 sender

它不是日常主命令，但很适合做整队列清理。

中文环境里最容易踩的坑

1. 多账号环境里忘了带 --account

这会让你以为自己在处理某个 bot 的 pairing，实际却改到了默认账号。

2. 把 allowFrom 和 pairing pending 当成同一份状态

它们相关，但不是同一件事。

3. 只会 approve，不会看 list 和 clear

长期运行里，pairing 队列本身也需要治理。

一条更稳的管理员顺序

建议按这个顺序处理：

1. 先确定是哪个渠道、哪个账号
2. 用 list 看当前 pending
3. 再决定 approve / reject
4. 必要时清理失效 pending
5. 最后回到对应账号的 allowFrom 状态核对

下一步推荐

• 配对审批与设备授权管理
• shared inbox 的运营边界和信任模型
• Session 与配对机制