反馈报告：Web GUI 文件链接（产物行 / 行内代码）点击无任何反馈，表现为「死链接」

[hcli0228]

环境

• DSH：@deepseek-ai/dsh@0.1.0-rc.6（npm 安装版，非源码 checkout）
• 宿主：Windows（沙箱化受限环境），Web GUI 走 loopback（http://127.0.0.1:3080）
• 复现对象：会话中「产物」（ProducedFiles）行内的文件 chip，以及收尾正文中解析出的行内代码文件引用

复现步骤

1. 让智能体用 write 工具创建一个文件（如 maze.py），工具结果成功。
2. 会话收尾后，聊天中出现「产物」行，含 maze.py chip（样式为可点击按钮：hover 下划线、cursor: pointer）。
3. 在浏览器里点击该 chip（或正文中解析为链接的 `maze.py`）。
4. 浏览器内没有任何反应：不跳转、不预览、不报错、不打开文件夹。

期望 vs 实际

• 期望：点击后至少有三种之一——在 Web 内预览/跳转到文件；在宿主机桌面用默认程序打开；或给出明确反馈（如「已在桌面打开」「无法打开：原因」）。
• 实际：点击静默调用宿主机的原生打开器；失败时错误被完全吞掉，用户端零反馈，链接表现为「死链接」，用户会怀疑「这不是一个链接」。

根因分析（依据已安装包代码，逐层追踪）

1. 点击链路：Web 内没有「跳转」，只有宿主机原生打开器

• 聊天视图 openFile：dsh-client-ui-conversation/lib/client.js:9731-9733

  openFile: (path) => {
      workspaces.openPath(resolveWorkspacePath(cwd, path)).catch(() => {});
  }

• 客户端 RPC：dsh-client-runtime/lib/client.js:9993-9996（错误会 throw，但被上层吞掉）

• 宿主端点：dsh-host-apiproxy/lib/index.js:3260-3262 → openPath() (2364-2366) → openNativePath → Windows 分支 openWindowsPath (792-798)：

  await run("powershell.exe", ["-NoProfile", "-Command", `Invoke-Item -LiteralPath ${powershellLiteral(path)}`], signal);

  即点击只做一件事：在宿主机桌面用默认程序打开该文件。浏览器内没有预览、没有工作区跳转、没有 reveal。

2. 失败被静默吞掉（关键问题）

• 宿主原生打开失败（例如：宿主环境 PATH 中无 powershell.exe、无交互桌面/会话 0、沙箱拒绝派生子进程、Invoke-Item 本身失败）时，RPC 返回错误 → 客户端 workspaces.openPath 抛 Error（9995 行）→ 但聊天视图 openFile 用 .catch(() => {}) 静默吞掉（9733 行）。
• 结果：任何失败对用户都是「点击了但什么都没发生」。

3. Windows 的可用性探测过于乐观

• canOpenNativePath()（dsh-host-apiproxy/lib/index.js:843-849）对 win32 无条件返回 true，不检测是否存在可用交互桌面、powershell.exe 是否可执行、子进程派生是否被沙箱允许。
• 本环境实测：沙箱化 shell 中 powershell.exe 根本不在 PATH 中（CommandNotFoundException）——说明受限 Windows 环境是现实存在的，而握手仍会报告 canOpenPath: true。
• 「在文件夹中显示」按钮的显隐由 isLoopback && hostCanOpenPath 控制（dsh-client-ui-deliverables/lib/client.js:216-217），它信任同一个乐观探测。

4. 附注（非 bug，供参考）

• 行内代码提及的解析逻辑本身正确：producedFileMentions（dsh-client-ui-deliverables/lib/client.js:140-157）按「精确路径或唯一 basename」解析，basename 同时处理 / 与 \（124-127 行），Windows 路径无匹配问题；写入工具也会上报 locations（dsh-tool-fs/lib/index.js:685 等）。所以本报告不涉及提及解析，只涉及「点击后的行为与反馈」。

建议修复方向（供维护者取舍）

1. 失败可见化：openFile 不再吞错——失败时在 Web UI 显示提示（toast/inline error），例如「无法在宿主打开 D:\...\maze.py：<原因>」。这是最小改动，收益最大。
2. Web 内兜底：为文件 chip 增加浏览器内行为（如在工作区面板中定位/高亮该文件、或只读预览），让「点击」在无桌面环境时仍有意义。
3. 探测更严格：Windows 上也应探测 powershell.exe 可执行性与交互会话可用性（如 Get-Process explorer / session id），或让 openPath 的失败结果通过 RPC 返回并在 UI 展示，避免「报告可用但实际不可用」。
4. 行为说明：若「点击 = 桌面打开」是有意设计，建议在 UI 上明示（如 tooltip「在宿主桌面打开」），避免用户预期错位。

附：精确代码位置清单（npm 包 0.1.0-rc.6）

环节	位置
UI 点击处理 + 吞错	dsh-client-ui-conversation/lib/client.js:9731-9733
客户端 RPC 抛错	dsh-client-runtime/lib/client.js:9993-9996
路径解析	dsh-client-runtime/lib/client.js:10302-10306
宿主 openPath 端点	dsh-host-apiproxy/lib/index.js:3260-3262
原生打开（Windows）	dsh-host-apiproxy/lib/index.js:792-798, 2364-2366
canOpenPath 探测（win32 恒真）	dsh-host-apiproxy/lib/index.js:843-849
产物行 + Show in folder 门控	dsh-client-ui-deliverables/lib/client.js:216-217
提及解析器（正常，无需修改）	dsh-client-ui-deliverables/lib/client.js:140-157

[NekoDD-wow]

补充一条同类且更具体的复现，可能与本条同源：

➡️ #7099 从聊天引用点开文件时右侧预览失败：fs-error "… is not an absolute path"

对照现象

入口	结果
💬 聊天中的文件引用	❌ 预览失败（破图）
📁 右侧 Files 文件树	✅ 正常

同一个文件、同一个路径，仅入口不同。

实际报错

{"ok":false,"error":{"code":"fs-error",
  "message":"\"拖拽动图/1.png\" is not an absolute path"}}

定位（简要）

packages/client/ui-chat/src/client/apply.ts → openFile：

const cwd = ctx.sessions.list.getSnapshot().byId[sessionId]?.cwd
const url = fileAddressFor(sessionId, cwd, path)

fileAddressFor 在 cwd 已知时会剥掉工作区根，地址里只保留相对路径；
服务端 WorkspaceFiles.locateFile() 用 fs.resolve(path, { cwd: workspaceRoot })
解析失败 → fs-error: "<path>" is not an absolute path。

而 Files 文件树入口产生的是绝对路径，所以不受影响。

建议修复

• 最小改动：apply.ts 改为 fileAddressFor(sessionId, undefined, path)
• 更根本：让 WorkspaceFiles.locateFile() 正确使用 workspaceFileScope.workspaceRoot 解析相对路径

完整分析、复现步骤与临时绕过方案见 ➡️ #7099