Sessions whose stored cwd matches a Workspace stay in "Ungrouped": adoption only runs during the one-time bootstrap

[cnlarry]

Sessions whose stored cwd matches a Workspace are not grouped under it ("Ungrouped"), because adoption only runs during the one-time bootstrap

Where: packages/workspace/workspace/src/index.ts (WorkspaceRegistry[Service.init], bootstrap) + packages/workspace/workspace/src/entity.ts (WorkspaceEntity.attachSession, mutate)

Environment: desktop runtime @deepseek-ai/dsh-desktop-runtime 0.2.0-rc.2 (also present in the published CLI @deepseek-ai/dsh@0.1.5-rc.1); Windows; verified against master (packages/workspace/workspace/src/index.ts, blob 4b4176c5).

Summary

A session is only ever attached to a workspace when SessionController.create() is called with an explicit workspaceId (or when a fork child attaches). There is no recovery path afterwards, so a session that starts any other way — or whose workspace accounting is pruned once — stays in Ungrouped forever, even though its stored header cwd is exactly the workspace path.

Reproduction / observed data

On a machine with one Workspace E:\...\Project\EOS registered since first use (state.initialized === true):

	count
sessions listed in storages/workspace.json for that workspace	22
sessions whose per-session cache identity.cwd is that same path, but which appear in no workspace	31

The ungrouped sessions' stored headers are correct, e.g.

{"type":"session","version":4,"id":"session-09f3f60d-...","cwd":"D:\\Larry\\Documents\\Project\\EOS","isSeeded":false}

so indexHeader resolves them to the workspace path and get sessionIds() would include them — but they were never added to record.sessionIds in the first place.

Root cause

1. Adoption by canonical cwd lives in bootstrap(), which [Service.init] calls only while the registry is uninitialized:

if (!this.state.initialized) {
  const headers = await this.listStoredHeaders()
  await this.replaceHeaderIndex(headers)
  await this.bootstrap(headers)
} else if (this.table.size > 0) {
  await this.replaceHeaderIndex(await this.listStoredHeaders())
}

Once initialized: true is durable (normal after first use), sessionPaths is rebuilt but never reconciled with workspace membership. A session created without a workspaceId is therefore permanently loose.

2. Membership is pruned against that rebuilt index on every write, so a loose id that is not in the index is silently dropped:

// entity.ts — mutate()
const sessionIds = changed.sessionIds.filter(
  id => this.host.sessionPath(id) === changed.path,
)

3. attachSession then refuses to put it back, because its guard reads the raw snapshot rather than the filtered projection:

async attachSession(sessionId: SessionId): Promise<void> {
  // Validation is skipped when the settled snapshot already accounts the
  // id: the cwd fact was checked when it first attached and both inputs
  // (stored header cwd, workspace path) are immutable. Membership itself is
  // decided on the write chain inside `mutate`, never on this snapshot.
  if (!this.record.sessionIds.includes(sessionId)) { ... }
  await this.mutate(record => record.sessionIds.includes(sessionId)
    ? record
    : { ...record, sessionIds: [sessionId, ...record.sessionIds] })
}

this.record.sessionIds is the unfiltered stored array; get sessionIds() filters it by host.sessionPath(id) === record.path. A pruned/never-added id is absent from the filtered view but may be present in the raw one — so the early return skips re-validation and mutate finds the id already present and writes nothing. The result is a session that is visible in the sidebar (the list surface) but accounted to no group.

Note also that the justification "both inputs … are immutable" does not hold for the index: host.sessionPath(id) returns undefined whenever the header was absent from that process's index (header not in the persisted listing yet, cwd unresolvable, directory temporarily missing). The startup order makes this reachable: replaceHeaderIndex(...) runs before indexLiveSessions(), so any write that lands in between prunes candidates whose path is not yet indexed.

Suggested fix

Reconcile membership on every registry open, not only the first. Reusing the existing bootstrap loop is enough and needs no new data:

await this.indexLiveSessions()
// Adopt stored sessions whose canonical cwd matches a registered workspace but
// that no workspace accounts for (e.g. created without a workspaceId). Without
// this, membership is only ever established at create time and a pruned or
// never-attached session stays ungrouped forever.
await this.adoptLooseSessions()
this.rebuildEntities()
this.validateStoredState(this.requireState())
this.reportFilteredCandidates()

with adoptLooseSessions() = the historical half of bootstrap() restricted to already-registered paths (skip sessions already accounted for by any workspace; skip path mismatch or unresolvable cwd with a logger.warn).

Two related hardening points worth considering in the same change:

• make attachSession's guard consult the same projection as get sessionIds() (re-validate when the id is not currently a member), so an explicit re-attach always works;
• or reject an attach whose cwd does not match instead of writing an entry that mutate will immediately prune (today the write can silently no-op).

Workaround (for anyone hitting this before a fix)

storages/workspace.json is the durable registry. Moving a session id into the target workspace's sessionIds — via the UI, or by adding it to the array while the app is stopped — restores grouping, since the read projection only filters by path.

Verification of the workaround fix

Patching only WorkspaceRegistry[Service.init] in a packaged build to run the adoption step on every open (node --check clean, archive byte length unchanged, deterministic replay from a backup) grouped all 31 previously ungrouped sessions under the workspace on restart.

---

中文摘要：会话只有在「带 workspaceId 创建」时才会被挂进工作区；按 cwd 自动收编的逻辑（bootstrap）只在注册表首次初始化时执行一次，之后 initialized: true 便不再收编。同时 attachSession 的守卫读的是未过滤的原始快照，而读取侧的 sessionIds 是按规范路径过滤的 —— 于是被剪掉/从未加入的会话再也挂不回去，表现为「工作目录明明匹配，却一直待在未分组」。实测：一个工作区只收编了 22 个会话，另有 31 个 cwd 完全一致的会话遗留在未分组。建议把收编改成每次打开注册表都执行。

[PerryLink]

"只在一次性 bootstrap 里做采用"——我在源码里核到了对应结构

1. 代码（HEAD = dsh-v0.2.1-alpha.1）

packages/workspace/workspace/src/index.ts
:166  * bootstrap before the service becomes active. …
:196  /** Open the domain, finish bootstrap when required, and rebuild the ordered cache. */
:209        await this.bootstrap(headers)          ← 在 open 路径里调用
:648  private async bootstrap(headers: readonly SessionHeader[]): Promise<void>

⇒ 两处细节支持你的判断：bootstrap 是在"打开域"这条路径上调用（:209），且注释写的是 "finish bootstrap when required"（:196）⇒ 它是有条件的、一次性的。⇒ 因此在它之后才出现的会话（或才被改成匹配某工作区的会话）不会被采用 ⇒ 停在 Ungrouped，与你观察一致。

2. 建议的诉求（把"一次性"改成"幂等可重入"）

采用（adoption）应当与 bootstrap 解耦：在会话被附加（attach）/ 变更（mutate）时也做一次幂等的采用检查，而不是只在服务首次激活时执行一次。

"幂等"这个词很重要：它让改动变成"多跑一次也无害"，从而不必重新设计时序。

3. 请补两样（让这条可复现）

1. 最小步骤：先建一个会话（cwd 尚不匹配任何工作区）⇒ 再创建工作区并指向该目录 ⇒ 观察它是否停在 Ungrouped；若重启后就被归组，那正好证明"只在启动期采用"；
2. attachSession 与 mutate 当前是否会触发采用（你已给出 entity.ts 的符号，把这两处是否调用采用逻辑说清即可——这一句决定修法落在 index.ts 还是 entity.ts）。

4. 版本

你写桌面运行时 @deepseek-ai/dsh-desktop …；当前最新 HEAD 是 0.2.1-alpha.1，我核到上述结构仍在 ⇒ 这条无需在新版重测。

[easonlao]

Another trigger for this: the one-shot bundle never mounts the workspace layer at all.

Environment: @deepseek-ai/dsh@0.2.1-rc.2, Linux (Ubuntu, kernel 6.8), dsh web running under systemd --user.

I drive dsh from an assistant on my phone, which spawns dsh --profile headless --json [--session-id <id>] <text> for every message. Comparing the two composed trees:

• dsh --profile web --dump-config contains workspace, workspace-controller, ui-workspace.
• dsh --profile headless --dump-config contains none of them — only sandbox-policy with workspaceRoot: process.cwd().

So a session created on that path carries a correct header (cwd is the registered workspace path), but no code exists that could ever attach it: attachSession is only reached from SessionController.create()/fork(), and the headless bundle has no session controller. This is not a crash and not a prune — the session is born outside the registry, every time.

Observed on one machine, single workspace /home/lyx/DSH:

	count
sessionIds in storages/workspace.json	36
session directories under sessions/--home-lyx-DSH--/	66
loose (in no workspace), cwd = the workspace path	30 (20 with origin: "subagent", 10 ordinary)

There is no escape hatch either: workspace/insertSessionBefore rejects them with "the session is not accounted", and the sidebar offers no "move to workspace" action.

Workaround that works, at the cost of downtime: stop dsh-web, append the ids to sessionIds, start it again. Editing the file while the host runs is lost on the next workspace mutation, because the registry writes back its in-memory copy.

Suggestion, if a per-start adoption pass is acceptable: when the registry opens, adopt every stored session whose canonical cwd equals a registered workspace path and that is not yet accounted — idempotent, no reordering, no title changes. That would cover this case, the crash case in #10467, and make external drivers like the one-shot CLI behave like sessions created in the browser.