[Feature] 右侧 Sidebar 文件树缺少「在资源管理器中显示」（主机侧能力已就绪，仅客户端未接）

[misstarn]

版本：dsh 0.1.5-rc.1 ｜ 环境：Windows 11 + Web GUI (http://127.0.0.1:3080) ｜ 提出日期：2026-09-10

摘要

右侧 Sidebar 的文件树（@deepseek-ai/dsh-client-ui-sidebar-files）目前是纯浏览：左键把文件打开到 Sidebar 内部的预览，此外没有任何"把文件交回本地"的入口。

而同一个工作区里的交付物面板（@deepseek-ai/dsh-client-ui-deliverables）已经完整支持"在文件管理器中显示 / 用默认应用打开"。

结果很反直觉：AI 产出的文件能一键定位到本地，用户自己在树里翻到的文件反而不能。 对日常在编辑器/资源管理器里干活的人来说，文件树找不到"到本地去"的路，这个树就只完成了一半功能。

复现步骤

1. 打开右侧 Sidebar → 文件 tab（工作区根目录已渲染成树）
2. 展开任意目录，看到一个文件
3. 尝试右键 —— 无任何菜单
4. 悬停 —— 无任何操作按钮
5. 左键 —— 文件在 Sidebar 内打开预览（行为正确，但不是本需求要的）

期望：能右键（或悬停）选择「在资源管理器中显示」/「用默认应用打开」。

现状（代码依据）

文件树没有行级操作入口

dsh-client-ui-sidebar-files/README.zh.md 的「已知限制与暂缓事项」明确写着：

只有列目录。 没有搜索、产物过滤、拖拽、重命名、右键菜单、当前文件高亮或文件系统监听；一层只会因重新读取而变化。

该包只注册了两个坑位：sidebar.right.pane.tab（正文）与 sidebar.right.pane.tab.title（标题）。没有任何行级（row-level）坑位，也就是说第三方插件无法往树的行上注入操作——这决定了它必须是一次核心改动，而不是扩展包能解决的。

行类型只有三种（同上 README）：

条目类型	当前行为
directory	切换展开/折叠
file	经 useTabInfo().tab.actions.openResource 打开 dsh-resource://file/session/<sessionId>/<encoded 相对路径>
other	灰显不可点

但主机侧能力已经齐了

@deepseek-ai/dsh-api-session-controller 已经暴露了 Remote 方法（lib/index.js 约 2886 行）：

async openWorkspacePath(request, signal) {
  if (request.path.length === 0) throw new RemoteError("gateway/bad-request", ...);
  signal.throwIfAborted();
  if (request.action === "reveal") await this.revealPath(request.path, signal);
  else await this.openPath(request.path, signal);
  return { opened: true };
}

配套的能力探测（同文件约 2871 行）：

workspaceDesktop() {
  const fileManager = nativeFileManager();
  return { name: hostname(), available: fileManager !== null && this.canOpenPath(), fileManager };
  // fileManager: 'finder' | 'explorer' | 'directory' | null
}

也就是说 Windows 上的"在资源管理器中显示"这条路，主机早就通了。 缺的只是客户端的一颗按钮/一条菜单项。

交付物面板就是现成的参照实现

dsh-client-ui-deliverables/lib/index.js（约 33–104 行）已经跑通了完整链路，可直接照搬：

1. registerPresentOpen(ctx) 用 ctx.connection.fetch.register 在鉴权栅栏内注册两条路由：
   • GET PRESENT_HOST_PATH → 返回 ctx.sessionController.workspaceDesktop()（含 available 与 fileManager，cache-control: no-store）
   • POST PRESENT_OPEN_PATH → 接受 action=open|reveal
2. handlePresentOpen 的关键三步：
   • 可用性闸门：if (!ctx.sessionController.workspaceDesktop().available) return 409
   • 把逻辑路径解析成绝对路径：workspaceFiles.stat({ sessionId, workspaceRoot: session.cwd }, file.path)
   • 宿主路径校验（安全关键）：

     const mapped = fs.processPathFromHostPath(path);
     if (mapped === undefined || fs.processPath(await fs.resolve(mapped, { signal })) !== path) return 422;

   • 通过后才 openWorkspacePath({ path, ...(action === "reveal" ? { action } : {}) }, signal)

期望行为

在文件树的行上（file 与 directory 都算）提供：

• 在资源管理器中显示 —— action: "reveal"
• 用默认应用打开 —— 不带 action
• 复制路径（可选，但对开发者很实用）

UI 形式建议二选一（或都做）：

• 右键菜单：最符合文件树的心智模型，Windows 用户下意识就会右键
• 悬停按钮：行尾出现一个"⋯"或"↗"图标，触达成本更低、更好发现

实现建议

最小可用范围（建议先做这个）

1. dsh-client-ui-sidebar-files 的 FilesBody.tsx 给行加右键菜单，仅 file 类型
2. 复用已有的 session.openWorkspacePath Remote，不必新开路由
3. 挂载时读一次 workspaceDesktop().available，为 false 时完全不渲染入口（不能只置灰）
4. 沿用交付物面板那套宿主路径校验，不要把 openResource 用的相对路径直接拼成绝对路径丢给主机

完整范围（后续）

• directory 行也支持 reveal（揭示所在文件夹本身）
• 行内选中态 + 键盘导航
• 与文件系统监听/自动刷新一起做（README 把这两个也列为延后项）

边界情况与注意事项

• SSH / 远端部署必须隐藏入口。 dsh-host-open-in-app 的 README 说明：SSH_CONNECTION 或 SSH_TTY 非空时应用列表为空，头部隐藏 Open In。文件树的入口应遵循同一规则，否则点了没有任何反应，比没有更糟。
• 路径必须过宿主校验。 树里的路径来自 workspaceFiles.list，但直接透传给原生启动器会有风险；交付物面板那段 round-trip 校验（processPathFromHostPath → fs.resolve → fs.processPath 比对）是现成的正确做法。
• action 的取值要在 wire 边界校验，非法值返回 400（交付物面板已这么做）。
• 不要为这件事新造一套启动器解析。 dsh-host-open-in-app 已经维护了"编辑器 / Git GUI / 终端 / 文件管理器"的固定目录与逐平台已验证启动器；文件树如果自己 shell.open 会绕开这套已验证链路，也会丢掉图标与可用性探测。
• Windows 上的"揭示"语义要注意：资源管理器定位并选中文件是 explorer.exe /select,"<path>"，而不是打开父目录。交付物面板既然已经在 Windows 上跑通 reveal，直接复用它的实现即可。

为什么这不能做成第三方插件

文件树的行由 FilesBody.tsx 内部渲染，该包只对外暴露 tab 级坑位（sidebar.right.pane.tab / ...tab.title），没有行级扩展点。因此在现有架构下，任何外部插件都无法给树的行加右键菜单——要么核心改，要么先补一个行级 slot。后者更符合 DSH 的插件化取向，也能顺带让"选中态""键盘导航"这些延后项有地方落脚。

附：一句话版本

右侧文件树缺一个「在资源管理器中显示」。主机侧 session.openWorkspacePath({ action: "reveal" }) 和 workspaceDesktop() 都已就绪，交付物面板也已完整实现同样的功能，唯独文件树没接——建议给树的行加个右键菜单，复用同一套 Remote 与宿主路径校验。

---

本 issue 的代码定位（包名、文件、行号）由 DSH 会话中的 AI 助手整理，人工复核后提交。