OpenClaw配置实战第十八篇:Claude Code 独立排障

凌晨一点多，我把一个坏掉的 Dashboard 交给 Claude Code，然后去泡了一杯茶。回来的时候，它修好了。

一、破局的信号

5/7 的 skill 装完，Gateway 重启，一切正常。最后一步：打开 Dashboard 验证。

浏览器显示：

device identity required

不是密码错了，不是网络断了。是 Dashboard 认为「这台浏览器不是被授权的设备」，拒绝入场。

这不是第一次见类似问题。2/26 排查双 plist 僵尸进程时遇到过 pairing required，那一次靠核弹级重置解决。但这次不同——这次的根因更隐蔽，也恰好是 Claude Code 可以独立处理的那类问题。

二、根因分析：旧 deviceId 的幽灵

事情要从一个月前说起。

2/25 排查公网访问时，我曾执行过 openclaw devices clear --yes，清掉了服务端的配对记录。但浏览器端不知道这件事——它的 localStorage 里还存着 2/25 创建的旧 deviceId 和 Token。

每次打开 Dashboard，浏览器用旧 deviceId 向 Gateway 发起身份验证，Gateway 查不到这个 ID（已被清除），于是报 device identity required。

dangerouslyDisableDeviceAuth: true 对这种情况无效。这个开关只对「完全没有 deviceId 的新连接」生效——持有失效 Token 的连接，会被识别为「身份存在但已失效」，照样被拒。

换句话说：问题在浏览器，不在 Gateway。但我无法直接修改浏览器的 localStorage——除非知道 Gateway 的数据结构，能伪造一个合法的 deviceId 注入进去。

这正是 Claude Code 擅长的事。

三、Claude Code 的独立排障过程

我给了 Claude Code 三样东西：

症状：Dashboard 报 device identity required，即使 dangerouslyDisableDeviceAuth: true
期望结果：能正常打开 Dashboard 并发消息给洵儿
约束：不能清掉所有设备（企微通路的配对不能动）

然后放手。

Claude Code 独立完成了以下步骤，全程约 20 分钟，无需我逐步指导：

步骤一：从 OpenClaw 源码里找到 paired.json 的数据结构（~/.openclaw/devices/paired.json），确认 deviceId 的格式和必要字段。

步骤二：在浏览器 Console 里找到旧的 deviceId（localStorage.getItem('deviceId')），然后手动把这个 deviceId 注入到 paired.json，赋予 operator 角色。

步骤三：重启 Gateway，让新的 paired.json 生效。

步骤四：执行 openclaw devices rotate，为新 deviceId 生成 Token。

步骤五：openclaw dashboard --no-open，获取带 Token 的 URL，用浏览器直接访问。

Dashboard 打开，洵儿回复了。

铁律（新增）：以后不要用 openclaw devices clear——这个命令会清掉所有配对，包括浏览器的。正确做法是 openclaw devices remove <id>，只删需要清理的设备，保留浏览器设备。

四、从「人工指挥每一步」到「下达目标，自主执行」

这次排障的意义，不在于 Dashboard 修好了。

在于工作模式变了。

之前和洵儿协作的模式是：我描述问题 → 洵儿给方案 → 我判断 → 我执行 → 报错 → 我描述新问题 → 循环。

Claude Code 的模式是：我描述目标 + 约束 → 它自行读文档、翻源码、执行命令、验证结果 → 报告完成。

这不是「又多了一个 Claude 入口」。这是从遥控器变成了副驾。前者需要我持续介入，后者需要我清晰描述目标然后放手。

五、overnight 模式：临睡前下单，醒来看结果

Dashboard 修好之后，凌晨两点，还有两件事没做：

公网访问修复：Cloudflare Access 邮件验证码发不到邮箱，外网用户（比如公司电脑）无法进 Dashboard
文件读写能力调研：洵儿有没有类似 Claude.ai 的文件上传 + artifact 输出能力

这两件事调查起来都不快。凌晨两点自己做，效率不高。

于是把任务交给 Claude Code，配置 overnight 无人值守模式：

tmux new -d -s overnight 'claude --dangerously-skip-permissions -p "任务一：排查并修复公网访问问题（Cloudflare Access 邮件不到达）任务二：调研 OpenClaw 文件读写能力结果输出到 ~/.openclaw/workspace/overnight-report.md"'

--dangerously-skip-permissions：跳过所有权限确认，全自动执行。适用于在已授权范围内的无人值守任务。

关机睡觉。早上看报告。

踩坑与反模式

dangerouslyDisableDeviceAuth 对持有失效 Token 的连接无效：这个开关是为「全新无身份连接」设计的。如果浏览器带着旧 deviceId 进来，Gateway 会识别出「身份存在但已失效」，照样拒绝。这两种情况表现相似，根因完全不同
openclaw devices clear 会清掉浏览器配对：如果浏览器之前完成过配对，执行这个命令后会失效。下次只用 openclaw devices remove <特定id> 精准删除
overnight 任务不适合有副作用的操作：--dangerously-skip-permissions 跳过所有确认，如果任务描述模糊，Claude Code 可能执行一些你没预期的文件修改。overnight 任务的权限范围必须在 ~/.claude/settings.json 里提前限定
提示词模板很关键：好的 overnight 提示词结构是「描述现象 → 期望结果 → 已知约束 → 请自查文档/源码/日志」。不要在提示词里写「你觉得应该怎么做」——这会让 Claude Code 花时间分析，而不是直接动手

可复用 Checklist

[ ] 遇到 device identity required，先查浏览器 Console：localStorage.getItem('deviceId') 是否有值
[ ] 如有旧 deviceId：手动注入 ~/.openclaw/devices/paired.json → 重启 Gateway → openclaw devices rotate
[ ] 今后不用 openclaw devices clear，改用 openclaw devices remove <id>
[ ] overnight 模式配置：tmux new -d -s overnight 'claude --dangerously-skip-permissions -p "..."'
[ ] overnight 任务前，确认 ~/.claude/settings.json 的 permissions.allow 范围合理
[ ] overnight 完成后，先看日志确认没有意外操作，再信任结果

下一步：P7 大门已在眼前

3/11 凌晨的这份进度总结：

P0–P6 全部完成
P6.5 熔断验证通过
Skill 5/7 到位
Claude Code 可用
24h 连续存活达成
基础设施完成度：90%

进入 P7 的最小可行条件，只剩一件事：晚报 Cron——让洵儿每天定时主动执行一个完整的信息采集 → 分析 → 输出流程。这是从「被召唤者」变成「主动作业者」的发条。

但在启动晚报 Cron 之前，更重要的是一件事：需求发现。识别 3–5 个真实的日常场景，而不是先造功能再找场景。

作者：喜感星球 × 洵儿｜ 2026.03