[Bug] [Windows] 「显示文件位置」不打开文件夹、按钮变灰后再也无法点击：explorer.exe 子进程等待没有超时（0.2.0-rc.2）

[Hrainy1]

提交说明：本报告由 DSH 桌面版（0.2.0-rc.2）自身在我与用户的会话中排查并整理，经用户确认后由其账号提交。文中用户名 / 主机名 / 安装路径 / 真实业务文件路径 / 会话 ID 均已脱敏。

0. English summary

On Windows, the "Show file location" (path.reveal) action can permanently lock its button with no error message and no way to retry.

Chain: renderer gesture (dsh-client-ui-open-in-app) → session remote openWorkspacePath (dsh-api-session-controller) → revealNativePath (dsh-native-command) → execFile('explorer.exe', ['/select,', <file:/// URI>]).

execFile is called without a timeout option and without any abort signal, so the promise settles only when the child process exits. If the Windows shell stalls while handling a path argument, explorer.exe never exits → the promise never settles → the client's pending flag never clears → the button stays disabled forever. There is no timeout anywhere on this path, while sibling packages in the same repository (dsh-host-open-in-app, dsh-workspace-changes, dsh-api-workspace-controller) all use AbortSignal.timeout(...) or a watchMs window for exactly this reason.

Observed on one machine: the same command hung 182 s with 0 windows before an OS reboot, and completed in ~660 ms opening the correct folder after the reboot (same DSH build, no DSH change). The stall is shell-side and reproducible machine-wide (also from a scheduled task outside DSH's process tree), but DSH turns a transient shell hiccup into a permanently dead button.

Requested fix: a wall-clock bound on this wait (translate a timeout into a normal path.revealError toast and reset the button), plus passing a signal from the client RPC.

1. 环境

项	值
DSH Desktop	0.2.0-rc.2（build commit 04f392c9ddd144fa426da2045178797da6db6c11）
安装方式	官方 Windows 桌面版（Electron 外壳 + app.asar 打包的 dsh runtime）
操作系统	Windows 11 专业版 24H2，10.0.26100.9445，x64
会话类型	单交互会话（console / Session 1 / Active），非 RDP 多会话、非无桌面服务会话
涉及包	dsh-client-ui-open-in-app、dsh-api-session-controller、dsh-native-command、dsh-client-ui-deliverables（均 0.2.0-rc.2）

其他说明（可能相关，不作为结论）：出问题那次系统已连续开机约 17.5 小时，explorer.exe 自开机后未重启过；系统中注册了若干第三方外壳扩展（HKCR\Directory\shell 下的自定义动词），且 HKCU\...\Policies\Explorer\EnableShellExecuteHooks = 1。

2. 症状（三步复现）

1. 在与 Agent 的会话中，让 Agent 产出/修改某个文件（Windows 上的普通文件，例如 .docx）。
2. 在该文件的交付卡片或文件菜单里点击 「显示文件位置」（英文 UI：Show file location）。
3. 观察结果。

实际结果（三个症状同时出现）：

• 文件夹不打开：没有任何资源管理器窗口出现，目标文件夹没被打开、目标文件没被选中。
• 点击后无反应：没有任何错误提示、没有任何 toast、界面没有其它变化（不是"报错"，是"什么都没发生"）。
• 按钮变灰且无法再次点击：按钮进入灰态（data-state="busy"），此后一直灰色，反复点击无效；只能重新加载/重启整个 DSH 窗口才能恢复。

期望结果：打开资源管理器并选中该文件；或失败时给出「无法显示文件位置，请重试」，并让按钮回到可点击状态。

3. 代码路径与关键行（0.2.0-rc.2，均为 app.asar 内路径）

渲染层   dsh/node_modules/@deepseek-ai/dsh-client-ui-open-in-app/lib/client.js
宿主 RPC dsh/node_modules/@deepseek-ai/dsh-api-session-controller/lib/index.js
         dsh/node_modules/@deepseek-ai/dsh-native-command/lib/types/path-opener.js
         dsh/node_modules/@deepseek-ai/dsh-native-command/lib/types/runner.js

3.1 渲染层：按钮灰态 = pending 永不复位

dsh-client-ui-open-in-app/lib/client.js（手势钩子 useOpenTargetGesture）：

const [pending, setPending] = useState(false);
const inFlight = useRef(false);

act: (operation) => {
  if (inFlight.current) return;          // 第二次点击在这里被挡掉
  inFlight.current = true;
  setPending(true);
  execute(operation)
    .then((f) => { if (f !== null) show(t(`path.${f}`)); })            // 失败才提示
    .finally(() => { inFlight.current = false; setPending(false); });  // 只有 settle 才复位
}

同文件里按钮的禁用条件与灰态标记：

const disabled = pending || props.busy === true || props.loading === true;
// ...
"data-state": disabled ? "busy" : "idle"

结论：disabled 里的 busy / loading 是外部传进来的（打开方式、预览加载），用户点击时不会变化；点击后唯一会变的就是 pending。因此"点完变灰、永远灰"只可能由 execute(operation) 返回的 promise 永不 settle 造成——若它 reject 或返回 { ok: false }，会走 .then 弹出「无法显示文件位置，请重试」并在 .finally 复位按钮，这与"无提示 + 永久灰"不符。

3.2 会话 RPC：openPath 既无超时也无取消信号

async openPath(path, action, application) {
  const request = action === "reveal" ? { path, action } : { path, ...(application === void 0 ? {} : { application }) };
  let ok = false;
  try { ok = (await this.remote.session.openWorkspacePath(request)).ok; } catch {}
  return ok ? null : action === "open" ? "openError" : "revealError";
}

这里调用 openWorkspacePath 不传任何 signal，也没有 AbortSignal.timeout。只要宿主端不返回，这个 await 就永远挂着，pending 永远是 true。（对照：dsh-client-ui-deliverables/lib/index.js 的服务端路由是把 request.signal 传下去的，说明链路本身支持取消，只是这条 UI 路径没有用。）

3.3 宿主：execFile('explorer.exe', …) 没有超时

dsh-api-session-controller/lib/index.js：

async openWorkspacePath(request, signal) {
  try {
    const path = await this.verifyDesktopPath(request.path, signal);
    if (request.action === "reveal") await this.revealPath(path, signal);
    else if (request.application !== void 0) await this.openFileApplication(path, request.application, signal);
    else await this.openPath(path, signal);
    return { opened: true };
  } catch (error) {
    if (signal.aborted) throw new RemoteError("gateway/cancelled", "path open was aborted", {});
    if (error instanceof RemoteError) throw error;
    throw new RemoteError("gateway/internal", "path open failed", {}, { cause: error });
  }
}

dsh-native-command/lib/types/path-opener.js（Windows 分支）：

async function runExplorer(args, signal, run) {
  try { await run('explorer.exe', args, signal, 'visible'); }
  catch (error) {
    signal.throwIfAborted();
    // 退出码 1 被当作"已把请求交给桌面进程"的成功而吞掉
    if (!(error instanceof Error) || !('code' in error) || error.code !== 1) throw error;
  }
}

function explorerTarget(windowsPath) {
  const href = pathToFileURL(windowsPath, { windows: true }).href;
  return href
    .replace(/(?:%[89A-F][0-9A-F])+/gi, (escaped) => decodeURIComponent(escaped))  // 还原非 ASCII
    .replaceAll(',', '%2C').replaceAll('=', '%3D');
}

// reveal：显示文件位置
async function revealNativePath(path, signal, internals = {}) {
  // ... manager === 'explorer'（win32）：
  await runExplorer(['/select,', explorerTarget(windowsPath)], signal, run);
}

// 普通打开（"打开"菜单项）在 Windows 上也走同一条 explorer 命令行
async function openWindowsPath(path, signal, run) {
  await runExplorer([explorerTarget(path)], signal, run);
}

dsh-native-command/lib/types/runner.js（全文 30 行的核心）：

export const runNativeCommand = (command, args, signal, window) =>
  new Promise((resolve, reject) => {
    execFile(command, [...args], { encoding: 'utf8', signal, windowsHide: window === 'hidden' },
      (error, stdout, stderr) => {
        if (error !== null) {
          const failure = Object.assign(new Error(error.message, { cause: error }), { code: error.code, stdout, stderr });
          reject(failure);
          return;
        }
        resolve({ stdout, stderr });
      });
  });

注意：execFile 的 options 里没有 timeout，resolve/reject 只发生在子进程退出之后。也就是说：只要 explorer.exe 不退出，这条链上没有任何一层会醒过来——没有超时、没有兜底、没有日志。

3.4 同一仓库里已有的正确做法（可作修复参考）

• dsh-host-open-in-app/lib/index.js：「打开方式 → 文件资源管理器」走 launch { kind: 'shell-open' } → runShellOpen(path, watchMs, internals)，用 watch 计时窗口判定，超时即 resolve("launched")——所以这条路不会把按钮卡死。
• 同包 lib/types/resolver.js：await internals.run(command, args, AbortSignal.timeout(timeoutMs), 'hidden')。
• dsh-workspace-changes/lib/types/git.js：AbortSignal.any([options.signal, AbortSignal.timeout(this.limits.timeoutMs)])。
• dsh-api-workspace-controller/lib/index.js：AbortSignal.any([signal, AbortSignal.timeout(this.config.documentsLookupTimeoutMs)])。

对 app.asar 内 9934 个脚本文件做过全局检索：@deepseek-ai/dsh-native-command 与 @deepseek-ai/dsh-api-session-controller 是唯二完全没有出现任何 AbortSignal.timeout / 超时配置的相关包，而「显示文件位置」正好只走这两个包。

另外，dsh-native-command/README.zh.md 自己已经记录了同类风险：

Windows 主机需要交互桌面会话。在非交互会话（服务，或没有交互登录的计划任务）中，explorer.exe 不调用任何文件关联，且仍在约 1 秒后以退出码 1 返回……调用方的 abort 信号把这段等待变成超时而不是挂死。该会话下的兜底尚未实现。

即：作者知道"这段等待可能挂死"，也设计了 abort 入口，但当前这条 UI 路径没有把 abort/超时接上。

4. 证据与实测数据

4.1 最小复现（不依赖 GUI）

probe.js —— 执行的命令与 DSH 完全一致，参数从环境变量读入（避免命令行引号干扰）：

// 用法：PROBE_ARGV='["/select,","file:///D:/工作/材料/样本文档（含图表）_report.docx"]' node probe.js
const { execFile } = require('child_process');
const argv = JSON.parse(process.env.PROBE_ARGV);
const t0 = Date.now();
const child = execFile('explorer.exe', argv, { encoding: 'utf8', windowsHide: false }, (err) => {
  console.log('EXIT ms=' + (Date.now() - t0) + ' code=' + (err ? err.code : 0));
  process.exit(0);
});
setTimeout(() => { console.log('TIMEOUT ms=' + (Date.now() - t0) + ' still_running=true'); child.kill(); process.exit(0); }, 20000);

窗口检查：

(New-Object -ComObject Shell.Application).Windows() | ForEach-Object { $_.LocationName }

4.2 同一台机器、同一 DSH 构建，重启前后对照

测试	重启前（故障态）	重启后（正常态）
explorer.exe /select, <file:/// URI>（ASCII 目标，DSH 的真实调用形态）	子进程存活 182 秒仍不退出，窗口数 0	EXIT 659 ms，errCode=1，正确打开目标文件夹
同上，目标是中文名 + 全角括号 + 空格的 .docx	无窗口	EXIT 652 ms，正确打开该文件所在的文件夹
同上，改从计划任务（DSH 进程树之外）执行	80 秒仍无窗口 → 机器级故障，与 DSH 的进程树/作业对象无关	—
对照：explorer.exe file:///…（无 /select,，即"打开"路径）	无窗口	EXIT 709 ms，正确打开
对照：同样目标，但把非 ASCII 写成百分号编码（DSH 特意避免的形态）	—	EXIT 669 ms，打开了错误的文件夹
同期用其它方式开文件夹（Shell.Application.Explore / Invoke-Item / cmd /c start）	可以正常打开窗口	可以正常打开窗口

三点结论：

1. DSH 发出的命令本身是对的：正常态下 /select, 形式能正确打开并定位目标文件（含中文、全角括号、空格路径）；被 DSH 特意"还原非 ASCII"的写法恰恰是必需的——用百分号编码会打开错误的文件夹。
2. 触发条件是机器侧的一次性外壳异常：同一台机器、同一个 DSH 构建，只是重启了系统，行为就从"永不退出"变成"660 ms 正常完成"；且故障态下从 DSH 进程树之外也复现。所以它不是"每次开机都存在的机器级缺陷"，而更像"运行久了外壳卡住"这类一次性状态异常（该次外壳已连续运行约 17.5 小时）。
3. DSH 的问题是"不能从异常里恢复"：外壳卡住时按钮永久锁死、无提示、无重试；外壳健康时没有任何问题。

4.3 为什么"变灰后不能再次点击"是必然的

• 第二次点击被 if (inFlight.current) return; 挡掉；
• 按钮 disabled 依赖 pending，而 pending 只在 .finally 里复位；
• .finally 只在 promise settle 时执行，而这条 promise 依赖宿主返回，宿主依赖 execFile 回调，回调依赖 explorer.exe 退出；
• 这一串里没有任何超时，openWorkspacePath 的调用也没有 signal，所以没有任何东西能打断它；
• 没有 toast 也符合这条路径：只有 f !== null 才提示，而挂住时 .then 根本不会执行。

5. 同一路径上的次要缺陷

1. 退出码 1 被无条件当作成功：runExplorer 认为"explorer 退出码 1 = 已交给桌面进程"（正常时确实如此，本次实测正常态也是 errCode=1）。但在"非交互会话"这类场景里，explorer.exe 也会以 1 退出而什么都没打开（dsh-native-command/README.zh.md 自己记录了这一点）。此时 DSH 返回成功、不报错，用户看到的就是"点了没反应"——静默失败。
2. 该路径没有任何日志：会话日志（sessions/**/session.v4.jsonl.zstd）与 logs/ 中都没有 openWorkspacePath 相关记录，用户无法自查、也无法提供有效证据。
3. 影响范围：Windows 上"打开文件 / 显示文件位置 / 打开所在文件夹"都落在同一条 explorer.exe <file:/// URI> 命令行路径上（path-opener.js 的 win32 分支），所以外壳一卡，这些动作会一起永久卡住；只有 dsh-host-open-in-app 的"打开方式"因为用了 watchMs 而幸免。建议修复时一并覆盖。

6. 建议的修复

最小改动（解决"永久锁死"）

1. 给这段等待加墙钟上界，并把超时翻译成正常失败：
   • 在 dsh-api-session-controller.openWorkspacePath 里用 AbortSignal.any([signal, AbortSignal.timeout(pathOpenTimeoutMs)])（默认建议 8–10 s，可配置），超时抛 RemoteError；
   • 或在 runNativeCommand 里给 execFile 加 timeout: pathOpenTimeoutMs（注意与 signal 组合时的语义）。
   • 客户端拿到的就是 { ok: false } → 显示 path.revealError（"无法显示文件位置，请重试"）→ .finally 复位按钮，用户可以重试。
2. 客户端 OpenInAppPathController.openPath 也应在 RPC 上带 signal/超时（与 dsh-host-open-in-app 的 watchMs 思路一致），避免宿主异常时 UI 层无从取消。

更完善（可选）

3. Windows 上的兜底：超时或退出码 1 且确认无窗口时，改用 Invoke-Item <path> / cmd /c start "" <path>（本次排查中，故障态下这两条命令仍能正常打开窗口，而 /select, 命令行不能），从而在"外壳命令行交接卡住"时依然能打开文件夹。
4. 给这条路径加一条诊断日志（请求路径、最终 argv、耗时、退出码），便于用户提交有效证据。
5. 若不便改行为，至少把"等待无上界"写进 dsh-native-command 的文档与 path.revealError 的可用性说明。

7. 本报告的局限

• 报告基于 0.2.0-rc.2（Windows 桌面版），未在 0.2.1-alpha.2 上复测；若该路径的超时逻辑已改动，以最新版本为准。
• "外壳卡住"的触发条件没有定论（只确认了表现与恢复方式：重启系统后消失）。系统里有第三方外壳扩展与 EnableShellExecuteHooks = 1，但本次没有做"禁用它们后复现"的对照实验，不作为结论。
• 需要的话我可以补充：/select, 挂起期间 explorer.exe 的线程/句柄快照、重启前后同一条命令的完整计时日志。

[PerryLink]

这条全链逐步证实，你的自测量与源码语义完全自洽。补三样：为什么连 toast 都没有是必然、第二处独立缺陷、以及一个你把两个独立缺陷合并成一处的判断（拆开后修法不同）。

1. 缺陷链：六个环节，逐环节有据

环节	位置	事实
渲染	packages/client/ui-open-in-app/src/client/OpenTargetButton.tsx:50-64	const [pending, setPending] = useState(false) / if (inFlight.current) return / setPending(true) / void execute(operation).then(...).finally(() => { inFlight.current = false; setPending(false) }) —— 只有 settle 才复位
按钮态	同文件 :92 / :134	const disabled = pending || props.busy === true || props.loading === true / data-state={disabled ? 'busy' : 'idle'} —— data-state="busy" 精确对上你的观察
客户端	packages/client/ui-open-in-app/src/client/open-path.ts:56-66	ok = (await this.remote.session.openWorkspacePath(request)).ok —— 第二参数 signal? 没传（同文件 :77 的 applications() 却传了 ⇒ 接口支持，这条 UI 路径没用）
宿主	packages/api/session-controller/src/index.ts:347-368	@Remote('openWorkspacePath') async openWorkspacePath(request, signal) —— 这个 signal 是 carrier 生命周期，超时不会触发它；AbortSignal.timeout 在整个 src/ 下 0 命中
命令	packages/util/native-command/src/path-opener.ts:307	await runExplorer(['/select,', explorerTarget(windowsPath)], signal, run)（openWindowsPath 在 :154-156）
执行	packages/util/native-command/src/runner.ts:25-43	execFile(command, [...args], { encoding: 'utf8', signal, windowsHide: window === 'hidden' }, ...) —— options 里没有 timeout

零命中的交叉复核：packages/util/native-command/src/ 内 timeout / killSignal / deadline / setTimeout / AbortSignal.timeout / watchMs 各 0 命中（同目录 signal 正常命中，证明正则有效）。整个包没有时间上界。

2. 为什么「无任何 toast」是必然，不是偶发

OpenTargetButton.tsx:60-62 只有 failure !== null 才 show(...)。挂住时 .then 从不执行 ⇒ 既不报错也不复位 ⇒ 无提示 + 永久灰。你这条推理经源码完全证实。

3. 你的对照组也是对的（这点值得保留）

• packages/host/open-in-app/src/resolver.ts:90 → const watch = setTimeout(() => { settle(resolve) }, options.watchMs)，:92-95 → launcher exited with code …
• 同文件 :168-171 → await internals.run(command, args, AbortSignal.timeout(timeoutMs), 'hidden')
• :686-710 的 runShellOpen(path, watchMs, internals) —— 「打开方式 → 文件资源管理器」走这条路，所以确实不会卡死

⇒ 所以"兄弟包都做了、只有 native-command 没做"这个对照成立。

4. ⭐ 第二处独立缺陷：退出码 1 被无条件当成功

packages/util/native-command/src/path-opener.ts:136-145：

await run('explorer.exe', args, signal, 'visible')
…
if (!(error instanceof Error) || !('code' in error) || error.code !== 1) throw error

注释 :142 写着 Explorer can exit 1 after delegating to the existing desktop process. —— 在正常场景下这是对的，但在你遇到的故障态下，explorer 以 1 退出却什么都没打开，而这里把它当成成功 ⇒ 静默失败。

而且包自己的 README 已经记录了这一点（packages/util/native-command/README.zh.md 的 Known Limitations）：

Windows 主机需要交互桌面会话。在非交互会话（服务，或没有交互登录的计划任务）中，explorer.exe 不调用任何文件关联，且仍在约 1 秒后以退出码 1 返回……于是「打开」会报告成功却什么都没打开；调用方的 abort 信号把这段等待变成超时而不是挂死。……该会话下的兜底尚未实现。

⇒ 建议把它单列为第二个诉求：超时/退出码 1 且无窗口时回退 Invoke-Item / cmd /c start（你实测这两条在故障态可用）。不要把它和"缺超时"合成一条 —— 它们的修法不同（一条是加上界，一条是改判据+加兜底）。

5. 一处需要拆开的判断

你写"机器侧一次性外壳异常，不作为 DSH 缺陷" —— 这个克制是对的，我同意 explorer 卡住本身不是 DSH 的问题。但请把它明确写成：

DSH 的真实缺陷是不能从异常里恢复（无上界 + 误判成功 + 无诊断），而不是 explorer 卡住。

这样维护者不会把报告读成"用户在抱怨 Windows"。

6. 最小修法（两行位置）

1. packages/util/native-command/src/runner.ts:30 的 options 加 timeout
2. 或 packages/api/session-controller/src/index.ts:353-354 用 AbortSignal.any([signal, AbortSignal.timeout(pathOpenTimeoutMs)])
3. 客户端侧同时给 open-path.ts:60 传 signal/超时

任一失败都会让 openPath 返回 'revealError'（open-path.ts:65）→ 弹 locales.ts:52 的 'path.revealError': '无法显示文件位置，请重试' → .finally 复位按钮 —— 与你的期望结果一致。

7. 你的诊断日志诉求也成立

openWorkspacePath 这条路径下没有任何 logger 调用（会话日志与 logs/ 均无记录）⇒ 值得作为修复的一部分。这一点可以和"静默失败"合并成一条诉求。

8. 版本与边界

你写 0.2.0-rc.2 / build commit 04f392c9…。我核的是 origin/master = d743267388（= dsh-v0.2.1-alpha.2），上述六处都在；native-command 包内仍然没有时间上界 ⇒ 缺口对最新线成立。

⚠️ 按规范如实标注：你举的两个"同仓已有正确做法"（dsh-workspace-changes、dsh-api-workspace-controller）我没有逐一核对；我只核实了 host/open-in-app 这一处。另外你自测的 182 s 挂死 / 重启后 660 ms，我无法在你机器外复核，但它们与源码语义完全自洽。

用户侧 workaround：重启 DSH 窗口（你已知）；更轻的是重启 explorer.exe 进程（故障在 explorer 侧）。