DSH 会话从侧栏消失 / 变为「会话不可用」

[BigStorm233]

环境

• DSH Desktop 0.2.2-rc.1（2026-11-04 构建，Electron 44.7.0 / Node 24.21.0）
• Windows 11 x64，中文界面
• Profile：desktop（默认 bundle + dsh-market + dsh-whale-widget）

现象

1. 侧栏某个工作区里，个别会话会从列表消失（工作区本身还在，同组其他会话正常）。通常每次 2 个左右。
2. 已打开的这些会话，标题退化为 session-xxxx…，输入框显示「会话不可用」，无法输入，也无法继续对话。
3. 窗口本身完全正常：可拖动、可缩放，其他会话可点开；DSH 进程 CPU/内存正常，端口有响应。
4. 重启应用后恢复；过一段时间（尤其待机/挂起回来后）再次出现。
5. 磁盘上会话日志、工作区成员关系都完整，重启即可恢复 → 不是数据丢失。

复现步骤（最小）

1. 打开一个较大的会话 A（让它驻留在内存中），然后切到另一个会话 B。
2. 等待宿主释放/卸载 A（待机几分钟再回来更容易触发）。
3. 观察侧栏：A 从所属工作区消失。
4. 若再打开 A（例如通过搜索或已保留的视图）：标题变成 session-…，输入框提示「会话不可用」。
5. 重启 DSH：A 重新出现在侧栏且可正常输入。

期望：卸载 A 不应让它从侧栏消失，也不应让已打开的 A 变成只读。

根因分析

DSH 不支持删除会话（只能归档），所以 session/disposed 语义上只是从内存 store 卸载，并不代表删除。
但宿主把它直接当成「会话被删除」转发给客户端：

@deepseek-ai/dsh-api-session-controller/lib/index.js:3828

ctx.on("session/disposed", (session) => {
    ctx.emit("api-session/removed", session.id);
});

客户端收到 removed 后：

@deepseek-ai/dsh-api-session-controller/lib/types/client/sessions/manager.js:620

handleSessionRemoved(sessionId) {
    ...
    this.recordMutation(durableSubagent
        ? { kind: 'status', sessionId, running: false, agentAvailable: false }
        : { kind: 'remove', sessionId });   // ← 侧栏这一行被移除
    ...
    this.sessions.get(sessionId)?.handleRemoved();  // ← 已打开实例标记 removed
}

而输入框的禁用条件里包含 removed：

@deepseek-ai/dsh-client-ui-conversation/lib/client.js:21826

const disabled = removed || inert || !live || blocked !== void 0 || parentOffline;
// disabled 为真时 placeholder 取 placeholder.unavailable → 「会话不可用」

客户端只有在连接重建 / 启动时才重新拉全量列表（handleConnected() → refreshList()），
因此行一旦被移除，会一直缺到下次重启。

数据证据

• 工作区注册表成员关系完整，无缺失。
• 会话目录与注册表一一对应，session.v4.jsonl.zstd 的头部（id / cwd / createdAt / version）全部可正常解析。
• 消失的会话均在磁盘上存在，且重启后完整恢复。

建议修复

• 宿主：session/disposed 不要映射为 api-session/removed。卸载应发「已卸载/离线」或什么都不发，交给下一次 session.list 覆盖。
• 或客户端：收到 removed 后回查列表；若该 id 仍在 session.list 中，应视为「未加载」，只清实例、不删行。
• removed 也不应永久禁用输入，可退化为「重新打开」提示。

补充

• 不是渲染层卡死：窗口可操作，进程指标正常。
• 不是归档状态：归档行会置灰展示（在「全部对话（显示已归档）」下可见），这些会话是整行消失。
• 更新器里下载的 0.2.2-rc.1 与当前运行版本相同，安装后仍可复现。

[PerryLink]

这是真 bug：host 把「从内存卸载」当成「删除」发给客户端了。

packages/api/session-controller/src/index.ts:227-228：

ctx.on('session/disposed', (session) => { ctx.emit('api-session/removed', session.id) })

客户端收到后，非 subagent 会话走 { kind: 'remove' } 并把实例标成 removed（src/client/sessions/manager.ts:684-691），快照里带 removed: boolean（contract/snapshot.ts:77）。侧栏行被删、已打开实例变只读，和你的观察一一对应。

session/disposed 只表示离开内存 store，不等于归档。修法形状：给归档/删除单独的事件，或让客户端在 removed 时只标记不可用、保留列表行，等下一次列表快照再决定。

短期重启恢复是对的。如果想抓现场，趁会话消失但应用没重启时，把侧栏状态和对应 session-*.jsonl.zstd 的时间戳留下来。

这段可以直接给 AI，让它对着 index.ts:227 和 manager.ts:684 改。

[kenyonxu]

Independent reproduction + plugin-isolation data point (0.2.2-rc.1, Windows 11 desktop):

Same symptoms as described — clicking/switching sessions in one workspace group makes rows vanish from the sidebar (click through the whole group and it empties); an app restart restores the list; session logs and workspace membership intact on disk.

A/B isolation: removing all third-party bundles from the desktop profile (only the default bundle set) does not stop the repro — rows still disappear on click. So it is not plugin-interaction; it reproduces on the stock composition.

Notably, the same stack (dsh CLI 0.2.2-rc.1 driving dsh web) in a regular browser does not show it — the list keeps every row across clicks and group switches. That matches the host-side session/disposed → api-session/removed analysis above: the desktop host is more aggressive at unloading idle sessions from the memory store, so the mis-signaled removed event actually reaches the client list, while the web host kept the sessions resident.

Workaround we use: restart the app (list rebuilds from disk, nothing lost).