[Windows] dsh-native-command 把 windowsHide 用在 GUI 程序上：窗口被创建成隐藏态，并导致整个目录后续无法打开

[yangzeusyong-creator]

环境

DSH Desktop	0.9.0（社区桌面壳）
内置 Harness	0.1.5-rc.2
平台	Windows 11 x64
相关包	@deepseek-ai/dsh-native-command

现象

两个不同按钮都会出现「点了没反应」，且同一个会话目录坏了之后，所有方式都打不开它：

1. 交付卡片「在文件资源管理器中显示」（走 revealNativePath）
2. 会话标题栏右上角「打开工作目录」（走 openNativePath）

症状特征：HTTP 返回成功（204 / {ok:true}）、无任何报错、但屏幕上什么都不出现。

根因：一个根源，三处缺陷

根源是 windowsHide: true 被应用到了 GUI 程序上。

它本该只隐藏控制台窗口（避免 pwsh 闪黑框，参见 #1344 / #1102 / #1142 那一批讨论），但被同时用在了 explorer.exe 和 powershell.exe 上。对 GUI 程序而言，Node 会把它转成 STARTUPINFO.wShowWindow = SW_HIDE —— 于是窗口被创建/继承成隐藏状态。

缺陷 A — pathToFileURL 的结果交给 /select,

revealNativePath() 用 pathToFileURL(windowsPath).href 把路径变成百分号编码的 file: URL，再交给 explorer.exe /select,，而后者需要的是文件系统路径。

Explorer 无法解析 → 静默回退打开「桌面」。中文 → %E4%B8%AD，空格 → %20。

（此点已由社区插件 HeJian2002W/dsh-reveal-fix 独立确认，结论一致。）

缺陷 B — runNativeCommand 硬编码 windowsHide: true

explorer.exe 是 GUI 启动器而非控制台程序。隐藏它 = 隐藏它正要显示的那个窗口。窗口被创建成 SW_HIDE 状态，IsWindowVisible() 返回 false。

缺陷 C — openWindowsPath 走 Invoke-Item，窗口继承隐藏态

async function openWindowsPath(path, signal, run) {
  await run('powershell.exe', [
    '-NoProfile',
    '-Command',
    `Invoke-Item -LiteralPath ${powershellLiteral(path)}`,
  ], signal)
}

powershell 被 windowsHide 隐藏（这对控制台程序是正确的），但它打开的文件夹窗口继承了该隐藏状态 → 又产生一个隐藏窗口。

为什么危害会扩散：「隐藏窗口毒化目录」

隐藏的文件夹窗口看不见、关不掉，会常驻（每个约 180MB）。而 Windows 按目录复用文件管理器窗口 —— 之后无论用什么方式打开那个目录，都只是「激活那个已存在的隐藏窗口」，于是看起来什么都没发生。

后果：

• 某个会话的按钮失效，其他会话正常（只有那个目录被毒化）
• 重启后暂时好转，用一会儿又坏（又毒化了一个目录）
• 交付卡片与右上角「一起坏」（它们共享同一套目录毒化机制）

实测证据

判定标准必须用 IsWindowVisible —— Shell.Application.Windows() 会列出隐藏窗口，靠计数无法区分可见与否：

Add-Type -MemberDefinition '[DllImport("user32.dll")] public static extern bool IsWindowVisible(IntPtr h);' -Name W -Namespace Q
(New-Object -ComObject Shell.Application).Windows() |
  ForEach-Object { "{0,-6} {1}" -f [Q.W]::IsWindowVisible([IntPtr]$_.HWND), $_.LocationURL }

在干净重启的 explorer shell 上，每条路径各触发 3 次：

路径	可见	隐藏	判定
revealNativePath（交付卡片）	0	1	每次毒化一个目录
openNativePath（右上角）	0	1	每次毒化一个目录
修复后（见下）	3	0	正常

A/B 单变量对照（同一命令，仅改一个变量）：

变量	结果
pathToFileURL().href → /select,	窗口落在 Desktop
纯路径 → /select,	窗口落在目标目录
windowsHide: true	IsWindowVisible = False
windowsHide: false	IsWindowVisible = True
目录走 explorer.exe /n,<dir>	可见（且已毒化的目录也能开出可见窗口）

为什么这个 bug 极难诊断

三者叠加使故障完全静默：

1. explorer.exe 无论成败退出码恒为 1（上游已将其视为「委派交接」吞掉）
2. HTTP 路由恒返回成功
3. 前端提示文案与成功时完全相同

建议修法（三处，均已实测）

① runner.ts — GUI 启动器不隐藏

const GUI_LAUNCHER = /^(?:explorer\.exe|explorer|open|xdg-open)$/i
execFile(command, [...args], {
  encoding: 'utf8',
  signal,
  windowsHide: !GUI_LAUNCHER.test(command),
}, cb)

（powershell.exe 不在此白名单 → 仍保持 true，控制台窗口照常隐藏。这样 #1344 那批问题仍能规避。）

② path-opener.ts — revealNativePath 传纯路径

const target = windowsPath   // 替代 pathToFileURL(...).href.replaceAll(',', '%2C')

③ path-opener.ts — openWindowsPath 按类型分流，目录走 explorer /n

import { statSync } from 'node:fs'

function isExistingDirectory(path: string): boolean {
  try { return statSync(path).isDirectory() } catch { return false }
}

async function openWindowsPath(path: string, signal: AbortSignal, run: PathOpenerRunner): Promise<void> {
  if (isExistingDirectory(path)) {
    try {
      await run('explorer.exe', [`/n,${path}`], signal)
    } catch (error) {
      signal.throwIfAborted()
      // explorer.exe 即使成功打开窗口，退出码也常为 1
      if (!(error instanceof Error) || !('code' in error) || error.code !== 1) throw error
    }
    return
  }
  await run('powershell.exe', [
    '-NoProfile',
    '-Command',
    `Invoke-Item -LiteralPath ${powershellLiteral(path)}`,
  ], signal)
}

/n 的作用是强制新窗口：即使目标目录已被毒化（已存在一个隐藏窗口），也能开出可见窗口。

补充建议

1. 考虑在 Desktop 场景改用 Electron 原生 API。 桌面壳自身已在用 shell.showItemInFolder() / shell.openPath()（例如菜单「显示日志」），工作完全正常 —— 它不创建子进程、不受 windowsHide 影响。若 Host 的 reveal/open 调用能通过壳层桥接，可根治这一整类问题。

2. openWindowsPath 对 powershell.exe 的依赖也可一并优化：参见 zhu1090093659/dsh-web#395，那里踩的是同类调用方式的另一个坑（cwd 传入了带 /select, 前缀的假路径）。

与已有讨论的关系

本 issue 与 #1344 / #1102 / #1142 是同一机制的两个相反方向：

• 那批讨论解决「窗口不该出现却出现」→ 用 SW_HIDE 把控制台藏起来
• 本 issue 是「窗口该出现却被藏了」→ 同一个 windowsHide 落到 GUI 程序上的副作用

也就是说：windowsHide 对控制台程序完全正确，只是不该无差别地作用于 GUI 启动器。