[Bug] 工作区选择根目录后无法在该工作区创建对话，并跳转至其他工作区

[lishang25253]

（别问我为什么要在根目录创建工作区，我只是想清个C盘😅）

Windows 盘根目录工作区无法创建 Session

环境

• Windows 11 x64
• DSH Desktop 2.0.13（社区 Electron 外壳），内置 @deepseek-ai/dsh 0.1.5-rc.2
• Host 运行时：Electron 43.3.0 ELECTRON_RUN_AS_NODE → Node v24.18.1
• 另在系统 Node v20.19.0 上独立复现
• 涉及包：@deepseek-ai/dsh-api-session-controller@0.1.5-rc.2

摘要

在 Windows 上，如果某个 Workspace 的 path 是盘根目录（C:\、D:\），就永远创建不出 Session。因为 createOrAdopt 无条件调用mkdir(cwd, { recursive: true })，而 Node 在 Windows 上对「卷根」调用它会抛 EPERM—— 哪怕那个目录明明已经存在。

Host 其实把这个失败正确包装成了一个信息完整的 gateway/internal RemoteError，但 Web 客户端「新建会话」页的工作区选择器把这个 rejection 直接丢掉了，所以用户看到的现象只是「选中后自己跳回原来的」—— 没有报错、没有提示、没有日志。

复现步骤

A. 纯 Node 四行（不需要 DSH）

const fs = require('node:fs/promises')

await fs.mkdir('C:\\', { recursive: true })                  // 抛错
await fs.mkdir('D:\\', { recursive: true })                  // 抛错
await fs.mkdir('D:\\PEIA', { recursive: true })              // 正常
await fs.mkdir('D:\\workspace\\crawler', { recursive: true }) // 正常

实测输出（Node v24.18.1 与 v20.19.0 一致）：

FAIL  mkdir("C:\\", {recursive:true}) -> EPERM : EPERM: operation not permitted, mkdir 'C:\'
FAIL  mkdir("D:\\", {recursive:true}) -> EPERM : EPERM: operation not permitted, mkdir 'D:\'
OK    mkdir("D:\\PEIA", {recursive:true})
OK    mkdir("D:\\workspace\\crawler", {recursive:true})

注意盘根目录是存在的，而且 fs.realpath('C:\\') === 'C:\\'—— 所以这不是「目录不存在」的问题，而是递归 mkdir 在卷根上根本无法成功。

B. 产品级

1. 添加一个指向 C:\ 的 Workspace（应用内目录选择器接受它，realpathNormalize 也接受，Workspace 记录成功创建）。
2. 打开新会话，在「新建会话」页的工作区选择器里选中它。
3. chip 先显示成新工作区，随后跳回原来的工作区。用户得不到任何反馈。

实际结果

session.create 被拒绝，错误为：

gateway/internal: failed to create session "session-…":
Error: failed to ensure project directory "C:\": EPERM: operation not permitted, mkdir 'C:\'

而客户端完全不显示任何反馈。

期望结果

要么 Session 创建成功（目标目录本来就存在），要么明确告知用户失败原因。盘根目录是合法的 Workspace 选择 —— 例如「让 agent 清理整个卷」这种用途 ——而目前它根本无法获得 Session。

根因

1. 无条件的递归 mkdir —— packages/api/session-controller/src/agent.ts:481（函数 createOrAdopt，起于 agent.ts:444）：

try {
  await mkdir(cwd, { recursive: true })
} catch (error) {
  throw new Error(`failed to ensure project directory "${cwd}": ${String(error)}`, { cause: error })
}

cwd 来自目标 Workspace 路径 —— packages/api/session-controller/src/commands.ts:118：

const cwd = workspace?.path ?? request.cwd ?? this.defaultCwd

2. Host 侧其实正确上报了 —— commands.ts:119-142，以及rejectCreation（commands.ts:534-556），其结尾是：

throw new RemoteError('gateway/internal', `failed to create session "${sessionId}": ${String(error)}`, {})

所以诊断信息是完整送达客户端的。这不是 Host 吞错误的问题。

3. Web 客户端把它丢了 —— @deepseek-ai/dsh-client-ui-conversation，「新建会话」主视觉区的工作区选择器（0.1.5-rc.2 发布版 lib/client.js:14890-14896）：

onPick: (workspaceId) => {
  setPickerOpen(false)
  setPendingWorkspaceId(workspaceId)                  // 乐观地先显示
  selectWorkspace(workspaceId).catch(() => {
    setPendingWorkspaceId((current) => current === workspaceId ? undefined : current) // 静默还原
  })
}

调用链：selectWorkspace → @deepseek-ai/dsh-client-ui-workspace 的 openWorkspace（lib/client.js:65-72）→ connectWorkspace → sessions.create({ workspaceId })。

为什么这个 bug 特别难排查

• 表面症状（「选工作区没反应」）看起来像导航/状态 bug，不像文件系统 bug。
• rejection 被丢弃时没有 console.warn，所以 DevTools 里什么都看不到；而 Desktop 的「导出诊断」只覆盖 Host 日志和启动事件，不含渲染层输出。
• Workspace 本身创建是成功的，所以工作区列表看起来完全健康。

影响版本

• 0.1.5-rc.2（DSH Desktop 2.0.10 / 2.0.11 / 2.0.12 / 2.0.13 均内置）—— 通过阅读安装产物并实测复现确认。
• 已发布的 @deepseek-ai/dsh-api-session-controller@0.1.7-rc.1 tarball 里同样存在（同一个无保护的调用），所以最新发布线上也没修。
• 0.1.5-rc.3 与 0.1.5-rc.2 在客户端侧功能等价（只有构建路径和 CSS 哈希差异），升级无济于事。

影响范围：所有规范化路径为 Windows 卷根的 Workspace，在每一台 Windows 主机上。

建议修法

1. Host（主要）。 让「确保目录存在」这一步容忍目录已存在：

   try {
   await mkdir(cwd, { recursive: true })
   } catch (error) {
   const usable = await stat(cwd).then((entry) => entry.isDirectory(), () => false)
   if (!usable) {
   throw new Error(failed to ensure project directory "${cwd}": ${String(error)}, { cause: error })
   }
   }

（stat 从 node:fs/promises 引入即可，无需新依赖。）等价做法：先用 stat 判断已是目录就跳过 mkdir。

2. 客户端。 不要丢弃这个 rejection。保留原选择的同时把原因呈现出来（toast 或行内状态）；至少 console.warn 一下，让失败可诊断。

3. 产品决策（可选）。 明确卷根是否允许作为 Workspace 路径。若允许，补一个覆盖 C:\ 的 Windows 测试；若不允许，就在创建工作区时用清晰的提示直接拒绝，而不是先接受记录、等到建会话时才失败。

附注

• @deepseek-ai/dsh-workspace 的 attachSession 校验（packages/workspace/workspace，判定 realpathNormalize(header.cwd) === record.path）对盘根路径是完全接受的 —— 整条链路上只有 session-controller 里那个 mkdir 拒绝它。这正是这个失败从外面看显得莫名其妙的原因。
• 报告中的个人路径均为通用示例，不含凭据或会话内容。

[luoyukun3-oss]

独立复现了你的结论 ✓ 本机 Windows 11 + Node v24.9.0（系统 node，不是 DSH 内置运行时）：

await fs.mkdir('C:\\', { recursive: true })          // EPERM: operation not permitted, mkdir 'C:\'
await fs.mkdir('E:\\', { recursive: true })          // EPERM（另一个卷根，同样）
await fs.mkdir('C:\\Windows', { recursive: true })   // 正常
await fs.mkdir('E:\\2', { recursive: true })         // 正常

⇒ 确认是 Node 在 Windows 对卷根的行为，与 DSH 无关。你的链路定位（createOrAdopt 无条件 mkdir → 卷根抛 EPERM → 客户端把 rejection 静默丢掉）成立。

补两条可能省事的：

1. 不必动 createOrAdopt 的整体逻辑 —— mkdir 前判一下卷根即可（path.parse(p).root === p 就跳过，或先 stat 再决定）。
2. 客户端那个「静默丢 rejection」其实比 EPERM 更值得修：任何工作区创建失败都会表现成「选中后自己跳回去」，用户拿不到任何线索。

顺带提醒后来者：工作区决定 cwd 与沙箱/审批作用域，选 C:\ 等于把整盘纳入范围。想清 C 盘建议注册某个子目录，或者干脆交给资源管理器。