Web UI does not show existing sessions even though session files and workspace index are intact

[Oscar-fyc]

Bug description

In DeepSeek Harness 0.1.5-rc.1, existing sessions in a workspace are no longer displayed in the Web UI, even though:

• the session files still exist on disk;
• the sessions are correctly registered in workspace.json;
• archivedSessionIds is empty;
• the session contents can still be successfully accessed through a dsh-session: cross-session reference;
• rebuilding session_projcache does not restore them;
• dsh web prints no related error or warning.

This appears to be a Web UI / session-list restoration issue rather than session data corruption.

Environment

Windows 10/11
DeepSeek Harness: 0.1.5-rc.1
Node.js: v24.21.0
Corepack: 0.36.0
Workspace: F:\summer_paper

DSH_HOME is not explicitly set.

Therefore Harness uses:

C:\Users\<username>\.dsh

[PerryLink]

Short version: I went through master (0d1f50007f, v0.1.6-alpha.1) and could not find a commit that specifically fixes "sessions present on disk and in workspace.json but missing from the web session list". The three candidates you'd expect are all in 0.1.6-alpha.1, but each targets something else: 5f773a0ded adds a settings page to restore archived sessions, 11248ea949 retains blank manual positions during reconnect, and 8423b270e3 derives sidebar recency independently of manual order (all verified as ancestors of HEAD; 0.1.5-rc.1 is tagged 2026-09-10 per docs/persistence-changes/releases/dsh-v0.1.5-rc.1.md:32). None of them adds missing sessions back to the list. Trying 0.1.6-alpha.1 is still reasonable — that window reworked the whole sidebar store — but I can't promise it fixes your symptom (not verified).

More useful: the current code has a silent drop that fits every symptom you listed. The sidebar does not read workspace.json sessionIds for existence — /api/session/list → ApiSessionList.list() (packages/api/session-controller/src/list.ts:126-144) → sessionQuery.listSessions() (packages/session-query/session-query/src/corpus.ts:61-80) → sessionPersistence.list(), a directory scan of the storage root (packages/session/session-persistence-jsonl/src/index.ts:461-490, 1504-1526). workspace.json only groups/orders rows (packages/client/ui-workspace/src/client/tree.ts:266-274). Then at list.ts:138:

if (record.header.cwd === undefined) continue

Cold sessions whose header has no cwd are skipped silently (same filter in search at list.ts:181). Such sessions are still stored — under <root>/_no-cwd (session-persistence-jsonl/src/format.ts:254) — and are still reachable by id: dsh-session: references resolve through sessionQuery.readSurface → corpus.load, which has no cwd filter (session-query/src/index.ts:310-318, corpus.ts:91-120). That is exactly your symptom set: files intact, index intact, cross-session references work, no error printed. This filter predates rc.1 (added 2026-08-25, 69fad4b8db0), and list.ts was not touched between rc.1 and HEAD — so it was present in your build. (Whether your headers actually lack cwd I can't verify without the files.)

Checklist, in order: 1) open each session's stored header and check the cwd field; 2) confirm archivedSessionIds really is empty in the registry the gateway uses; 3) confirm origin !== 'subagent' — subagent rows are hidden (tree.ts:203-207, which also hides archived rows and blank rows unless selected); 4) if headers look fine, watch session.list in the browser's devtools — an ok-but-empty response points at the backend scan, an error response points elsewhere.

One observation: your post appears to end mid-paste at "Therefore Harness uses: C:\Users\<username>\.dsh" — the layout tree seems missing. If you can finish that (plus any dsh web logs, and one stored header), I'll happily help pin down which drop is eating your rows.