[Bug] 0.1.7-rc.2 / master：Windows 上「打开目录 / 在资源管理器中显示」的窗口不可见、或只在任务栏不弹前台 —— SW_HIDE 泄漏 + Windows 前台锁

[Michael10Z4]

[Bug] 0.1.7-rc.2 / master：Windows 上「打开目录 / 在资源管理器中显示」的窗口不可见、或只在任务栏不弹前台

English version below.

TL;DR

@deepseek-ai/dsh-native-command@0.1.7-rc.2（以及 master）在 Windows 上通过 openNativePath() 打开目录时有两个独立缺陷：

1. 窗口被创建，但不可见。 runNativeCommand 恒以 windowsHide: true（STARTF_USESHOWWINDOW + SW_HIDE）启动子进程；Explorer 会把调用方的显示状态带给它创建或激活的窗口，于是窗口 IsWindowVisible = false——而 POST /open-in-app/open 依然返回 200 {ok:true}，界面无任何报错。
2. 窗口存在，却只在任务栏出现、不弹到前台。 启动链是「浏览器（前台）→ HTTP → DSH 宿主（后台）→ 子进程」，后台进程被 Windows 前台锁拒绝；即使绕开前台锁，若执行激活的进程随即退出，焦点也会被交还给上一个活动窗口。

修复：① 目录改用 explorer.exe <encoded file URI> + windowsHide: false 启动；② 在宿主进程内用 koffi 直接调 user32（EnumWindows 定位窗口 → 最小化 → 还原 → SetForegroundWindow），与打开并行、best-effort。

版本与环境

• @deepseek-ai/dsh-native-command 0.1.7-rc.2（dist-tags.next），并对照 master
• Windows 11 25H2（build 26200.9457），Node 24.19.0
• 涉及界面：会话头部 open-in-app 的「文件资源管理器」条目（explorer 目录 id，win32 上唯一的 shell-open 条目），以及 revealNativePath() 的「在资源管理器中显示」

一、发布产物核验（0.1.7-rc.2 真实 npm tarball）

解开发布包逐处确认（lib/index.js 是 exports 映射实际加载的 bundle，lib/types/*.js 是随包发布的同伴文件）：

// lib/types/runner.js:14（lib/index.js:22 是同一份 bundle 内的副本）
execFile(command, [...args], { encoding: "utf8", signal, windowsHide: true }, (error, stdout, stderr) => {

// lib/types/path-opener.js:115（lib/index.js:143 同上）
await run('explorer.exe', args, signal);   // 未传启动状态 → 继承 SW_HIDE

即：Explorer 重写已发布（Invoke-Item 在全包内已无命中），但 runner 仍硬编码 windowsHide: true，runExplorer 也未覆盖它。

二、缺陷一：窗口被创建但不可见（SW_HIDE 泄漏）

windowsHide: true 在子进程的 STARTUPINFO 中设置 SW_HIDE；当该子进程请求外壳打开/激活文件夹时，Explorer 会把调用方的显示状态应用到它创建（或激活）的窗口上——窗口不可见，而请求本身"成功"。

实测（Windows 11 25H2 build 26200.9457；每次先关闭目标窗口，再启动一次，用 Shell.Application.Windows() + IsWindowVisible/IsIconic 读取状态）：

启动方式（0.1.7 的实际 argv）	windowsHide	结果
explorer.exe <encoded file URI>	true（现状）	不可见 ❌ IsWindowVisible=false、IsWindow=true、IsIconic=false
explorer.exe <encoded file URI>	false	可见 ✅
rundll32 url.dll,FileProtocolHandler <path>	true	不可见 ❌（证明是启动状态，而非选哪个启动器）

被隐藏的窗口并未销毁：ShowWindow(hwnd, SW_SHOW) 可以恢复（实测有效）。宿主机上曾累计出现 8 个这样的隐形 file:///D:/Innovation 窗口。

三、缺陷二：窗口只出现在任务栏、不弹到前台

修好可见性后，窗口会正常出现（IsWindowVisible=true、IsIconic=false），但不进入前台：只多出一个任务栏按钮。根因两层，都在 Windows 侧：

1. 后台进程无权抢前台：SetForegroundWindow 返回 False，系统只闪一下任务栏；
2. 即使用"最小化 → 还原"绕开前台锁成功拿到前台，执行激活的进程一退出，焦点立刻交还给上一个活动窗口。

实测（同上环境，浏览器为前台）：

抬升手法	调用返回	+1s / +4s 实测
裸 SetForegroundWindow	False	❌（副作用：把窗口弄回隐藏）
AttachThreadInput + SetForegroundWindow	False	❌
SetWindowPos(HWND_TOP)（仅调 z 序，不抢焦点）	True	❌ 观感无变化
HWND_TOPMOST → HWND_NOTOPMOST	True	❌ 反而留下一个最小化窗口
最小化→还原 + SetForegroundWindow，执行进程随即退出	True	❌ 1 秒内焦点被交还
最小化→还原 + SetForegroundWindow，由常驻进程执行	True	✅ 前台稳定停在目标窗口

结论：抬升必须由生命周期长于该次点击的进程执行——这正是把它放进 DSH 宿主进程（而非短命子进程）的原因。

边界：若另一个程序正在主动争抢前台（实测中，同机上一个交互式 TUI 控制台就会），任何启动器都无法稳压它。这属于系统级限制，不属于本缺陷。

四、修复

1）目录分支改用可见启动状态

packages/util/native-command/src/path-opener.ts → openWindowsPath()，目录交给 Explorer 自身的 CLI，并用可见启动状态；退出码 1 仍视为"已交接给运行中的外壳"（与 revealNativePath() 的既有处理一致）：

-  await run('explorer.exe', args, signal)
+  await run('explorer.exe', args, signal, { windowsHide: false })

配套（缺陷一的根因所在，src/runner.ts）：把 windowsHide 提升为每次调用可选参数，默认 true，所有既有调用方行为不变：

+export interface NativeCommandOptions {
+  /** 默认 true；子进程要创建用户窗口的调用方传 false。 */
+  windowsHide?: boolean
+}
 export type NativeCommandRunner = (
   command: string,
   args: readonly string[],
   signal: AbortSignal,
+  options?: NativeCommandOptions,
 ) => Promise<{ stdout: string; stderr: string }>
-export const runNativeCommand: NativeCommandRunner = (command, args, signal) =>
+export const runNativeCommand: NativeCommandRunner = (command, args, signal, options = {}) =>
   new Promise((resolve, reject) => {
     execFile(
       command,
       [...args],
-      { encoding: 'utf8', signal, windowsHide: true },
+      { encoding: 'utf8', signal, windowsHide: options.windowsHide ?? true },

（文件/文档路径保持原样，不改变"用默认程序打开"的语义。）

2）在宿主进程内抬升窗口

openWindowsPath() 内，与打开并行发起一次 best-effort 抬升（失败不影响已经成功的打开）：

// 用 DSH 已随装的 koffi 绑定 user32，不起任何子进程
const koffi = (await import('koffi')).default
const lib = koffi.load('user32.dll')
// EnumWindows 找到目标窗口：窗口类 CabinetWClass 且标题前缀为 "<文件夹名> - "
//（标题前缀与系统语言无关）
lib.func('bool EnumWindows(void *lpEnumFunc, intptr_t lParam)')(callback, 0)
// 后台进程被前台锁拒绝，先最小化再还原——还原这一步才解锁激活
lib.func('bool ShowWindow(intptr_t h, int cmd)')(handle, 6)   // SW_MINIMIZE
await delay(140)
lib.func('bool ShowWindow(intptr_t h, int cmd)')(handle, 9)   // SW_RESTORE
await delay(90)
lib.func('bool SetForegroundWindow(intptr_t h)')(handle)

因为宿主进程常驻，不需要任何"保持激活"（见第三节最后两行实测）。

延迟：宿主内直调实测 窗口成为前台 555 ms、openNativePath 返回 662 ms；其中 EnumWindows 单次 2 ms、抬升动作约 230 ms（两次等待 140 + 90 ms），瓶颈回到 explorer.exe 自身创建窗口的耗时。

实现注意：koffi 不允许重复定义同名类型。koffi.proto("bool EnumWindowsProc(...)") 必须定义一次并缓存——若在轮询循环中每次重新定义，第二次迭代即抛 Duplicate type name，而该异常会被 best-effort 的 catch 吞掉，表现为"补丁已生效、窗口却完全没有被抬升"，非常难定位。

五、影响面

• 仅 Windows；影响所有通过 openNativePath() 打开目录的界面（最明显的是 open-in-app 的「文件资源管理器」条目），以及 revealNativePath() 的「在资源管理器中显示」。
• macOS / Linux 分支与 argv 方式启动的条目（VS Code / Windows 终端 / Git Bash）不受影响。
• 与本包 README 已自述的另一条限制无关：非交互会话（服务 / session 0）中 explorer.exe 不触发文件关联、约 1 秒后仍返回 1，于是"报成功但什么都没打开"。

---

English

Two independent defects when 0.1.7-rc.2 opens a folder on Windows.

(1) The window is created but invisible. runNativeCommand always spawns with windowsHide: true, which sets STARTF_USESHOWWINDOW + SW_HIDE in the child's STARTUPINFO; Explorer applies the caller's show state to the window it creates or re-activates, so the window is IsWindowVisible = false while POST /open-in-app/open still answers 200 {ok:true} and the UI shows no error. Verified against the published artifact: lib/types/runner.js:14 (lib/index.js:22) hard-codes windowsHide: true, and lib/types/path-opener.js:115 (lib/index.js:143) calls await run('explorer.exe', args, signal) with no launch-state option. Measured on Windows 11 25H2 (build 26200.9457): explorer.exe <encoded file URI> with windowsHide: true → invisible window; with windowsHide: false → visible. rundll32 url.dll,FileProtocolHandler with windowsHide: true is invisible too, so the flag — not the launcher — is the variable. Hidden windows are not destroyed (ShowWindow(hwnd, SW_SHOW) restores them; eight had accumulated on the reporting host).

(2) The window only appears in the taskbar. With visibility fixed the window exists (IsWindowVisible = true, IsIconic = false) but never reaches the foreground. Two Windows-side causes: a background process is refused by the foreground lock (SetForegroundWindow returns False, the shell only flashes the taskbar), and even the minimize → restore trick that does unlock the activation is undone the moment the activating process exits — measured: with an immediate exit the foreground is back on the browser within a second; when the raise runs from a long-lived process it stays. Bare SetForegroundWindow, AttachThreadInput + SetForegroundWindow, SetWindowPos(HWND_TOP) and a HWND_TOPMOST → HWND_NOTOPMOST cycle all failed to raise it (the last one even left the window minimized).

Fix. (a) openWindowsPath() opens a directory through Explorer's own CLI with a visible launch state — run('explorer.exe', args, signal, { windowsHide: false }), keeping exit code 1 as the delegated handoff — and src/runner.ts gains a per-call windowsHide option (default true, so every existing caller is unchanged). (b) The window is raised from the host process, in parallel with the open and best effort, using the koffi that DSH already ships: bind user32.dll, find the window with EnumWindows (class CabinetWClass, title prefix "<folder name> - ", which is locale-independent), ShowWindow(SW_MINIMIZE) → 140 ms → ShowWindow(SW_RESTORE) → 90 ms → SetForegroundWindow. Because the host outlives the call, no keep-alive is needed. Measured: foreground after 555 ms, openNativePath returns in 662 ms (EnumWindows 2 ms, the raise ~230 ms), leaving Explorer's own window creation as the floor. Implementation trap: koffi refuses to define the same type name twice, so koffi.proto(...) must be created once and cached — re-creating it inside the polling loop throws Duplicate type name from the second iteration, and a best-effort catch turns that into "patched, yet the window is never raised".

Scope. Windows only; affects every surface opening a directory through openNativePath() (most visibly the open-in-app File Explorer entry) and revealNativePath(). macOS/Linux branches and argv-launched entries (VS Code, Windows Terminal, Git Bash) are unaffected. Unrelated to the README's Known Limitation about non-interactive sessions, where explorer.exe opens nothing and still exits 1.

[davis0178]

Confirming on Desktop 0.1.7-rc.2 (Windows 11, build 26100), with a minimal reproduction and a verified local workaround.

Reproduction (100% deterministic)

const { execFile } = require('node:child_process')
// hidden: no window ever appears; explorer.exe exits (code 1) after delegating
execFile('explorer.exe', ['file:///C:/Users/<user>/Documents'], { windowsHide: true }, () => {})
// visible: the folder window appears immediately
execFile('explorer.exe', ['file:///C:/Users/<user>/Documents'], { windowsHide: false }, () => {})

Observed on the actual button click

• POST /open-in-app/open returns 200 {"ok":true} — the UI shows no error; the busy spinner flashes and nothing happens.
• Process monitoring during clicks: new explorer.exe processes are spawned, but every one of them has MainWindowHandle = 0 — the window is created hidden (SW_HIDE leaks through the delegated launch).
• The route reports launched because runExplorer treats explorer's exit code 1 as a delegated handoff, so the silent no-op is invisible to the caller.

Root cause

dsh-native-command's runNativeCommand() hardcodes windowsHide: true for every command, including the explorer.exe launch in the open-in-app shell-open path. Explorer inherits the hidden STARTUPINFO state, so the window it creates/delegates is hidden.

Suggested fix

Hide only console-only helpers, not GUI launchers — e.g. in packages/util/native-command/src/runner.ts:

windowsHide: command !== 'explorer.exe'

Keep windowsHide: true for the PowerShell icon extraction; only the shell-open / reveal paths need a visible spawn.

Local workaround applied (verified working)

In-place patch of the packaged asar (dsh/node_modules/@deepseek-ai/dsh-native-command/lib/index.js): windowsHide: true -> windowsHide: 0==1 (equal-length edit). After restarting the desktop app, the "Open in File Explorer" button opens the window normally. Side effect: the PowerShell icon extraction briefly flashes a console window the first time icons load; no other impact.

[shark6s]

补充一份桌面版自带运行时上的实测证据，支持①（SW_HIDE 泄漏），并补一条本贴还没提到的限制。

1. 缺陷就在 Desktop 0.1.7-rc.2 的 asar 里（不只是 npm 的 dist-tags.next）

装的是官方桌面版（DeepSeek Harness.exe FileVersion 0.1.7-rc.2，asar 内 @deepseek-ai/dsh-desktop，dshBuildCommit=c1275515b6b97551ec358c926c479ab750c687c0）。直接解析 L:\DeepSeekHarness\resources\app.asar 的头部后按条目读取：

条目 /dsh/node_modules/@deepseek-ai/dsh-native-command/lib/index.js
  size=40419   offset=47562602   unpacked=false   (asar 头部该条目带 integrity 字段)
  含 "windowsHide: true"          = true
  含 "pathToFileURL(windowsPath"  = true
  含 "revealExplorerPath"         = false

也就是说：桌面版安装包里同时带着你指出的两处——runner 依旧硬编码 windowsHide: true，explorer 依旧收 file:// URL 形态。桌面版用户不装任何插件、不跑 npm 包就会命中。

2. 【新增】桌面版没有「本地打补丁」这条路可走

同一台机器上，npm 全局树（web profile 用的 0.1.5-rc.2）在 2026-09-24 打过一次本地补丁，「在文件资源管理器中显示」就恢复正常：

const revealExplorerPath = (windowsPath, signal) => new Promise((resolve, reject) => {
  execFile("explorer.exe", ["/select," + windowsPath], { signal, windowsHide: false }, (error) => {
    if (error !== null && error.code !== 1) { reject(error); return }
    resolve();
  });
});

要点：单 argv（/select, 与路径不拆开）、本地路径不做 URL 转换、windowsHide: false、容忍退出码 1（explorer 成功也回 1）。判定不靠肉眼，用 Shell.Application.Windows() 读窗口状态：新窗口 file:///L:/dsh工作区、FocusedItem = L:\dsh工作区\tools ✅ —— 路径含中文（dsh工作区）也正确选中，可作为 #7565 / #7033 那类「非 ASCII 路径」场景的对照样本。

但这条补丁在桌面版上不适用：DeepSeek Harness.exe 内嵌了 INTEGRITY / ELECTRONASAR 资源（electron-builder 开启 asar integrity 时的产物，PE 资源里可见），即 Electron 会对 app.asar 做完整性校验。因此去改 asar 里那 40 KB 的 lib/index.js 存在让 Harness 直接启动失败的风险 —— 桌面版用户没有本地 workaround 可走，只能等上游出新版本。这一点建议在 issue 说明里点明，否则会有一堆用户照着 web 侧的补丁去改 asar。

3. 同机对照

同一台 Windows 11 机器、同一时刻：

宿主	dsh-native-command 来源	点「在文件资源管理器中显示」
web profile（3080）	npm 全局 0.1.5-rc.2 + 上述本地补丁	正常弹窗并选中目标项 ✅
desktop profile	自带 asar 内 0.1.7-rc.2（未打补丁）	静默无反应 ❌（RPC 仍返回成功）

与 #7982 的 A/B 结论一致：区分变量是 windowsHide（以及路径形态），不是退出码。

一点边界说明：本机没能观察到你说的第②条前台锁那一半 —— 补丁版在 0.1.5 web 宿主上窗口是正常提到前台的。所以前台锁可能只在「宿主进程长期处于后台」的桌面宿主场景才暴露（desktop 宿主与 web 宿主的前台状态不同），这边没有反证，只能认为 desktop 下表现更差，建议仍按你的修法做 best-effort 前台提升。

---

English summary: the exact defects also ship inside DSH Desktop 0.1.7-rc.2's bundled resources/app.asar — dsh/node_modules/@deepseek-ai/dsh-native-command/lib/index.js (size 40419) still has windowsHide: true and the file:// argv form, and has no revealExplorerPath. A local-patch workaround that fixes the npm/web profile on the same machine (verified via Shell.Application FocusedItem, including a CJK path) is not applicable to Desktop: the exe carries an INTEGRITY/ELECTRONASAR resource, i.e. asar integrity validation, so patching app.asar risks making Harness fail to start. Same-machine A/B: patched web tree reveals correctly; unpatched Desktop copy is a silent no-op.

[davis0178]

Thanks for the added evidence — the offsets and size match our install exactly, so it is the same defect in both copies.

One empirical datapoint that softens the "no local workaround on Desktop" conclusion for this shipped build: on our machine the official DeepSeek Harness.exe (FileVersion 0.1.7-rc.2) also carries an ELECTRONASAR resource (present as a UTF-16 PE resource name), yet after the equal-length in-place patch (windowsHide: true -> windowsHide: 0==1, same 40419-byte file, all offsets untouched) the app restarted and booted normally. The patched module is genuinely loaded — the "Open in File Explorer" button now opens a visible window — and there was no integrity error at startup or on read.

So on this build the integrity metadata is present but validation is not enforced (or not blocking); enforcement presumably depends on the EnableEmbeddedAsarIntegrityValidation fuse / distribution channel. Your general caution still stands: other builds could enforce it, so asar patching should not be advertised as a universal workaround — backup-first, last resort only — and the official fix remains the right path. We kept app.asar.dsh-bak alongside for rollback.