[Bug] Workspace loses session accounting after a host crash/relaunch (sessions fall into "Ungrouped", no way to re-attach)

[roxorlt]

Environment

• DSH Desktop 0.2.1-rc.2 (Electron), core packages @deepseek-ai/dsh 0.1.5-rc.2
• macOS 26.3 (Apple Silicon), profile: desktop
• Session log format v4 (session.v4.jsonl.zstd)

Summary

After the desktop host process was killed (SIGKILL) and the app relaunched, an existing workspace lost its session accounting. The workspace record in ~/.dsh/storages/workspace.json ended up holding only the newest session id; every earlier session of that workspace fell into the "Ungrouped" group in the sidebar.

The sessions themselves are intact (logs on disk; one of them was still live and was auto-resumed after the relaunch), so this is a registry/bookkeeping bug rather than session-data loss. However the GUI offers no way to re-attach an existing session to a workspace:

• dragging a session row only reorders within the same group (sameGroupDrag = drag.accountKey === group.key in dsh-client-ui-workspace);
• dragging a workspace header only reorders workspaces;
• there is no "move to workspace" / "pin" action in the session menu (only rename / fork / archive);
• the only remotely exposed mutation, workspaces.insertSessionBefore, rejects sessions that are not already accounted for, and Workspace.attachSession is not exposed over the remote API (it is only called by session.create when a workspaceId is passed).

Observed sequence (redacted)

t0  workspace W is created for /path/to/project together with session A
    registry: W.sessionIds = [A]
t1  host process is SIGKILLed while A is running
t2  app relaunched; A is auto-resumed (active goal re-armed).
    a while later a new empty session B is created in W
    registry: W.sessionIds = [B]          <-- A dropped
    (W.createdAt is still t0, W.updatedAt = t2)
t3  another new session C is created in W
    registry: W.sessionIds = [C]          <-- B dropped too

Other long-lived workspaces in the same registry kept their full accounts (dozens of session ids), so this looks specific to the crash/relaunch path rather than to normal session creation.

Evidence (redacted registry excerpt)

"tables": {
  "workspaces": {
    "<workspace-id>": {
      "path": "/path/to/project",
      "title": "project",
      "sessionIds": ["session-<newest-only>"],
      "createdAt": "<timestamp from before the crash>",
      "updatedAt": "<timestamp of the newest session>"
    }
  }
}

Suspected code paths (from reading the installed packages, not a source checkout)

• dsh-workspace → WorkspaceEntity.sessionIds getter filters record.sessionIds with host.sessionPath(id) === record.path. If a stored session's path cannot be resolved yet during a cold start, a subsequent mutation can persist the filtered list and silently drop ids.
• bootstrap(headers) only runs when the registry state has initialized === false (dsh-workspace/lib/index.js, around the if (!this.state.initialized) guard), so a normal relaunch never re-adopts stored sessions by cwd.

Steps to reproduce (best effort)

1. Create a workspace for a directory and start a session there.
2. SIGKILL the desktop host process.
3. Relaunch the app, let it resume the session, then start another session in the same workspace.
4. Inspect ~/.dsh/storages/workspace.json: the workspace's sessionIds has lost the older ids.
5. In the sidebar the older sessions are shown under "Ungrouped"; dragging them onto the workspace group does nothing.

Expected

• Existing sessions should stay attached across restarts; at minimum, startup should reconcile workspace membership by session cwd and never silently drop ids it cannot validate.
• Please expose a way to re-attach an existing session to a workspace (UI action or remote API).

Impact

After a crash, workspace grouping silently disappears for affected sessions and cannot be restored from the GUI. Session content is intact, but to users it looks like the sessions were "lost" from the workspace.

Workaround

Quit the app, edit ~/.dsh/storages/workspace.json, insert the missing session ids back into the workspace record's sessionIds, then relaunch. (It can be lost again after another crash.)

Happy to provide more details or test a patch.

中文摘要

桌面版宿主进程被 SIGKILL 后重启，某个工作区的会话账目被重写为只剩最新会话：~/.dsh/storages/workspace.json 中该工作区的 sessionIds 丢失了历史会话，旧会话在侧栏落到「未分组」；GUI 没有把已有会话移回工作区的入口（会话拖拽只在同组内排序，工作区拖拽只调整工作区顺序），attachSession 也未暴露给远程 API，所以用户无法自救。会话内容本身没丢。

[TheStreamCode]

This is the same missing capability as #10006 from the crash side. The folder-deleted variant fails earlier: the first prompt cannot assemble the system prompt because workingDirectory.ensure() falls back to the missing header.cwd (packages/session/working-directory/src/index.ts:134-152). The registry already knows (Workspace.status() === 'missing-dir'), but the state is neither exposed nor rendered.

A public workspace/moveSession plus a missing-folder workspace state would cover both cases; details and the minimal fix are in #10006.

[bigfatorangecatjohn]

Confirmed on Windows 0.2.1-rc.5, with the prune site pinned to exact lines — and one trigger that has not been named yet: a crash loop (not just a SIGKILL).

Environment: @deepseek-ai/dsh-desktop 0.2.1-rc.5 (Electron 44.7.0 / Node 24.21.0), Windows 11 x64. One workspace D:\\DSH\\DSH INSTALL ZONE accounted 7 sessions (4 top-level + 3 subagent children), all session.v4.jsonl.zstd.

Observed: the desktop host crash-restarted 9 times between 21:57 and 22:00 local (unrelated auth failure), then came up at 22:01:29. That boot rewrote the workspace record with sessionIds = 1 entry and updatedAt = 2026-11-02T14:01:29.674Z — the boot instant itself. All 7 session directories were intact on disk the whole time, with valid v4 headers whose cwd is exactly the workspace path. So this is not a cwd mismatch, not a junction, not an unreadable header: the ids simply were not in the boot index yet.

Mechanism (@deepseek-ai/dsh-workspace/lib/index.js, bundled in rc.5):

// 367 — the only two ways an id counts as accounted
candidateMatches: (id, path) => this.sessionPaths.get(id) === path || this.missingSessionPaths.has(id),

// 173-185 — every write persists the filtered list
async mutate(fn) {
  next = await this.host.table().update(this.id, (current) => {
    const changed = fn(current);
    const sessionIds = changed.sessionIds.filter((id) => this.host.candidateMatches(id, changed.path)); // 178
    ...
    return { ...changed, sessionIds, updatedAt: new Date().toISOString() };
  });

Two supporting facts make this a permanent, silent loss:

1. sessionPaths is populated only by indexHeader() after realpathNormalize(header.cwd) and stat(path).isDirectory() both succeed (884-889). The only exempt ids are in missingSessionPaths, which is filled exclusively on ENOENT (892). A session that is listed but not yet indexable — or is absent from the boot listing entirely because the on-disk snapshot was inconsistent right after a crash — lands in neither map, so candidateMatches is false and the id is dropped.
2. bootstrap() runs only when initialized === false (387-391). A normal relaunch never re-adopts stored sessions by cwd, so dropped ids never come back by themselves.

The read path filters too (getter at 102-103), so the sidebar shows the truncated list immediately rather than waiting for a write.

Why users cannot diagnose it: reportFilteredCandidates() (905-915) already computes the exact reason (session header is missing / header has no cwd / canonical cwd ... differs from workspace path ...) and logs workspace '<id>' filtered session '<sid>' from membership: <reason>. But the desktop host's stdout/stderr is not persisted: %APPDATA%\\@deepseek-ai\\dsh-desktop\\logs\\crash-*-host.log records only phase / error / renderer console, and host logger output is lost. The one diagnostic that explains the loss is invisible.

Recovery (verified): quit the app, put the missing ids back into the workspace record in ~/.dsh/storages/workspace.json, relaunch. Editing while the app is running does not stick — the registry holds the truncated record in memory and the next mutate rewrites the file from it. We restored all 6 ids this way and they survived the following boot.

Suggested fixes, in decreasing order of value (1 is a sharpening of the net-loss guard proposed in #10513):

1. Do not prune on the write path: const sessionIds = changed.sessionIds; and move any pruning into a separate, explicit, logged maintenance step. Right now an unrelated write (create/rename/reorder) silently deletes membership.
2. Reconcile on every boot, not only during bootstrap: for each stored header whose canonical cwd equals a workspace record's path and whose id is unaccounted, add it back. This makes the loss self-healing with no UI work.
3. Net-loss guard: refuse to persist a shrink of >= 2 ids unless the caller passes an explicit intent flag, and log the full delta.
4. Surface the reason: reportFilteredCandidates() already has it. Persist it to a rotating log file on desktop, and/or render it on the workspace row (N sessions unaccounted — click to restore).

Related: #10513 (same symptom), #9880 (same prune reached through an offline drive), #11507 (same class of loss via hot reload, with no write involved), #11288.

中文摘要：Windows 桌面版 0.2.1-rc.5 实测。桌面宿主因无关故障连续崩溃 9 次后于 22:01:29 启动，该次启动把本工作区 7 条会话账目写成 1 条，updatedAt 正是启动那一刻；7 个会话目录与 v4 header 全程完好、cwd 与工作区路径完全一致。根因确认在 @deepseek-ai/dsh-workspace/lib/index.js：mutate() 第 178 行在写路径上用 candidateMatches 剪枝并落盘；candidateMatches(367) 只认 sessionPaths（需 realpath + stat.isDirectory 成功）与 missingSessionPaths（仅 ENOENT 时登记，892），崩溃后快照不一致 / 尚未索引的会话两边都不在 ⇒ 被永久丢弃；bootstrap() 只在首次初始化跑（387-391），后续启动不会按 cwd 重新接纳，因此不会自愈。reportFilteredCandidates()(905-915) 本会 warn 出确切原因，但桌面宿主不持久化 stdout/stderr，用户拿不到。已验证的恢复办法：退出应用 → 手工把 id 写回 workspace.json → 重启；应用运行中修改无效（内存里的截断记录会覆盖回去）。