bug(session): a session id recorded on spawn poisons every later resume when the CLI never created the conversation

[smileygames]

目的

起動が会話を作る前に終わると、そのトピックに死んだセッション id が残る。以後そのアカウントをそのトピックで起動するたびに再開が走り、No conversation found with session ID で失敗する。復帰経路が無い——再開コマンドを消すか、トピックを消すまで直らない。

観測

2026-08-29 00:41 に Claude Lay を起動、00:42 に再度起動して次が出た。

No conversation found with session ID: eb9ea0a9-938b-42be-a887-c2735a7137ab

状態行は「Claude Lay を再開しました。」であり、再開の線に入っている。

再開コマンドを消すと同じ操作でエラーが出なくなる（Master が実測）。resolve_launch の再開分岐が両方揃ったときだけ発火するため、片方を欠いた状態が回避になっている。

今夜の CLI セッションは ~/.claude/projects/C--Users-smile-Claude/ に一つも記録されていない（最新は 8/28 18:58）。id は在るのに会話が無い、という状態が実際に起きている。

前提

いずれも main（542f770）で確認した。

• resolve_launch（src-tauri/src/session.rs:369）は、トピックに記録された id と アカウントの再開コマンドの両方が揃ったときだけ再開の線を選ぶ。片方でも欠ければ通常起動になる。
• 記録は spawn 成功の直後に行われる（同 :596 付近）。コメントはこの順序の理由をこう述べている——「Recorded after the spawn rather than before: an id written for a launch that failed would be resumed into a session that was never started.」
• その守りは掛かる位置が一段早い。 spawn 成功は「プロセスが立った」ことであって「会話ができた」ことではない。Claude Lay の args は --dangerously-load-development-channels server:github-webhook-mcp を含んでおり、CLI は起動直後に確認プロンプト（1. I am using this for local development / 2. Exit）で止まる。ここで終了すると、プロセスは立ったが会話は作られていない。id はもう記録されている。
• 実際 2026-08-28 21:41 の起動はこのプロンプトで止まったまま終了させており（docs(requirements): record the 2026-08-28 real-device verification of the sidebar toggles #123 の実機確認）、その回の id が索引に残っていた。
• 再開が失敗しても通常起動へ落ちる経路は無い。CLI がエラーで終わり、席が死ぬ。(アカウント, トピック) の組が固定的に壊れる。

由来（Master 談）

再開コマンドはもともとスリープ回避策として入れたものである。 PC がスリープから復帰したとき、webview の再読み込みで部屋が空になる経路（#108、#84）に対する手当てとして書かれた。

resolve_launch はその由来を知らない。分岐の条件は「このトピックにこのアカウントの id が記録されているか」と「アカウントが再開の線を持つか」の二つだけであり、どの状況で再開すべきかという軸を持たない。したがって、スリープ復帰のために書かれた線が、アプリの再起動後の起動でもそのまま発火する。

この二つは前提が違う。スリープ復帰では CLI のプロセスが生きている——席の引き取り（#115 決定4C / #84）が繋ぎ直す経路であり、そもそも --resume を要しない場合がある。再起動後はプロセスが無く、--resume が頼るのは会話が保存されていることだけである。上の「会話ができる前に終わった起動」は、まさにその前提が崩れる場合であり、スリープ用に書かれた線が一番効かない状況で発火している。

制約

• 記録の順序を「会話ができてから」へ動かすなら、アプリはその瞬間を知らない。CLI の出力を読むか、transcript の出現を見るか、別の合図が要る。出力を読む形は docs/0-requirements.md「CLI の出力から状態を読む形」で一度見送られている軸なので、そこへ踏み込むかどうかは判断が要る。
• 再開失敗時に通常起動へ落とす形は、失敗を握り潰す側面がある。「戻れなかった」ことが見えなくなると、履歴が繋がっていないまま話が続く。feat(history): split the history into topics, resumable from the list #115 決定4 の二段構え（native resume が無ければ部屋の pull）と揃えるなら、落とした事実を状態行で言う必要がある。
• 死んだ id を捨てる形（再開が No conversation found を返したらその記録を消す）は最小だが、エラー文字列に依存する。CLI の版で文言が変われば黙って効かなくなる。

決定

AI 判断1: 軸2 と軸3 を採る。 再開の線で起動したセッションが席に着かないまま終了したら、そのトピックからその id の記録を外し、状態行でそう言う。次に押したときは通常起動になる。

採る理由:

• 既に在る合図で足りる。 pty.rs:199 が pty-exit-{id} に終了コードを載せて出しており、画面はこれを受けて「〜が終了しました（…）。端末を確認してください。」を既に描いている（src/main.ts:2767）。CLI の出力を読む必要が無いので、制約に挙げた文字列依存を負わない。docs/0-requirements.md「CLI の出力から状態を読む形」で見送られた軸にも踏み込まない。
• 軸1 の壁を回避する。 「会話ができた瞬間」をアプリは知らないままでよい。知る必要があるのは「戻れなかった」ことだけであり、それは終了として観測できる。
• 握り潰さない。 失敗は状態行で述べる。feat(history): split the history into topics, resumable from the list #115 決定4 の二段構えと揃う。

AI 判断2: 自動で起動し直さない。 記録を外して終わり、次の操作は人が決める。自動再試行は失敗の繰り返しをこちらで回す形になり、model-loop-safety の避ける形に当たる。一度押し直せば通常起動で立つ。

軸4 は見送り、この issue では扱わない。 再開の線に適用範囲を持たせる形は設定の概念を増やす変更であり、今回の復帰とは別の判断である。由来（スリープ回避）から見て検討に値するので、別 issue で扱う。

判別条件（席に着かないまま終了した、の literal）は実装側で決めてよい。LaunchLine.resumed が再開かどうかを持ち、seats.hold が着席の位置である。CLI のエラー文言との一致を条件に使わないことが制約である。

想定される軸（判断の材料。採否は上記）

1. 記録を遅らせる — 会話ができたと分かってから id を書く。根治だが、その瞬間を知る手段が要る。
2. 再開失敗を検知して落とす — 通常起動へフォールバックし、状態行で「戻れなかった」と言う。復帰はするが、検知が文字列依存になりうる。
3. 死んだ id を掃除する — 失敗した時点でトピックからその記録を外す。次回は通常起動になる。2 と組み合わせられる。
4. 再開の線に適用範囲を持たせる — どの状況のための線かをアカウント側が言えるようにする。由来（スリープ回避）に照らすと、そもそも再起動後の起動で発火させない選択がありうる。

target files

• src-tauri/src/session.rs
• src-tauri/src/room_log.rs
• docs/0-requirements.md

関連

• feat(history): split the history into topics, resumable from the list #115 決定3 / 決定4 / 決定4B / 決定4C（二つの線と二段構えの復帰）
• bug(topics): a session started without a post leaves an untitled row that cannot be deleted #125（同じ record_session が題の無い行を作る側面。こちらは行の見せ方と消し方で、id の生死は別軸）
• docs(requirements): record the 2026-08-28 real-device verification of the sidebar toggles #123（この id を作った実機確認）