[Bug]: Concurrent dsh instances sharing one DSH_HOME wipe each other’s workspace session membership

[KaramachiA217]

Bug report: concurrent dsh instances sharing one DSH_HOME wipe each other's workspace session membership

Summary

Running two dsh web instances (different profiles, different session-persistence-jsonl roots, same DSH_HOME)
against the same workspace directory makes the sidebar's workspace group lose sessions:
every session.create on one instance permanently removes the other instance's sessions from the
workspace account, so they fall into the sidebar's Ungrouped bucket. The user sees
"sessions keep moving from the workspace into Ungrouped" and the damage is durable
(the one-time bootstrap never re-adopts them).

Environment

• Windows 11, Node 24, current master
• DSH_HOME = C:\Users\<user>\.dsh
• Profile web: dsh --profile web web → 127.0.0.1:3080, session root $DSH_HOME/sessions
• Profile desktop: dsh --profile desktop web → 127.0.0.1:5478, session root $DSH_HOME/sessions-desktop
  (isolated via a profile patch on session-persistence-jsonl.root, as recommended)
• Both profiles share the workspace domain file $DSH_HOME/storages/workspace.json
  (storage-json.root = dshHomePath('storages') in packages/bundle/web-app/cordis.patch.yml is home-level, not profile-scoped)

Observed behavior (timeline, UTC)

1. 15:30:16Z — web instance attaches session A (session-27caaf14…).
   workspace.json now records sessionIds: ["A"].
2. 15:37:01Z — desktop instance creates and attaches session B (session-e6d05dba…).
   workspace.json is rewritten with sessionIds: ["B"], updatedAt: 15:37:01Z. A is gone from the account.
3. The two running instances now disagree:
   • web (3080) workspace.list → sessionIds: ["A"]
   • desktop (5478) workspace.list → sessionIds: ["B"]
   • disk → ["B"]
4. After the web instance next writes (or restarts), session A appears under Ungrouped in the web sidebar.

This happened repeatedly during the day: every attach on either instance left exactly the newest session
of whichever instance wrote last; all other sessions (including archived ones, whose slots should be kept)
ended up unaccounted.

Root cause

• WorkspaceEntity.mutate() (packages/workspace/workspace/src/entity.ts) re-filters
  record.sessionIds on every write:
  changed.sessionIds.filter(id => this.host.sessionPath(id) === changed.path).
• host.sessionPath(id) answers from the registry's in-process header index
  (packages/workspace/workspace/src/index.ts), built at startup from this process's own
  sessionPersistence.list(). A session stored under the other profile's session root is
  simply not in the index → sessionPath(id) === undefined → the id is durably pruned.
• The durable workspace domain (storages/workspace.json) is home-level and shared by every
  profile, so the two registries fight over one file: last writer wins, and each writer
  destroys the other's membership.
• Re-adoption only happens in the one-time bootstrap (initialized === false), so pruned
  sessions never return to the workspace group.

The sessions' headers are all valid: every header's cwd canonicalizes exactly to the workspace
path (E:\DshProject\Test), verified by decoding the zstd logs. So this is not a cwd/path mismatch.

Suggested fix

The prune should be non-destructive for sessions the writer has not indexed:

• In WorkspaceEntity.mutate(), only drop an id when its canonical cwd is known and differs
  from the record path (or is known-invalid, e.g. cwd unresolvable / not a directory).
  Keep ids that are merely absent from the writer's header index
  (sessionPath(id) === undefined and the header isn't cached at all).
  The registry already distinguishes these two cases in reportFilteredCandidates()
  (session header is missing vs canonical cwd … differs), so the needed knowledge exists;
  it just needs to be exposed through the entity host (or the filter moved into the registry).

Alternative/complementary: document (or enforce) that two live instances must not share the
storage-json root, mirroring the existing guidance for session-persistence-jsonl roots.

Repro sketch

1. Create a workspace at directory W in instance 1.
2. session.create {sessionId: A, workspaceId} on instance 1 (root sessions-1).
3. session.create {sessionId: B, workspaceId} on instance 2 (root sessions-2, same DSH_HOME).
4. workspace.list on both instances and inspect $DSH_HOME/storages/workspace.json:
   the account holds only the newest session of the last writer; the other was pruned.

Impact

Data is not lost (session logs are intact) but workspace organization silently degrades:
sessions the user worked on for hours land in "Ungrouped" and cannot get back into the
workspace group without manual re-attach via session.create re-adoption.

[JakeLi168]

独立复现确认 + 读侧根因补充（macOS，0.1.1-rc.2，第三方 Desktop 壳 + 官方 web 组合）

独立遇到同类故障，并在 0.1.1-rc.2 产物源码中定位到根因。对本报告补充两点：

1. 常见真实组合零配置即踩中：第三方 DSH Desktop 壳 + 官方 web。 先澄清：我们的桌面端是第三方 DSH Desktop 壳（内嵌 server :43120），并非 deepseek-ai 官方应用；但它默认同样使用 ~/.dsh 下同一套数据——与官方 dsh web（launchd 常驻，:3080）共享同一个 session root（~/.dsh/sessions/）和同一个 ~/.dsh/storages/workspace.json，之间没有任何 profile 隔离。任意两个共享 DSH_HOME 的实例（官方 web 双 profile，或 web + 此类第三方壳）都默认处于这个暴露面上。

2. 「列表陈旧」独立于「写侧丢更新」——读路径从不重扫。 @deepseek-ai/dsh-workspace 的 WorkspaceRegistry：init() 只在启动时做一次 sessionPersistence 全量扫盘（replaceHeaderIndex）；之后仅 indexLiveSessions() 索引本进程新建的会话。全包无 fs watcher、无周期性重扫（唯一的惰性重扫在归档路径的 sessionKnown()）；而喂给侧栏的 list()（经 dsh-host-apiproxy：items: ctx.workspaceRegistry.list()...）在源码注释中明确写着 "performs no persistence reads"。后果：每个实例的侧栏冻结在「启动快照 + 本实例存活会话」。我们的事故里 web 已运行约 17 小时，当天 Desktop 壳新建的所有会话在 web 侧栏全部不可见，直到重启 web——而会话文件与其 workspace.json 成员位其实早已落盘（实测：重启后全部现身；纯读场景无数据丢失）。

因此即使修好写侧覆盖（merge-on-write 等），跨实例会话在没有重扫/通知机制时依然永远不会出现。反过来，只需在 list() 前对 sessions root 与 workspace.json 做一次 stat-mtime 检查——有变化就重跑 replaceHeaderIndex 并重载 domain——就能一并解决：陈旧列表、收养被抹掉的成员、以及本报告提到的「one-time bootstrap 永不再收养」。

3. 同一轮排查的关联发现

• dsh-web / dsh-host-webserver / dsh-app-boot 均无单实例防护（无 lockfile/flock）——同一 DSH_HOME 跑两个 server 非常容易，而这正是 Desktop 壳+web 并存场景的常态。
• @deepseek-ai/dsh-storage-json 自述假设："single writer per process and last-write-wins is correct"——Desktop+web 组合默认就违反该假设。
• 会话 id 铸造是进程内的：API 层用 session-${randomUUID()}（无碰撞问题），但 SessionStore.prepare() 的缺省铸造路径（session-${++counter}）查重只查本进程内存；叠加 [bug] Concurrent session writers cause corrupt session log (seq collision) - history/model fail to load #4208（并发写同一会话日志损坏），两实例同时使用同一会话仍有风险。

如需我们事故中的会话/workspace.json 快照佐证，可以提供。

[denial123789]

I turned this report into a source-backed English recovery guide: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/concurrent-dsh-home-session-membership.md — it documents the shared workspace-store race, safe DSH_HOME topologies, recovery steps, and tests that inspect durable membership. Feedback welcome.

[slmeng]

Additional data point: official Desktop app + official dsh web, no profile isolation — session absent entirely, not just Ungrouped

Both instances here are official builds with zero profile patching, so the usual "isolate the session root per profile" mitigation doesn't apply.

Environment — macOS 26.7, arm64. Desktop: DeepSeek Harness.app 0.2.0-rc.2, profile $DSH_HOME/profiles/desktop. Web: @deepseek-ai/dsh@0.2.0-rc.2, dsh web --no-open, profile $DSH_HOME/profiles/web. Both use DSH_HOME=/Users/<user>/.dsh, and neither patches session-persistence-jsonl.root or storage-json.root, so both share $DSH_HOME/sessions and $DSH_HOME/storages/workspace.json. Web host had been up since Sep 29.

Observed (2026-10-03 PDT)

1. 20:04 — desktop creates session-abfe3410-…, cwd /Users/<user>/repo/ai-switch.
2. 21:04 and 21:17 — two more root sessions appear in the same directory; the web host holds session.lock for both, so they are web-side attachments.
3. storages/workspace.json → the ai-switch workspace listed only those two. session-abfe3410 was in no workspace record at all — unaccounted, not merely filtered.
4. The desktop host held its session.lock; the web host did not:

$ lsof -p <desktop-host-pid> | grep abfe3410
.../--Users-<user>-repo-ai-switch--/session-abfe3410-.../session.lock

5. The web host republished the whole workspace.json at 21:21, after the desktop session already existed.
6. The header is valid and its cwd canonicalizes exactly to the workspace path — not a cwd mismatch.
7. In the web UI the session was not under the project and not under Ungrouped — invisible entirely. Consistent with @JakeLi168's read-side point: the index was built at web startup (Sep 29, before the session existed) and nothing rescans.

Root cause still present at 5badb15009

• workspace/src/entity.ts mutate(): changed.sessionIds.filter(id => this.host.sessionPath(id) === changed.path)
• workspace/src/index.ts [Service.init]: bootstrap() only when !state.initialized
• storage-json single: memory authoritative, whole file republished, no cross-process locking

Recovery — stop both writers, back up workspace.json, append the missing id to the record's sessionIds (atomic replace), restart the web host. Two negative results worth noting: a browser refresh alone does nothing, and restarting the web host before repairing the durable account also does nothing. So both halves are needed — merge-on-write, plus a rescan or change notification on the read path.

Ask — per docs/architecture.md the desktop host deliberately runs the shared profile runner against the same $DSH_HOME, so anyone with the desktop app open and dsh web running reaches this with no exotic config. Can the maintainers confirm the supported topology? If concurrent writers aren't supported, a single-writer lock plus a loud startup diagnostic would at least surface it.