(restore): a backgrounded session is restored from its pre-fork transcript #518

Activity

1. devsuitup

   added

   bugSomething isn't workingSomething isn't working

   on Oct 9, 2026
2. devsuitup commented on Oct 9, 2026

   

   devsuitup

   on Oct 9, 2026

   OwnerAuthor

   More actions

   Diagnosis (read-only, code at origin/main):

   • The CLI's signal. Backgrounding appends {"type":"continued-in","sessionId":<old>,"continuedInSessionId":<new>} to the old transcript (7615734f, line 42050, 2026-10-05T19:21:12Z, right after "Backgrounding after the current tool finishes…"). A second one points to c1329340 (2026-10-08T20:23Z), so one id can have several continuations. The new transcript carries no back-link (sessionKind:"bg", no forkedFrom). The live link is the CLI descriptor ~/.claude/sessions/<pid>.json, whose sessionId changes (measured after an in-CLI /resume: pid 9368 now reads e7abbcdc).
   • Why no re-key. The only re-key path is session-transitions.js detectSessionTransitions (~330-430): a new jsonl is re-keyed only when forkedFrom matches (:395), otherwise "NO MATCH" (:409). A bg continuation has no forkedFrom, and /resume creates no file, so session-forked is never sent and the tab stays keyed on the launch id. The PTY itself stayed alive for four days (OSC 9 from 7615734f in main.log), so persistWorkingSet (public/app.js:175-200) kept writing 7615734f, and the trigger watcher logged "Session not found: e7abbcdc" on 06, 08 and 09/10. guardResume only checks whether the saved id is live elsewhere, which it was not.
   • Same class as /clear ((sessions): follow /clear to the new transcript instead of listing it apart #477), in-CLI /resume, and backgrounding: the PTY's conversation id changes while the PTY lives.

   Plan:

   • B (now, separate PR): at restore, follow the saved id's continued-in chain main-side; one continuation → resume it and fix the saved entry; several → ask, never resume silently; a live bg continuation → attach. Red-first.
   • A (after (sessions): follow /clear to the new transcript instead of listing it apart #477): re-key live from the descriptor in cli-session-state.js (already watched, 150 ms flush) for PTYs Switchboard spawned, reusing (sessions): follow /clear to the new transcript instead of listing it apart #477's clearOwner ownership walk and rekeyed map rather than a parallel path. Needs a measurement first: on Windows (pidDomain:"win32:anchor") the descriptor pid may not descend from the node-pty pid.
3. devsuitup

   added 2 commits that reference this issue on Oct 9, 2026

   test(restore): pin that restore follows a session's continued-in reco…

   ...

   30f1410

   fix(restore): follow a session's continuation instead of resuming the…

   ...

   99a6f97
4. devsuitup commented on Oct 9, 2026

   

   devsuitup

   on Oct 9, 2026

   OwnerAuthor

   More actions

   Part B is merged in #520: restore and manual open now follow continued-in.

   • One live continuation opens it and rewrites the saved entry.
   • A target whose transcript was never written is dropped when a sibling exists.
   • Ambiguous or unresolved cases never spawn. Automatic restore holds them in a notice, and a manual open asks, still offering the original.

   Part A (live re-key from the CLI descriptor on /resume / /clear) waits for #477.

   Follow-ups from the last review, not blocking:

   • liveElsewhereChecked ignores scheduledRuns.
   • When liveness is unknown, the notice says "choose" instead of "waiting for indexing".
   • The full read keeps the raw buffer next to the decoded string, so peak memory per read is about the file size; not measured.
5. devsuitup

   added 2 commits that reference this issue on Oct 9, 2026

   (restore): follow a session's continuation instead of resuming the pr…

   ...

   d14b035

   (sidebar): test that a merged web-session row follows its live member

   ...

   1754f04