[Bug Report] Seeded / forked sessions fallback to workspace name after restart (cached title skipped during cold listing)

[Oct1AtJoe]

Summary

After restarting DSH, forked/seeded sessions (isSeeded: true) show the workspace directory name as their title in the session list. Opening the conversation hydrates the full log and restores the real title, but restarting reproduces the issue.

Root Cause

1. Cold listing skips cache: In packages/api/session-controller/src/list.ts, projectionsFor(header, undefined) explicitly bypassed sessionProjectionCache for seeded sessions (header.isSeeded ? undefined : ...).
2. Log size limit: Most session logs exceed the 1KB cold probe threshold (probeSmallCold), so they cannot be inspected on startup without opening the session.
3. Fallback triggered: SessionSummary.projections is left undefined, causing displayTitleOf(title, cwd, id) to fall back to workspaceTitleOf(cwd).
4. Cache lookup limitation: In packages/session/session-projection-cache/src/index.ts, cachedSnapshot and cachedPredecessorTitle strictly required inheritedEventCount. However, SessionHeader during cold listing only carries version, id, createdAt, cwd, and isSeeded — not inheritedEventCount.

Proposed Fix

We have prepared and verified a clean fix with tests passing (508 tests in affected packages):

1. Allow optional inheritedEventCount: In packages/session/session-projection-cache/src/index.ts, make inheritedEventCount optional in cachedSnapshot and cachedPredecessorTitle. When omitted during cold listing, identityMatches matches by createdAt, cwd, and isSeeded.
2. Enable cold cache lookup: In packages/api/session-controller/src/list.ts, query sessionProjectionCache for cold sessions without skipping isSeeded.
3. Tests updated: Updated session-cold.host.spec.ts and cache.spec.ts to cover seeded cold listing and cache retrieval.

References

Since external Pull Requests are disabled on this repository, the patch is available in the fork below:

• Fork Branch: Oct1AtJoe/deepseek-harness:fix/seeded-session-cold-title
• Commit: 2f1e15f

[argszero]

Thanks for the source-level write-up and the fork patch — I verified your mechanism claims against master d347e70390 and they're accurate. Before that, a family note: this is a repeat of #5843 (xmzhu13, same release window, same root) — "冷态 seeded 会话重启后丢失全部列表投影" — where I traced the exact short-circuit (api/session-controller/src/list.ts:274-279 skips the cache before any read for header.isSeeded cold sessions). Your thread adds the valuable new piece: a working patch with tests, which #5843 lacked.

Your fix direction, however, runs into the one design fact I flagged in #5843, and I want to lay it out precisely so the tradeoff is visible to maintainers:

The exact-match identity is a deliberate anti-cross-wire invariant, not an implementation detail.

• session-projection-cache/src/index.ts recordFor docblock: "A session id names a slot, not a lifecycle: a recreated id or a persistence store swapped under a surviving cache must not let an old record seed state folded from an unrelated log."
• identityOf throws when an unseeded caller passes a non-zero cut — the count is part of what makes a cache row about the same log as the caller.
• cachedSnapshot docblock: "never from an unrelated log (the caller's header is the identity witness)."

Your change makes inheritedEventCount optional and, when omitted, matches on createdAt/cwd/isSeeded only. Within one session-id slot, the residual ambiguity is exactly the case the invariant names: the same id + createdAt re-seeded with a different inherited cut (log rewrite / truncate-and-refork — the #1703/#2143 family). With your relaxation, a cold list can serve a checkpoint written against the old cut.

Why that's bounded (and why your patch is probably still acceptable for the listing path):

• The relaxed call site is the cold listing path only — its output is display hints ("as stale as the last durable checkpoint but never wrong" per the docblock), and opening the session supersedes them via the history-tail baseline. Severity of a stale title until open: cosmetic.
• The dangerous paths (hydration cachedSnapshot(session) at index.ts:218/259) still pass the exact count from session.inheritedEventCount — as long as your diff keeps those calls strict (it appears to — the optionality only relaxes the cold SessionLogOffset(0) callers), the cross-wire guard holds where it matters.
• The same relaxed lookup is what #5843 needs anyway — the real blocker there was that the cold header carries no count (deliberately: core/session/src/types.ts:99-102 documents the prefix length as "Session state rather than ordinary header metadata").

What I'd add before this lands as the upstream fix:

1. A regression test for the residual ambiguity: same id slot, record written under cut A, session re-seeded to cut B, cold list must not serve A's values once the caller can know B — and document that cold-list-without-count is a best-effort hint read that may serve the previous cut.
2. Confirm the same fix covers subagent/subagent/src/list-children.ts:312, which has the identical seeded skip pattern.
3. For comparison, the alternative shape from [Bug][0.1.2-rc.1] 冷态 seeded 会话重启后丢失全部列表投影：cachedSnapshot 以 inheritedEventCount = 0 校验身份，弃用有效检查点 #5843: persist the inherited count into the session descriptor (format bump + adjacent migration per this repo's released-session rules) so cold listing can reconstruct the exact identity and read without relaxing the invariant. Heavier, but it keeps "never from an unrelated log" absolute. Your relaxation is the smaller diff; the choice between them is a maintainer call — worth stating both in the discussion.

Given PRs are disabled, your fork commit (Oct1AtJoe/deepseek-harness@2f1e15f, branch fix/seeded-session-cold-title) is the right vehicle — maintainers can pull it from there. This is core-side (session-controller + projection-cache), plugin-adjacent only in that a plugin cannot fix it; archiving as an upstream-fix candidate with your patch as the reference implementation.

[Oct1AtJoe]

Thanks for the detailed review and the design background! That makes total sense.

We have pushed an update to the fork branch fix/seeded-session-cold-title (commit 2e215b9) addressing your feedback:

1. Regression test & docs added:

   • Added the ambiguity regression test to packages/session/session-projection-cache/tests/cache.spec.ts: proving that while cold listing without count serves cut A as a best-effort hint, any caller that knows cut B strictly rejects cut A's checkpoint.
   • Updated docblocks in index.ts and bilingual READMEs documenting that cold header-only lookups are best-effort hint reads that may serve a previous cut if re-seeded in place before opening.

2. Regarding subagent/subagent/src/list-children.ts:312:

   • We inspected list-children.ts against tests/list-children.spec.ts:582 (refuses a cached ancestor identity from the fork seed and lets preparation rule).
   • Unlike ApiSessionList (where an inherited title is a desirable and safe UI display hint), a seeded subagent may replay the ancestor's subagent/descriptor in the prefix (seq < seedLength). Since SessionHeader carries no seedLength, list-children.ts cannot verify whether cached.seq >= seedLength without reading the body.
   • Therefore, list-children.ts must intentionally retain !header.isSeeded and fall through to observeSession to prevent ancestor identity leakage. We left list-children.ts intact.

All tests (509 tests in affected packages) and pre-commit hooks (translation pairing, lint, whitespace) pass cleanly. Maintainers are welcome to pull directly from the branch!

[argszero]

That's a genuinely important correction to my suggestion, and you're right — I owe the nuance: list-children.ts is not the same code path as the session-list display hint, and keeping its seeded skip is the correct call.

The distinction you drew is the load-bearing one: for ApiSessionList, a stale/previous-cut title is a cosmetic UI hint that gets superseded on open; for list-children, the cached row can carry the ancestor's subagent/descriptor in the replayed prefix, and with no seedLength on the header the cache cannot prove cached.seq >= seedLength without reading the body. Serving that row cold would leak ancestor identity across a fork boundary — which is precisely the class of cross-wire the identity gate exists to prevent. So the seeded skip there is a security boundary, not an omission, and the test at list-children.spec.ts:582 ("refuses a cached ancestor identity from the fork seed") is encoding exactly that intent.

That also sharpens the fix's documentation story: the honest statement isn't "same fix covers both call sites" but "the display-hint path may relax under documented best-effort semantics; the descriptor path must not, because the cost of a wrong read is identity leakage rather than a stale title." Your docblock updates plus the ambiguity regression test (cold-without-count serves cut A; a caller that knows cut B strictly rejects it) give maintainers both the boundary and the proof.

509 tests + pre-commit hooks clean is a solid landing state. This is now the reference implementation for the family — maintainers can pull fix/seeded-session-cold-title directly.

[alanzhao0128]

{"body": "Confirming this from another user: I hit exactly this on 0.1.2-rc.1 — after every restart, my long-lived compacted sessions show the workspace folder name and a stale "22d" timestamp in the session list until I open them. Opening restores title and time, but it comes back after the next restart. The thumbs-up on this report is mine — happy to test a fix build if useful."}

[argszero]

Thanks for confirming with the concrete repro — the "long-lived compacted sessions" detail is worth a beat, because it may be a second variant of the same family rather than the same instance. The thread so far (Oct1AtJoe's fork fix at 2e215b9 on fix/seeded-session-cold-title, discussed above) targets the seeded/forked cold-title case: projectionsFor short-circuits on header.isSeeded before the identity check, so a cold restart serves the fallback title.

Compacted sessions are a distinct flag — if your affected sessions are not seeded forks, the trigger is likely the same cold-list projection staleness but reached through compaction (higher inheritedEventCount making the cached snapshot fail its identity check on restart). That would make it a sibling report, not a duplicate of the seeded case. Two ways to tell:

1. In the session list/history, does the affected session show as a fork/derived session, or a plain top-level one you compacted?
2. If you have both kinds, does a plain compacted-but-never-forked session also show the workspace-name fallback after restart?

If it reproduces on plain compacted sessions too, that's a separate repro worth its own note here (the fix for the seeded path may not cover it — different short-circuit). Either way, if any of your sessions are seeded forks, Oct1AtJoe's branch is testable today and would appreciate a second tester.