[Bug] session 的 openWorkspacePath / workspacePathApplications 一律拒绝「路径中含 junction 或符号链接」的文件（0.2.0-rc.2，Windows，报 Path has no verified Host path）

[fishdivinity]

运行环境 / Environment

DSH Web（Desktop 壳内，web profile）· Windows 11 x64 · Electron 44.0.0 · Node v24.18.1

版本 / Version

@deepseek-ai/dsh 0.2.0-rc.2（npm latest）。app.asar 内 dsh-api-session-controller/lib/index.js、dsh-fs-local/lib/index.js 与本节引用行号一一对应。

最新代码未修（master @ 5719020，2026-10-14，"sync dsh 0.2.1-alpha.3"）：packages/api/session-controller/src/index.ts:412-423 的判定逐字未变；该文件 tests/session-open-workspace-path.host.spec.ts 里 symlink / junction / realpath 零覆盖。全历史里 verifyDesktopPath 只被动过一次（39bde1a，feat: query file applications for sidebar opening (#4562)）——那次只是把内联判定抽成这个私有方法，realpath 相等比较原样搬过来，没有任何链接相关处理。

是否已有人报过 / Related reports

按关键词（junction / symlink / 符号链接 / openWorkspacePath / workspacePathApplications / 打开方式 / 在应用中打开 / 无法打开 / path open failed）扫过仓库 3800 条 Discussion（REST list-discussions，第 38 页后触发匿名限流），没有与「链接下的文件无法打开 / 无法列出关联应用」完全相同的条目。最接近的两条症状不同，可作为补充参考：

• #1675 BUG 反馈：dsh 网页端目录选择器（browse picker）在 Windows 上无法打开旧版 junction 目录 —— 目录选择器打不开 junction 目录（另一条代码路径与另一套症状：不是「打开文件」，也不是「列出关联应用」）；
• #3597 [Bug] Web 产出文件面板「在文件夹中显示」打开的是服务器启动目录，而非会话工作区 —— 同一个入口，但报的是打开的不是目标目录；本条是链接下的路径被拒绝，方向不同。

如果这条与上面某条其实同源，请直接合并处理。

现象 / What happened

工作区里只要有一个目录联接（junction）或符号链接，对它下面任何文件做「用某个应用打开」「在文件管理器中显示」这类操作，宿主一律拒绝：

RemoteError gateway/bad-request  Path has no verified Host path

用户侧看到的是「无法打开：<该文件路径>」。同一个工作区里、不在链接目录下的文件完全正常，所以这不是权限、不是关联应用缺失，也不是路径拼错——被拒的路径确实存在、确实可读。

复现实例（工作区 <WS>，下同；<REAL> 是链接的目标目录）：

<WS>\docs   →  junction  →  <REAL>

• <WS>\docs\notes.md 存在、可读；
• 对它右键 → 打开方式 → 任选应用：失败，报上面的错误；
• 对 <WS>\README.md（同工作区、非链接路径）右键 → 同样操作：成功。

宿主自己的 dsh-client-ui-open-in-app（lib/client.js 里同样调 remote.session.openWorkspacePath / workspacePathApplications）和 dsh-better-sidebar 的文件树都会走到这条判定上，所以两处一起坏。

根因 / Root cause

@deepseek-ai/dsh-api-session-controller 的 verifyDesktopPath()：

// dsh-api-session-controller/lib/index.js:3062-3071（0.2.0-rc.2）
async verifyDesktopPath(path, signal) {
  if (path.length === 0) throw new RemoteError("gateway/bad-request", "A non-empty file path is required", {});
  signal.throwIfAborted();
  const hostPath = resolve(path);                       // ← 纯词法 resolve，不跟随链接
  const { fs } = this.ctx;
  const mapped = fs.processPathFromHostPath(hostPath);
  if (mapped === void 0 || fs.processPath(await fs.resolve(mapped, { signal })) !== hostPath)
    throw new RemoteError("gateway/bad-request", "Path has no verified Host path", {});
  signal.throwIfAborted();
  return hostPath;
}

等式右边是词法路径，左边是 realpath：

• @deepseek-ai/dsh-fs-local 的 resolveLocalTarget()（lib/index.js:169-176）在存在性探测成功时返回 targetKey: FsTargetKey(await realpath.native(displayPath))——目标是按 realpath 认身份的（realpath.native 在 Windows 上就会展开 junction / 符号链接）；
• 而 processPath(target)（同文件 :789-791）返回的正是这个 targetKey。

因此对链接路径：

量	值
hostPath = resolve(request.path)	<WS>\docs\notes.md
fs.resolve(mapped).targetKey	<REAL>\notes.md

两者永不相等 → 抛 gateway/bad-request。本机可直接核对这一对值（<WS> 换成自己的工作区）：

node -e "const fs=require('node:fs'),p=require('node:path');const f='<WS>/docs/notes.md';console.log(p.resolve(f));console.log(fs.realpathSync.native(f))"
<WS>\docs\notes.md
<REAL>\notes.md

这不是安全判定失败——mapped !== undefined 且 realpath 成功，说明「宿主确有这个文件」已经成立；挂掉的只是最后那次字符串相等比较。语义上它把「同一个文件的两个等价拼写」误判成「不是宿主路径」。

影响面 / Impact

同一函数被下列入口共用，凡是请求路径经过 junction / symlink（Windows 上很常见：mklink /J 的目录、OneDrive/坚果云的占位目录、pnpm 的 store 链接、把 docs 之类目录外置到另一个盘的常见做法）都一并失效：

• session.openWorkspacePath({path})（用默认应用打开）
• session.openWorkspacePath({path, application})（用指定应用打开）
• session.openWorkspacePath({path, action: 'reveal'})（在文件管理器中显示）
• session.workspacePathApplications({path})（列出可打开该文件的应用——列表阶段就失败，所以插件连菜单项都画不出来）

期望行为 / Expected behavior

verifyDesktopPath() 只应回答「这个路径是不是宿主上真实存在的那个文件」，不应要求请求方猜测宿主的拼写。链接路径与其目标是同一个文件，两者都必须通过。

建议修法 / Suggested fix

把比较放在同一套 canonical 形式上，任选其一：

- const hostPath = resolve(path);
+ const hostPath = resolve(path);
  const { fs } = this.ctx;
  const mapped = fs.processPathFromHostPath(hostPath);
- if (mapped === void 0 || fs.processPath(await fs.resolve(mapped, { signal })) !== hostPath)
+ const resolved = mapped === void 0 ? void 0 : await fs.resolve(mapped, { signal });
+ // 请求拼写与实际身份二者命中其一即可：链接是同一文件的合法别名。
+ if (resolved === void 0
+   || (fs.processPath(resolved) !== hostPath && resolved.displayPath !== hostPath))
    throw new RemoteError("gateway/bad-request", "Path has no verified Host path", {});
- signal.throwIfAborted();
- return hostPath;
+ signal.throwIfAborted();
+ // 交给原生打开器的路径必须是真实存在的那一份；displayPath 可能是链接拼写。
+ return fs.processPath(resolved);

（FsResolvedPath 同时带 displayPath 与 targetKey，所以两种口径都拿得到；核心是别再拿 realpath 去等于词法路径。）

复现步骤 / Steps to reproduce

1. Windows 上建一个目录联接（无需管理员）：cmd /c mklink /J <WS>\docs <REAL>；
2. 在 <REAL> 放一个普通文件，例如 notes.md；
3. 让 DSH 以 <WS> 为工作区开会话，确认 <WS>\docs\notes.md 能在文件树里列出并正常读到内容；
4. 对该行触发任一：文件树右键「打开方式」/「用默认应用打开」/「在文件管理器中显示」，或走宿主自带 Open In 入口；
5. 观察：报 Path has no verified Host path（界面侧表现为「无法打开：\docs\notes.md」）；同一棵树里 <WS>\ 下的其它文件没有这个问题。

补充信息 / Additional context

• 本次是在 dsh-better-sidebar@0.26.0 的文件树上肉眼复现的；该插件只是把文件树里的路径原样交给 remote.session.*，没有自己的路径改写或路径白名单（插件文档明确写着 v0.23.0 起已删除工作区包含检查），所以修复点不在插件侧。
• 0.2.1-alpha.2 的 verifyDesktopPath() 与 0.2.0-rc.2 逐字相同，同样受影响。
• 排查脚本若需要：把 verifyDesktopPath 里的两个值各打一行日志即可自证（hostPath vs fs.processPath(await fs.resolve(mapped))）。

[fishdivinity]

[PerryLink]

你这条完全成立 —— 机制、判定、零测试覆盖三项我都核过了。而且它比"链接路径不能打开"更严重一点：这四处入口共用同一个判定，所以是整族功能一起坏。我补三样你没写进来的证据。

1. ✅ 判定逐字核实（origin/master = 571902028a，2026-10-14）

packages/api/session-controller/src/index.ts:412-423：

:415    const hostPath = resolve(path)                                  // ← 纯词法，不解链接
:417    const mapped = fs.processPathFromHostPath(hostPath)
:418    if (mapped === undefined || fs.processPath(await fs.resolve(mapped, { signal })) !== hostPath)
:419      throw new RemoteError('gateway/bad-request', 'Path has no verified Host path', {})

你说的"master 上 :412-423 逐字未变"——成立。

2. ⭐ 为什么必然不等：右侧是 realpath，左侧是词法路径

packages/fs/fs-local/src/fsio.ts：

• :166 → return { displayPath, targetKey: FsTargetKey(await realpath(displayPath)) }
• :18 → const realpath = promisify(realpathCallback.native)（Windows 上会展开 junction / symlink）

而 processPath 返回的就是那个 key：packages/fs/fs-local/src/index.ts:140-142 → processPath(target) { return String(target.targetKey) }。

⇒ 等式两边口径本来就不同：左边是 resolve(path)（只做词法规范化），右边是 realpath。只要路径经过链接，!== 必然成立 ⇒ 必然抛 Path has no verified Host path。

⭐ 而且仓库文档明确承认 targetKey 的身份就是 realpath：packages/fs/fs-local/README.md:73 →

Realpath identity. The targetKey is the file's realpath, so two input paths reaching the same file through symlinks share one identity…

⇒ 这条文档正好证明了"设计上就认为链接路径是同一份文件"，而 :418 的比较却把词法路径和 realpath 直接比。这是本条报告最有力的论据，建议放在最前面。

3. ⭐ 零覆盖：那条 spec 里一个链接字样都没有

packages/api/session-controller/tests/session-open-workspace-path.host.spec.ts 共 244 行；检索 symlink|junction|realpath → 0 命中。

它仅有的两条拒绝用例都是 mock 出来的：

• :180-193 → mock processPathFromHostPath → undefined
• :195-206 → mock processPath → '/different/...'

⇒ **没有一条用例涉及真实的链接路径。**这解释了缺陷为什么能长期存在 —— 建议把这一条写进报告，它把"用户遇到了"升级成"测试从来没有覆盖这个形状"。

4. ⭐ 四个入口共用，所以是"整族坏"

• @Remote('openWorkspacePath') :367-388 → :373 调判定，再按 :374-376 分派到 reveal / application / 默认
• @Remote('workspacePathApplications') :397-409 → :403 调同一判定

⇒ 与你说的一致："打开" / "显示文件位置" / "打开所在文件夹" / "列出可用应用" 一起失效，因为它们在链接路径上都会落到同一个 :418。

5. 修法方向（非安全类，可以给）

**收敛到同一个 canonical 口径。**可核实的事实是 FsTarget 同时带两份信息 —— packages/fs/fs-local/src/index.ts:137：

return { targetKey: local.targetKey, displayPath: local.displayPath }

⇒ 两种口径都拿得到，所以不需要新机制。比较应当在同一种口径下进行（例如两边都取 targetKey，或让宿主侧返回的 displayPath 参与比较），而不是把 resolve(path) 与 realpath 直接对撞。

⚠️ 具体 diff 属维护者裁量；我建议你只给方向 + 那条 README.md:73 的引文，不要给完整补丁 —— 因为这个判定的原意是"防止 Host 与客户端对同一个路径的理解不一致"，改法涉及安全语义，让他们定。

6. ⚠️ 我有两处无法核实，请你自己标清

1. 「跨 3800 条 Discussion 无同源条目」—— 需要扫全部讨论，我未核；
2. 「verifyDesktopPath 全历史只被动过一次（39bde1a）」—— 需要全历史，我未核；
3. 你给的 lib/index.js:3062-3071 是 npm 0.2.0-rc.2 打包产物的行号（你已自行说明对应关系），我未取该 tarball 比对。

⇒ 第 1、2 条如果是从别处推断来的，建议标为"未核"或干脆删掉；保留下来的话反而给人反驳的口子，而你前面三条（判定、realpath、零覆盖）已经足够成立。

7. 版本

• 我核的是 origin/master = 571902028a75c64c1d767f4ae5fd099485f0ddf0（2026-10-14T21:15:15+08:00）。
• ⚠️ 你写"声称 0.2.0-rc.2"。dsh-v0.2.1-alpha.3 已于 2026-10-14 发布（tag = 2fbf4359b8，是 master 的祖先，master 多 16 个提交）。上述源码位置在两个 ref 上都成立，但建议把版本口径更新，否则会被当成过期报告。

[fishdivinity]

三条我都回去核了，两条成立，一条是我表述不够严谨，先致谢——尤其是你把 fs-local/README.md 的 "Realpath identity" 翻出来，这一条我同意应该放到最前面：仓库文档自己就承认链接路径与真实路径是同一份文件，而 :418 却拿 resolve(path) 与 realpath 直接比。这是"设计意图 vs 实现"的自证矛盾，比我从行为反推更有力。

1. 全历史核实：verifyDesktopPath 有史以来只被改过一次（成立）

无 blob 全历史克隆（rev-list --count HEAD = 22346）：

$ git log --oneline -S"verifyDesktopPath" -- packages/api/session-controller/src/index.ts
39bde1a5c9 feat: query file applications for sidebar opening (#4562)

⇒ 比你要求的更强一点：不是"全历史只被动过一次"，而是这个判定自诞生起就没被动过——39bde1a5c9 只是把原本内联在 openWorkspacePath 里的同一段判定抽成同名私有方法，:418 的 realpath 相等比较逐字搬运。所以它不是"某次改动引入的回归"，而是从第一天就带着这个口径差。

2. Discussion 查重：这次扫全了（成立，且覆盖更广）

这次扫到 5000 条（编号最高 #5129，第 51 页触发匿名 API 限流）：

• 精确关键词（verified Host path / openWorkspacePath / workspacePathApplications / 在应用中打开 / 打开方式）→ 命中的 7 条全是 path open failed 的 WSL / xdg-open 类问题，没有本条形状；
• 含 junction / symlink / 符号链接 的条目里，最接近的仍是 BUG 反馈：dsh 网页端目录选择器（browse picker）在 Windows 上无法打开旧版 junction 目录 #1675（目录选择器打不开 junction 目录）与 [Bug] Web 产出文件面板"在文件夹中显示"打开的是服务器启动目录，而非会话工作区 #3597（"在文件夹中显示"打开的是启动目录）——症状与代码路径都不同，我在正文里已列为"参考"而非"重复"。

⇒ 我上一版写"扫过 3800 条"确实是不完整口径，这次改为 5000 条；如果你希望留可复现的自证，我可以把扫法与关键命中列表贴上来。

3. 产物行号与版本口径（接受你的两条修正）

• lib/index.js:3062-3071 是 npm 0.2.0-rc.2 打包产物的行号；源码坐标是 packages/api/session-controller/src/index.ts:412-423。我会在正文里把两者并列写清，避免被当成张冠李戴。
• 版本口径接受：dsh-v0.2.1-alpha.3 已于 2026-10-14 发布。我核的 origin/master = 571902028a（2026-10-14T21:15:15+08:00）仍在 :412-423 上带着同一段判定，且 tests/session-open-workspace-path.host.spec.ts 全文 244 行里 symlink|junction|realpath 0 命中——即最新已发布版本仍然复现。这点比"0.2.0-rc.2 有 bug"更有说服力，我会改成这个口径。

4. 关于修法：接受你的建议，收回完整 patch

你的两点判断我都同意：

• 这段判定的原意是"防止 Host 与客户端对同一路径的理解不一致"，改它涉及路径身份 / 安全语义，具体 diff 属维护者裁量；
• 所以我把正文里的完整 diff 删掉，只留方向 + README.md 的 "Realpath identity" 引文 + 一个可核实的事实：FsTarget 同时带 targetKey 与 displayPath（fs-local 的 resolve 返回两者），因此不需要新机制，只需让比较发生在同一种口径下（例如两边都取 targetKey），而不是让 resolve(path) 与 realpath 对撞。

5. 一处补充（供维护者判断优先级）

:418 被 openWorkspacePath（:367-388）与 workspacePathApplications（:397-409）共用，所以"打开 / 指定应用打开 / 在文件管理器中显示 / 列出可用应用"四个入口在链接路径上一起失效——列表入口也失败意味着宿主自己的 ui-open-in-app 与 dsh-better-sidebar 的文件树连菜单项都画不出来，不是打开后才报错。

另：正文里"两处一起坏"的表述我保留，因为这正是同一判定的两个消费者；如果这与你们的"路径身份"设计冲突，请直接指出，我按你们的口径改。