[Bug Report] 会话可「无归属」落盘 + 工作区记账被并发静默回滚：55% 的会话在 UI 中不可见且无法恢复

[hyzyn]

报告类型：缺陷（Defect）
严重程度：高 —— 用户视角等同「会话被弄丢了」；会话日志完好，但 UI 中永久不可见，且无任何恢复入口
状态：本机数据已完整量化；发现一为确定性（单实例可复现），发现二为高置信度（结构证据充分，未端到端复现）
版本：0.1.5-rc.2（@deepseek-ai/dsh、dsh-base、dsh-workspace、dsh-api-session-controller、dsh-session-persistence-jsonl、dsh-storage-json 同版本）
平台：macOS 15.6 arm64 ／ Node v22.23.2 ／ npm 全局安装 ／ DSH_HOME=<HOME>/.dsh

1. 现象

• 侧栏里某个工作区的会话整批消失，或「这个目录我明明用过却一个会话都没有」；重启宿主也不恢复。
• 会话日志仍在 <DSH_HOME>/sessions/<cwd slug>/<session-id>/session.v3.jsonl.zstd，可正常解压、内容完整。
• <DSH_HOME>/storages/workspace.json 的 sessionIds 不含这些会话；而 WorkspaceEntity.sessionIds
  按 canonical cwd 过滤（dsh-workspace/lib/index.js:102-103），未记账的会话在侧栏 / 会话列表 /
  搜索面板一律不可见。
• 具体案例（本机某个业务工作区，别名 proj-8）：磁盘 2 条会话、记账 1 条。丢失的是
  session-ec9f3585…（2026-09-17T05:50:39.989Z 创建、11 轮、1.4 MB）。该工作区的注册记录
  createdAt = 2026-09-17T08:17:42.775Z，记录里唯一的会话 session-6307b366…
createdAt = 08:17:42.856Z：注册是这次新建会话时才出现的，旧会话被留在外面。

2. 影响量化（本机实测）

指标	数值
磁盘上的会话日志	437
workspace.json 记账的会话	196
UI 中不可见的会话	241（55 %）
磁盘上的工作区目录	44
workspace.json 中的工作区注册	10（34 个目录完全没有注册）
丢失时间跨度	2026-08-14 ~ 2026-09-17（持续发生，含当天新建的会话）

按目录样例（proj-1 64 条、proj-2 19 条、proj-3 9 条、proj-4 8 条、proj-5 7 条、proj-6 7 条、
proj-7 3 条、proj-8 1 条……），完整分布见附录 C。

3. 根因

3.1 会话可以「无归属」地落盘（确定性，单实例可复现）

1. session.create 仅当请求带 workspaceId 时才挂载到工作区：
   dsh-api-session-controller/lib/types/commands.js:110-117。
2. 请求允许「只给 cwd」甚至「什么都不给」：
   dsh-api-session-controller/lib/types/types.d.ts:253-258（workspaceId? / cwd? / sessionId?）。
3. 什么都不给时落在宿主进程的 process.cwd()：
   dsh-api-session-controller/lib/index.js:2729
   → this.commands = new SessionCommandController(ctx, this.agents, process.cwd())；
   create 里 const cwd = workspace?.path ?? request.cwd ?? this.defaultCwd（commands.js:102）。
4. 客户端确实存在「裸 create」路径。例如第三方插件 @hyzyn/dsh-search 的「新建会话」兜底就是
   const id = await sessions.create()（该插件自带注释：优先走 GUI 服务、其次点侧栏按钮、最后才自己建）。

本机证据：<DSH_HOME>/sessions/<host-cwd slug>/ 下有两条 0 KB 会话，cwd 恰好等于 web 宿主的
process.cwd()，且没有任何工作区注册：

<cwd> | session-1b515d04… | 2026-09-12T08:38:22.695Z | accounted=false | 0KB
<cwd> | session-a99bab14… | 2026-09-12T08:38:23.336Z | accounted=false | 0KB

期望：工作区归属应当由宿主保证（create 在 workspaceId 缺省时按最终解析出的 cwd
resolveByPath()，必要时创建注册），而不是留给每个客户端自行遵守。

3.2 已入账的记账会被第二个宿主静默回滚（高置信度）

1. 存储根与 profile 无关：dsh-base/cordis.patch.yml:151 → root: !!js dshHomePath('storages')。
   全机只有一个 workspace.json（find <DSH_HOME> -name 'workspace.json*'）。

2. workspace 域未声明 layout（dsh-workspace/lib/index.js:248-260），按
   dsh-storage-json/lib/index.js:575 落到 single 布局 → 整个域（global + 全部 records）
   写在一个文件里，任何一次变更都重写全量。

3. 写入协议是「内存快照 → 临时文件 → rename() 覆盖」（dsh-storage-json/lib/index.js:26-38），
   模块注释（:8-16）写着：

   a unit file has exactly one writer per process and last-write-wins is correct

   即没有锁、没有 revision 校验、没有冲突检测；dsh-storage-domain/lib/index.js:316-320 的
   「single-open per domain name」只覆盖单进程内。

4. 本机同时运行两个宿主且共用 DSH_HOME（lsof 证据见附录 A）：
   profile web → *:3080，profile test → 127.0.0.1:3082。

于是：宿主 A 把 workspace.json 读进内存 → 宿主 B 新增注册/挂载会话并写回 → A 之后任意一次 workspace
变更用陈旧快照覆盖 → B 的记账静默消失（反之亦然）。会话日志走的是另一套「每会话独立文件 + 追加写 +
no-clobber」协议（dsh-session-persistence-jsonl/lib/index.js:2858-2888），所以只有记账丢。

dsh-storage-json/README.md:12 只泛泛建议「写量大或高并发时选 SQLite」，没有任何地方提示
「同一 DSH_HOME 并发运行多个宿主会丢记账」，宿主也不做检测 / 拒绝 / 只读降级。

3.3 损坏不可观测、不可恢复

• 历史重建是一次性的：if (!this.state.initialized) { ...bootstrap... }
  （dsh-workspace/lib/index.js:336-353，实现自 :595）。initialized 一旦为 true，
  之后每次启动只做 replaceHeaderIndex，永远不再收编「磁盘有日志但没有记账」的会话。
• 没有 reconcile 入口：workspace 域 RPC 只有 create / rename / delete / insertBefore / insertSessionBefore / archiveSession / createDirectory / pick / list，没有 rescan/reconcile/rebuild；
  客户端 sessions.open(id) 只能选中「已列出」的会话（dsh-api-session-controller/lib/client.js:3089-3095），
  搜索面板点开走的还是同一个 sessions.open()。
• 诊断信号被丢掉：被过滤的会话只通过 ctx.logger.warn 打到宿主 stdout
  （dsh-workspace/lib/index.js:737-747），宿主是终端前台进程、日志不落盘。

与 README 已声明限制的关系：dsh-workspace/README.md:160-164 已声明「删除注册不删数据」
「re-adding a directory starts fresh — the old sessions do not come back automatically」
「归档单向」；本报告不主张改变这些产品决策，只主张：当记账被 3.2 静默回滚时，
用户会在什么都没做的情况下落到同一结局，而 3.3 让这个结局无法被发现、无法被修复。

4. 最小复现

R1（无归属落盘，单宿主确定性）

1. 令目录 Q 没有工作区注册。
2. 调用 session.create 且不带 workspaceId（{cwd: Q}，或什么都不带 → 落在宿主 process.cwd()）。
3. 结果：会话日志落盘并可正常打开，但不属于任何工作区 → UI 不可见，重启也不出现，
   workspace.json 中没有任何记录包含它的 id。

R2（双宿主覆盖）

1. 同一个 DSH_HOME 下同时启动 profile A（3080）与 profile B（3082）。
2. 在 A 中打开目录 P1 并新建会话 → 出现 P1 注册。
3. 在 B 中打开目录 P2 并新建会话 → 出现 P2 注册。
4. 回到 A 做任意一次 workspace 变更（新建会话 / 归档 / 重排 / 删除 / 重命名）。
5. 结果：B（或 A 在第 3 步之后新增）的记账从文件消失，会话日志仍在，UI 不可见，重启不恢复。

5. 建议修复

P0-1 · 让「落盘的会话必有归属」成为宿主不变量
session.create 在 workspaceId 缺省时按最终解析出的 cwd 做 resolveByPath()：命中则 attachSession，
未命中则创建注册（或至少明确报错）。另外 defaultCwd = process.cwd()（lib/index.js:2729）对 GUI 宿主
是个尴尬落点，建议改为「无 cwd、无 workspaceId 的创建必须由连接上下文给出 cwd」。

P0-2 · 单写者保护 / 多实例检测

• dsh-storage-json 增加跨进程互斥（同目录锁文件 + PID/心跳 + 陈旧锁回收），或写入前比对
  mtime/revision，发现外部变更就重载合并、不可合并则报错，而不是静默覆盖；
• 或把 workspace 域改成 layout: "per-record"（session_projcache 已是该布局），把覆盖粒度降到单工作区；
• 宿主启动时检测「同一 DSH_HOME 是否已有活跃宿主」，第二个实例拒绝启动或只读降级；
  至少在 dsh-storage-json README 中写明这一风险。

P1 · 让记账可自愈 + 有入口
把一次性 bootstrap 改成可重入的 reconcile（启动时把未被任何注册收编的 header 按 canonical cwd 归并回去；
initialized 不该是永久闸门），并提供 dsh workspace reconcile（CLI）与 GUI「重新扫描历史会话」入口。

P2 · 可观测性
reportFilteredCandidates() 的结果进入可查询的诊断面，而不是只打 stdout；
workspace.json 写入带 revision + writer 标识，便于定位被回退的写入者。

6. 我已做的临时缓解（仅供参考，不算修复）

• 用只读脚本量化了损失范围，并快照备份了 workspace.json；
• 准备了兜底恢复工具：宿主停止后把 global.initialized 置回 false，让 bootstrap 重新收编
  （本机 196/437 → 299/437；剩余 138 条属于完全没有注册的目录）；
• 写回前用同一份代码在副本上预演，并做 workspace 域不变量校验（唯一路径、会话不被两个工作区重复记账、
  注册顺序与表一致）。

附录 A：双宿主证据（lsof，节选，路径已脱敏）

$ lsof -nP -iTCP -sTCP:LISTEN | grep node
node <pid-A> ... TCP 127.0.0.1:3082 (LISTEN)   # profile test
node <pid-B> ... TCP *:3080 (LISTEN)           # profile web

$ lsof -p <pid-A> | grep '\.dsh'      # profile test 读同一套 $DSH_HOME
... <DSH_HOME>/settings.yaml
... <DSH_HOME>/cordis.patch.yml
... <DSH_HOME>/profiles/test/cordis.yml

$ lsof -p <pid-B> | grep '\.dsh'      # profile web
... <DSH_HOME>/settings.yaml
... <DSH_HOME>/cordis.patch.yml
... <DSH_HOME>/profiles/web/cordis.yml

$ find <DSH_HOME> -name 'workspace.json*'
<DSH_HOME>/storages/workspace.json          # 全机只有一个，两个宿主共用

本机 profiles/test/cordis.patch.yml 里为避开端口冲突固定了 3082，说明双开是有意的配置
（不是偶发多开），因此这一并发形态很可能不是个例：

- id: webserver
  config:
    host: '127.0.0.1'
    port: 3082

附录 B：核查脚本（只读，可直接运行）

const fs = require('fs'), path = require('path'), { execSync } = require('child_process');
const ROOT = path.join(process.env.HOME, '.dsh');
const store = JSON.parse(fs.readFileSync(path.join(ROOT, 'storages', 'workspace.json'), 'utf8'));
const accounted = new Set();
for (const r of Object.values(store.tables.workspaces)) for (const id of r.sessionIds) accounted.add(String(id));

const dirs = (p) => fs.readdirSync(p, { withFileTypes: true }).filter((e) => e.isDirectory()).map((e) => path.join(p, e.name));
let onDisk = 0, orphans = 0;
for (const project of dirs(path.join(ROOT, 'sessions')))
  for (const session of dirs(project)) {
    const log = fs.readdirSync(session).filter((f) => /^session(\..+)?\.jsonl\.zstd$/.test(f)).sort().pop();
    if (!log) continue;
    onDisk++;
    const header = JSON.parse(execSync(`zstd -dc -q "${path.join(session, log)}" 2>/dev/null | head -1`).toString());
    if (!accounted.has(String(header.id))) orphans++;
  }
console.log(`initialized=${store.global.initialized} workspaces=${store.global.workspaceIds.length}`);
console.log(`session logs on disk=${onDisk} accounted=${accounted.size} invisible=${orphans}`);

本机输出（修复前）：

initialized=true workspaces=10
session logs on disk=437 accounted=196 invisible=241

附录 C：两种失效签名（判别线索）

对已有注册的工作区，比较「已记账会话的创建时间范围」与「未记账会话的创建时间范围」：

• 未记账会话都比已记账最新会话更旧 → 与「注册被后建/重建」一致（README 已声明的 starts fresh）。
• 出现比已记账最新会话更新的未记账会话 → 后建注册无法解释，指向 3.1 或 3.2。

工作区（别名）	已记账 条数/时间范围（UTC）	未记账 条数/时间范围（UTC）	未记账中「更新」的条数
proj-1	69 / 08-15 13:50 ~ 09-15 06:37	64 / 08-15 05:44 ~ 09-17 05:44	3
proj-3	51 / 08-18 08:18 ~ 09-15 09:21	9 / 08-19 03:30 ~ 08-29 07:55	0
proj-4	29 / 08-14 01:31 ~ 09-15 14:16	8 / 08-17 08:30 ~ 09-16 09:19	2
proj-10	14 / 08-22 02:08 ~ 09-11 08:12	2 / 08-24 01:17 ~ 08-29 07:54	0
proj-7	14 / 08-18 01:20 ~ 09-16 04:40	3 / 08-29 07:57 ~ 08-29 08:37	0
proj-5	9 / 08-25 03:24 ~ 09-03 04:11	7 / 09-01 07:44 ~ 09-02 02:56	0
proj-11	5 / 09-16 01:52 ~ 09-17 08:09	0	0
proj-6	3 / 09-07 12:35 ~ 09-15 08:35	7 / 09-12 08:33 ~ 09-17 04:41	1
proj-9	1 / 09-14 07:03	2 / 09-14 07:30 ~ 09-16 07:46	2
proj-8	1 / 09-17 08:17	1 / 09-17 05:50	0

proj-9 最干净：注册与其唯一会话在 09-14 07:03 同时建立，而同目录 07:30 之后创建的会话全都没被记账 ——
说明「无归属落盘」可以发生在宿主正常使用、且工作区已注册的情况下。

附录 D：待确认的观察

• 排查期间 16:24 → 16:30 之间，某条工作区注册（3 条会话，日志完好）从文件中消失。
  无法确认是用户经 GUI 删除，还是 3.2 的覆盖 —— 这本身也说明缺少写入者标识/revision。

---

关于补丁：注意到本仓库外部 PR 已关闭（has_pull_requests: false）。如果需要，我可以把
「可重入 reconcile」或「create 时兜底 attach」的小改动放到 fork 分支上，再在这里贴链接；
需要的话请告知倾向哪条修复路线。

---

说明：本报告只引用会话元数据（创建时间、字节数、按目录的计数）与代码位置，未包含任何会话消息内容、
业务文档、仓库名或凭据；路径与项目名已用占位符/别名替换。