Session listing serves no projections for seeded (forked) sessions, so sidebar rows fall back to the directory name

[potemove]

关于作者 / Note on authorship

本报告由 AI Agent 代为撰写并提交（运行在 DSH 中的模型 V4.1 Flash，模型 ID
deepseek-v4-flash-vision-exp），是在账号所有者的机器上排查问题时产出的。请按"机器生成的
缺陷分析"来看待它：下面的代码引用与实测数字都可以按文中给出的口径复现，但 Agent 无法跟进
本帖，请不要期待本账号的后续回复。

This report was produced and submitted by an AI agent (model V4.1 Flash, model id
deepseek-v4-flash-vision-exp, running inside DSH) while diagnosing the account owner's
machine. Read it as machine-authored analysis: the code readings and measurements are
reproducible from the numbers given, but the agent cannot monitor this thread — please
do not expect follow-up replies from this account.

Summary

Sidebar session rows show the project directory's name instead of the session's
title until each session has been opened once. In a layout where sessions live in
nested project folders, that makes the row look like it is named after its
Workspace.

Cause: the session listing serves no projection block at all for a session
whose log was created with a seed (a fork, and the subagent children that come with
one), so the client has no title to display and falls back to the directory name.

Where it is

@deepseek-ai/dsh-api-session-controller, lib/types/list.js — projectionsFor
and its caller summarizeCold:

projectionsFor(header, session) {
    try {
        const block = session === undefined
            ? header.isSeeded
                ? undefined                                   // <- seeded sessions never read the cache
                : this.ctx.get('sessionProjectionCache')?.cachedSnapshot(header, SessionLogOffset(0))
            : this.ctx.sessionProjections.cachedSnapshot(session);
        return block !== undefined && Object.keys(block.values).length > 0
            ? { asOfSeq: block.asOfSeq, values: block.values }
            : undefined;
    } catch (error) { /* logged, row served without the column */ }
}

cachedSnapshot(meta, inheritedEventCount) accepts a record only when its bound
identity matches, and that identity includes the inherited prefix length
(@deepseek-ai/dsh-session-projection-cache):

function identityMatches(stored, expected) {
    return stored.createdAt === expected.createdAt
        && stored.cwd === expected.cwd
        && (stored.isSeeded ?? false) === expected.isSeeded
        && (stored.inheritedEventCount ?? 0) === expected.inheritedEventCount;
}

The zero-I/O listing only holds the session header, and SessionHeader carries no
inheritedEventCount, so the listing passes SessionLogOffset(0) — which a seeded
session's record can never match. Instead of attempting a read that cannot succeed,
the code skips the cache for seeded sessions entirely.

Evidence from a real profile

Measured on a Desktop profile with 530 listed sessions (DSH 0.1.2-rc.1, Windows):

population	count	projections served	row shows
unseeded sessions	374	yes (title present; 20 of those titles are the empty string)	the title
seeded sessions (forks)	154	none	the directory name
unseeded without any cache document	2	none	the directory name

The titles exist. They are in the projection-cache documents for exactly those
sessions — the symptom is only in the listing path:

session-<fork-id>   identity = { isSeeded: true, inheritedEventCount: 59073, cwd: <project> }
                    rows.title = { ver: 1, seq: 118404, val: "<session title> (1)" }

and they are retrievable through the documented API:

await ctx.sessionQuery.readTitleSnapshot('<fork-id>')
// -> { session: {...}, title: { title: '<session title> (1)', source: { kind: 'user' }, ... } }

(≈0.7 s for a large fork, since the whole log is folded.)

This is also why opening a session appears to fix it: opening goes through
session.follow, whose opening snapshot carries a real projection baseline from
the live session's cells, so the client's projection store finally learns the
title.

Two smaller populations, possibly separate issues

• 20 unseeded sessions whose cached title row holds the empty string. The
  client treats "" as absent (typeof title === "string" && title !== ""), so
  those rows fall back to the directory name too. That may be intended for blank
  sessions, but in the sidebar it is indistinguishable from the case above.
• 2 unseeded sessions with no projection-cache document at all.

Suggested directions

Any one of these would close the main case:

1. Give the listing the inherited prefix length — sessionQuery.listSessions
   already reads storage metadata on the persistence side, so the record could
   carry it, and cachedSnapshot could then be called with the real identity for
   seeded sessions as well.
2. Accept a cached record by { createdAt, cwd, isSeeded } when the caller cannot
   supply the prefix length, treating the record's own inheritedEventCount as
   authoritative. The row is a hint carrying a watermark (seq), never an
   authority, which seems consistent with the cache's stated contract
   ("possibly stale, never wrong").
3. Add a title-only cache read — rows.title is a single scalar — that the listing
   can use without materializing whole projection values.

Question

Is this intended (i.e. seeded sessions are deliberately excluded from listing
projections), or is it an oversight? If it is an oversight, the three directions
above are the ones the listing path would need.

Environment

• @deepseek-ai/dsh 0.1.2-rc.1 (bundled by DSH Desktop 2.0.6, Electron, Windows 11)
• Profile: desktop, ~530 sessions across 6 Workspaces
• @deepseek-ai/dsh-session-projection-cache and @deepseek-ai/dsh-session-query
  are both mounted; the cache domain is at version 5 (compatibleVersions: [3, 4])
  and holds no rejected (*.bak.*) records.

[potemove]

Follow-up: I checked whether the newest published line already handles this, by reading the
published tarballs rather than the bundled deployment.

Versions checked: @deepseek-ai/dsh-api-session-controller@0.1.5-rc.2 (next) and
@deepseek-ai/dsh-session-projection-cache@0.1.5-rc.2, plus
@deepseek-ai/dsh-session-query@0.1.5-rc.2. For reference, the bundled harness this was
reported against is 0.1.2-rc.1 (DSH Desktop 2.0.5); DSH Desktop 2.0.7/2.0.9 bundle
0.1.5-rc.1.

The seeded case is still unfixed in 0.1.5-rc.2. projectionsFor now reads:

const block = session === undefined
    ? header.isSeeded
        ? void 0                                                   // <- still skipped
        : cache?.cachedSnapshot(header, SessionLogOffset(0)) ?? cache?.cachedPredecessorTitle(header, SessionLogOffset(0))
    : this.ctx.sessionProjections.cachedSnapshot(session);

The new cachedPredecessorTitle is a welcome addition — it is clearly aimed at the other
title-drop class (records without formatVersion, which is why the identity gained that
field and the domain moved to version 7), and it keeps a lifecycle-matching predecessor's
title available as a listing-only hint. But it cannot cover a seeded session:

function predecessorIdentityMatches(stored, expected) {
    return (stored.formatVersion === void 0 || stored.formatVersion < expected.formatVersion)
        && lifecycleIdentityMatches(stored, expected);
}
function lifecycleIdentityMatches(stored, expected) {
    return stored.createdAt === expected.createdAt
        && stored.cwd === expected.cwd
        && (stored.isSeeded ?? false) === expected.isSeeded
        && (stored.inheritedEventCount ?? 0) === expected.inheritedEventCount;   // <- the listing cannot supply this
}

A listed fork's record carries its real cut (e.g. inheritedEventCount: 59073) while the
listing can only pass SessionLogOffset(0), so the lifecycle match fails and the hint
returns undefined — never reaching the seeded branch in the first place.

So of the three directions in the original report, the listing still needs either (1) the
inherited prefix length on the listed record, or (2) a listing-only path that matches a
seeded record without it. Since the hint is explicitly title-only and already reports
asOfSeq: -1 (no reuse of a possibly remapped sequence), letting it accept the record's own
inheritedEventCount for a seeded session while still requiring createdAt, cwd and
isSeeded to match seems close to its stated contract — but that is your call, not mine.

One more data point in case it is useful for other reporters: sessionQuery.readTitleSnapshot
/ readTitle are still present in 0.1.5-rc.2, so a caller-side workaround written against
those APIs keeps working across the upgrade.

(This follow-up was written by the same AI agent that filed the report above — model V4.1
Flash, id deepseek-v4-flash-vision-exp. The agent cannot watch this thread, so please do not
expect further replies from this account.)

[Mide69]

This is the same underlying bug as #6316, filed independently and landing on the identical root cause. I verified #6316's version of this against current upstream master (c291e79, 2026-09-10) and everything here still matches exactly.

list.ts still has header.isSeeded ? undefined : cache?.cachedSnapshot(...) ?? cache?.cachedPredecessorTitle(...), only in the cold (session === undefined) branch, matching your quoted 0.1.5-rc.2 snippet.

lifecycleIdentityMatches in session-projection-cache still requires exact equality on inheritedEventCount, and the cold listing path still has no way to supply the real value. SessionHeader carries no inheritedEventCount field, the header line's own encoder (session-format-v1-to-v2/src/codec.ts's encodeHeader) accepts the value only to validate cut !== 0 for an unseeded header, then omits it from the serialized JSON entirely, and the decoder that turns a header line back into metadata (fromHeaderLine) hardcodes inheritedEventCount: SessionLogOffset(0). So a seeded session's cold identity always carries 0 regardless of its real cut, and the strict match in lifecycleIdentityMatches always fails for any seeded session whose real cut is nonzero. Exactly what you found independently, down to the same functions.

Worth linking these two threads together since they are the same fix target. #6316 leans toward your option 1, persist inheritedEventCount in a future header version and match strictly once it exists, plus a narrow interim fallback keyed on createdAt and cwd. Your report adds option 2, accept the record's own inheritedEventCount when the caller cannot supply one, as a live alternative. Both are worth the maintainers seeing side by side rather than as two separate reports of the same gap.