0.2.0-rc.1 升级后部分会话被静默移出工作区（显示未分组）

[fanshuishui8]

English TL;DR — After upgrading 0.1.7-rc.2 → 0.2.0-rc.1 (the boot that migrated session logs V3→V4/zstd), 11 sessions vanished from their workspace's durable sessionIds and now render as Ungrouped. Their header.cwd still equals the workspace path (realpath-equal), so nothing moved: the boot-time membership rebuild prunes members with an incomplete path index and then persists that prune on the next record write. There is no re-attach path, so a restart does not heal it and forking an ungrouped session does not either.

环境

• @deepseek-ai/dsh 0.1.7-rc.2 → 0.2.0-rc.1（npm 全局安装），dsh web profile
• macOS（darwin），Node 22.19.0
• 升级方式：npm i -g @deepseek-ai/dsh@0.2.0-rc.1（升级时旧进程仍在跑），随后重启 dsh web
• 该次启动把会话日志从 V3 迁到 V4：<session>/session.v4.jsonl.zstd
• 装了 4 个第三方 bundle（better-sidebar / whale-widget / codearts-auth / 自研 session-bus），与本问题无关，仅说明现场

现象

• 升级重启后，「未分组」里多出 11 个本应属于某工作区的会话（另有 6 个未分组会话的 cwd 本来就不对应任何工作区，属正常）
• 这 11 个里至少 1 个在升级前确实在工作区的成员表里（见证据 2）
• 这 11 个会话的 header.cwd 与某个工作区的 path 完全一致（realpath 相等），不存在目录搬家
• ~/.dsh/storages/workspace.json → tables.workspaces.<workspaceId>.sessionIds 里已经没有它们
• 该文件 mtime = 重启后 6 分钟（正是「新建一个会话」落库那次写入），说明是那次写入把成员表重写了一遍

证据链

1. 解压 ~/.dsh/sessions/--Users-wangyun-work-Python--/<id>/session.v4.jsonl.zstd 的首行得到 header：
   {"id":"session-…","version":4,"cwd":"/Users/wangyun/work/Python","agentPreset":"standard",…}
   与工作区 path=/Users/wangyun/work/Python realpath 相等；对照组（仍留在该工作区里的会话）cwd 一字不差。
2. 升级前（0.1.7-rc.2）我通过宿主 workspaceRegistry.list() 打印过该工作区的 sessionIds，该会话当时是数组第一项（它是当时最新的会话）。
3. 现在同一数组 45 项里没有它；另一个工作区（/Users/wangyun/work/Python/dsh）14 项里没有另外 10 个。其余 59 个会话的成员关系完好。
4. 排除法：不是 cwd 变了、不是目录搬家、不是归档（archivedSessionIds 里没有它们）、不是 subagent（origin 为空）、重启不恢复。

源码级定位（0.2.0-rc.1）

• packages/…/dsh-workspace/lib/index.js:102

  get sessionIds() {
    return this.record.sessionIds.filter((id) => this.host.sessionPath(id) === this.record.path)
  }

  成员 = 持久化记录 ∩ 路径索引。
• 同文件 :178（mutate 的裁剪分支）——任何一次写入都会按「当时那一刻的索引」裁剪并落盘：

  const sessionIds = changed.sessionIds.filter((id) => this.host.sessionPath(id) === changed.path)

• 索引来源：:387/:389 启动时 replaceHeaderIndex(await this.listStoredHeaders())，
  listStoredHeaders() = sessionPersistence.list() 的 header（:892）；
  indexHeader()（:880 起）在 header 读不到或 realpath 失败时只写 invalidSessionPaths，不保留上一次的已知路径。
• reportFilteredCandidates()（:900）本应为每个被裁掉的 id 打一条 warn：
  workspace '<ws>' filtered session '<id>' from membership: <reason>（reason 含 session header is missing）。
  它就是这条路径的「证人」，可惜 dsh web 的 stdout 没有落盘，这次没能留下。
• 没有重新挂载已有会话的入口：attachSession 的调用点只有
  dsh-api-session-controller/lib/index.js:702（新建会话带 workspaceId）与 :830（fork 的子会话）；
  forkWorkspace()（:1037）在源会话不属于任何工作区时返回 undefined，
  所以 fork 一个「未分组」会话，子会话同样不会归组。

期望行为

1. 裁剪只在确证「会话已删除」或「cwd 真的变了」时发生；索引不完整（启动期日志迁移、读取失败）时应保留成员、延后判定，而不是静默落盘删除。
2. 至少能自愈：启动索引建好后，若某会话的 cwd 命中某工作区而成员表里没有它，应幂等补挂。
3. 提供一个把会话移入/移出工作区的 UI 入口（工作区文件夹绝对位置改变后工作区重绑定功能需求 #8029 也在要这个）。

修复建议（任选其一即可）

• 裁剪前对「索引里缺失」的 id 再 readSessionHeader() 确认一次，区分「确实读不到」与「索引尚未建好」；
• 或把裁剪改成非破坏性：先记 pending/候选集合，等索引完整后再决定；
• 或在 boot 的 reportFilteredCandidates() 之后，按 header.cwd 做一次幂等 re-attach。

相关但不同根因

• DSH桌面端更新到0.2.0-rc.1后工作区被清了 #8140（同样 0.2.0-rc.1、同样「未分组」）：楼主自查是桌面更新器清空了安装目录，用户数据被删，属另一条路径。
• Bug: the session that creates a workspace is never registered in that workspace's `sessionIds` (it stays "Ungrouped") #7985：创建者会话不会自动进入新工作区。
• 工作区文件夹绝对位置改变后工作区重绑定功能需求 #8029：目录搬家后无重绑入口。

影响

会话内容没有丢（日志完整）；丢的是工作区归属，而这是用户组织长会话的主要手段，且用户侧无法自行恢复（UI 无入口、重启不自愈）。

临时修法（本地已验证可行）

停掉 dsh web 后，按每个会话 header 的 cwd 找到对应工作区，把 id 插回 ~/.dsh/storages/workspace.json 里该工作区的 sessionIds 头部，再启动即可（启动时索引会按 header 重建，所以补回去能留住）。注意必须在停止状态下改 —— 运行中的进程持有内存记录，会在下次写入时覆盖文件。

[fanshuishui8]

补充更正：我最初把触发条件归给了「升级时 V3→V4 日志迁移导致启动期索引不完整」，这个归因不准确，特此更正。

真正的原因与上游 #1485 同类：并发实例共享 DSH_HOME。本机现场证据：

• 同时运行两个实例、共用 ~/.dsh（连 session 根都相同，也同一份 storages/workspace.json）：
  · dsh web（9/29 16:42 重启）
  · dsh --profile dsh-tui（9/28 11:16:15 启动后一直没关）
• dsh-workspace 的路径索引是进程内的：启动时由 sessionPersistence.list() 建一次（lib/index.js:387/389），
  之后只补本进程的 live 会话（indexLiveSessions() → ctx.sessions.list()，:895-898）。
• 于是「TUI 启动之后、由 web 实例创建的会话」，TUI 的索引里永远没有；它下一次写工作区记录时
  （:178 的裁剪分支）就把它们永久删除。
• 交叉验证：被裁的 11 个会话 11/11 都创建于 9/28 11:16:15 之后（9/28 15:37 / 16:10 / 16:27；
  9/29 10:05–14:59），59 个更早创建的会话一个没掉。

给维护者的两点补充：

1. 裁剪依据的索引应覆盖「持久化里的全部 header」，而不只是本进程感知到的那些；
2. 或至少引入单写者约束/锁（[Bug]: Concurrent dsh instances sharing one DSH_HOME wipe each other’s workspace session membership #1485 的 handbook 章节已给出 topology 表与恢复清单）。

本地临时修法已验证：停写者 → 备份 workspace.json → 按 header.cwd 把 id 插回 sessionIds → 重启
（索引重建后能留住）。但只要两个实例继续同时写这份文件，修复随时会被再裁一次。