[Bug] Windows: file-manager "Show file location" / default-app open silently fails (windowsHide hides Explorer's delegated window)

[unifilitence]

[Bug] Windows: "Show file location" / default-app open silently fails — runNativeCommand forces windowsHide: true, hiding Explorer's delegated window

English

Affected versions: Desktop 0.1.7-rc.2 (embedded runtime). The same code is present in @deepseek-ai/dsh-native-command 0.1.5-rc.1 (lib/index.js, runNativeCommand, windowsHide: true).
Reproduced in a normal interactive desktop session (clicking "Show file location", busy cursor ~0.5 s, then nothing) — distinct from the non-interactive-session blind spot documented in packages/util/native-command/README.md:112; A/B confirmation in the comments.

Component: @deepseek-ai/dsh-native-command — runNativeCommand (shared execFile runner), consumed by revealNativePath / openNativePath (Explorer delegation) via runExplorer.

Steps to reproduce

1. Open a workspace file in the sidebar document preview.
2. Click the file's "More ways to open" (更多打开方式) chevron → "Show file location" (显示文件位置).
3. Observe: a busy cursor for ~0.5 s, then nothing. No Explorer window, no error toast. (The host answers success because Explorer's delegation exit code 1 is accepted.)

Same result for opening the workspace directory via the session-header "Open In..." control (same runExplorer path).

Expected

Windows Explorer opens / reveals (selects) the file.

Actual

No window appears at all; the request is answered as successful, so the UI shows no failure.

Minimal reproduction (independent of DSH)

Any existing local file, e.g. C:\Users\Public\reveal-sample.txt:

const { execFile } = require("child_process");
const url = "file:///C:/Users/Public/reveal-sample.txt";

// A) windowsHide: true  -> explorer exits 1, NO window ever appears (silent)
execFile("explorer.exe", ["/select,", url], { windowsHide: true },
    (e) => console.log("hide=true :", e ? e.code : "ok"));

// B) no windowsHide     -> Explorer window opens with the file selected
execFile("explorer.exe", ["/select,", url], {},
    (e) => console.log("hide=false:", e ? e.code : "ok"));

Observed on Windows 11 (controlled experiment; same command line, same URL — the only variable is windowsHide):

• PowerShell direct invocation (no windowsHide): window opens, file selected ✔
• execFile with windowsHide: true: no window ✘
• execFile without windowsHide (only variable changed): window opens, file selected ✔

Root cause

runNativeCommand hard-codes windowsHide: true for every child process:

execFile(command, [...args], { encoding: "utf8", signal, windowsHide: true }, ...)

windowsHide becomes STARTF_USESHOWWINDOW + SW_HIDE in the CreateProcess STARTUPINFO.
explorer.exe /select,<target> is a delegation program: the new explorer process hands
the request to the always-running desktop shell and exits with code 1 (which runExplorer
correctly accepts as "delegated"). The shell process that finally creates the window
inherits the show-state along the delegation, so the reveal window is created hidden.
The result is a silent no-op from the user's perspective, with a success answer on the wire.

The flag is correct for the console tools this runner also executes (reg.exe, PowerShell
icon extraction, wslpath, ...) — it is only the delegation-style Explorer invocations that
must not force it.

Scope

• revealNativePath (Explorer /select, reveal): confirmed broken.
• openNativePath on win32 also goes through runExplorer (explorer.exe <target>),
  which delegates the same way, so default-app open of files/directories is expected to be
  affected by the same mechanism (inferred from the shared code path; not separately tested).
• Explicit-application launches (openNativeFileApplication, third-party GUI apps) are
  typically unaffected, because those apps create their windows from their own code and
  ignore the inherited SW_HIDE (inferred; not separately tested).

Suggested fix

Do not force windowsHide for Explorer's delegation-style invocations; keep it for the
console tools. Minimal change in runNativeCommand (or an equivalent dedicated runner for
runExplorer):

--- a/packages/util/native-command/src/runner.ts
+++ b/packages/util/native-command/src/runner.ts
@@
 const runNativeCommand = (command, args, signal) => new Promise((resolve, reject) => {
 	execFile(command, [...args], {
 		encoding: "utf8",
 		signal,
-		windowsHide: true
+		// Explorer delegates window creation to the always-running shell; a forced
+		// SW_HIDE travels through the delegation and hides the resulting window.
+		// Console tools (reg.exe, powershell icon extraction, wslpath, ...) keep the hide.
+		windowsHide: !/explorer\.exe$/i.test(String(command))
 	}, (error, stdout, stderr) => {

Workaround used locally (for reference)

Patched the embedded runtime's copy of runNativeCommand with the same one-line
special-case (full app.asar backup taken first; the patch is overwritten by upgrades
and must be re-applied until fixed upstream).

---

中文

影响版本： Desktop 0.1.7-rc.2（内嵌运行时）——@deepseek-ai/dsh-native-command 0.1.5-rc.1 中同样存在（lib/index.js 的 runNativeCommand，windowsHide: true）。
复现环境：正常交互式桌面会话（点击"显示文件位置"后 busy 约 0.5 秒、无任何窗口）——区别于 README.md:112 记录的"非交互式会话"已知盲区（评论区有 A/B 定案）。

组件： @deepseek-ai/dsh-native-command — runNativeCommand（共享 execFile runner），被 revealNativePath / openNativePath（explorer 委托）经 runExplorer 调用。

复现步骤

1. 在侧边栏文档预览中打开一个工作区文件。
2. 点文件的"更多打开方式" → "显示文件位置"。
3. 现象：鼠标 busy 光标约 0.5 秒后消失；没有资源管理器窗口、没有任何错误提示（宿主按成功应答，因为 explorer 的委托退出码 1 被 runExplorer 接受）。

会话头部 "Open In..." 打开工作区目录也走同一条 runExplorer 链路，结果相同。

期望 / 实际

• 期望：资源管理器弹出并定位（选中）该文件。
• 实际：完全不弹窗；请求被按成功应答，界面无任何失败提示。

最小复现（不依赖 DSH）

同上方英文节的脚本：windowsHide: true 不弹窗，去掉该参数立即弹窗并定位。

根因

runNativeCommand 对所有子进程硬编码 windowsHide: true。windowsHide 在 CreateProcess 的 STARTUPINFO 里成为 STARTF_USESHOWWINDOW + SW_HIDE。explorer.exe /select,<目标> 是委托式程序：新 explorer 进程把请求转交给常驻桌面 Shell 后以退出码 1 退出（runExplorer 已正确把 1 当作"已转交"）。最终创建窗口的 Shell 进程沿委托链继承 show 状态，于是定位窗口被创建为隐藏。用户视角就是静默无效果，而通信层应答成功。

该标志对 runner 同时执行的控制台工具（reg.exe、PowerShell 图标提取、wslpath 等）是正确的——只有委托式的 Explorer 调用不应强制它。

影响面

• revealNativePath（Explorer /select, 定位）：已实测损坏。
• win32 的 openNativePath 同样经 runExplorer，默认应用打开文件/目录预期受同一机制影响（依据共享代码路径推断，未单独实测）。
• 显式指定应用启动（openNativeFileApplication，第三方 GUI 应用）通常不受影响：这些应用自行创建窗口、忽略继承的 SW_HIDE（推断，未单独实测）。

建议修复

对 Explorer 的委托式调用不强制 windowsHide；控制台工具保持。见上方英文节的 diff（runNativeCommand 最小改动，或为 runExplorer 提供专用 runner）。

本地临时方案（供参考）

对内嵌运行时的 runNativeCommand 做了同样的一行特判补丁（事先完整备份 app.asar；补丁会被升级覆盖，官方修复前需重新应用）。

[PerryLink]

windowsHide: true 我核到了——而且你这个成因比我此前给同症状的解释更贴合交互式桌面

1. 那一行确实在

packages/util/native-command/src/runner.ts:27：

{ encoding: 'utf8', signal, windowsHide: true },

也就是 runNativeCommand 这个共享的 execFile 封装是无条件带上 windowsHide: true 的——而 revealNativePath / openNativePath（Explorer 委派）正是走它。⇒ 你说的"共享 runner 强制隐藏窗口"这一点成立。

2. 一条重要的对照：它补上了 README 没覆盖的情形

packages/util/native-command/README.md:112 记录过一个已知盲区：非交互式 Windows 会话（服务 / 无交互登录的计划任务）下 explorer.exe 不调关联、仍在约一秒后返回 1，于是"打开报告成功却什么都没打开"，并且明说没有回退实现。我在同症状的另一条帖子里（#7639 / #7698）就是按这条回答的。

但那条的前提是"非交互式会话"。 如果 #7842 报告的场景是正常交互式桌面（点击"显示文件位置"、有忙碌光标、约 0.5 秒后什么都没有），那 README 那条解释不了——而 windowsHide: true 这条能解释。

⇒ 所以我认为你这篇是同一症状的第二个成因，而不是重复报告。建议在正文里明确写一句"这是在交互式桌面会话下复现的"，这样维护者不会把它归到已知盲区里结掉。

3. 证据边界与一个决定性的 A/B

我要说清楚：我确认了 windowsHide: true 存在（代码层），但无法从这里验证它是否真的抑制了 Explorer 委派出去的那个窗口（那是 Windows/Electron 的运行时行为）。所以你的因果主张目前是强假设，不是已证结论。

建议做一个 30 秒的 A/B，把它变成结论：临时把 runner.ts:27 的 windowsHide: true 去掉（或改成可配置），用同一份构建、同一个文件、同一次点击再试一次：

• 窗口出现了 ⇒ 因果成立，你的报告可直接定案；
• 仍然不出现 ⇒ 说明 windowsHide 不是决定因素，那就回到 README 那条盲区或其他路径。

这个 A/B 的成本极低，而它能把"我怀疑是这行"直接变成"就是这行"。

4. 版本提醒

你写的是 Desktop 0.1.7-rc.2，就是当前最新（tag dsh-v0.1.7-rc.2）⇒ 不用先升级。⚠️ 只是别把核换成 npm 的 latest（仍停在 0.1.5-rc.3，更旧）：

npm i -g @deepseek-ai/dsh@next

[unifilitence]

A/B 已完成，因果成立（定案）——按你建议的路径做的，两层都验了：

1. 最小复现层（主帖 Minimal reproduction 一节，发布时就有）：同一命令行、同一 URL，唯一变量 windowsHide——hide=true 不弹窗，去掉立即弹窗并选中文件；
2. 真实 runner 层（你建议的 A/B）：把 0.1.7-rc.2 实机构建里该行编译产物的 windowsHide 改成仅对 explorer.exe 放行（其余调用不变），同一份构建、同一个文件、同一次点击：Explorer 窗口正常弹出并选中目标文件 ⇒ windowsHide: true 抑制 Explorer 委派窗口的因果成立，可定案。

该特判补丁已在本机生产形态运行（完整 asar 备份/校验/回滚俱全），无其他回归；如果官方愿意采纳，diff 就是主帖 Suggested fix 里那一行条件式。

环境：Windows 11 (build 26200)；官方安装版 Desktop 0.1.7-rc.2（tag dsh-v0.1.7-rc.2，与你说的一致）；A/B 在仅含该一处改动的工作副本上完成。

正文已按你的建议补充：受影响版本处注明"本报告在正常交互式桌面会话下复现（非服务/计划任务等非交互场景）"，与 README:112 的非交互盲区明确区分——避免被按已知盲区结帖。

再次感谢"已知盲区 vs 第二成因"的判定，这正是我们需要的。

[unifilitence]

同族发现（第三个表现形态）：下拉"打开方式"菜单里的默认应用条目，也是静默启动失败——机理一致，但启动载体不同。

复现：同一 UI（文件预览/交付物卡片的"更多打开方式"下拉），点列表里的默认应用条目（如 "Visual Studio Code (默认)"）→ 无窗口、无报错。同列表里的非默认条目（如 WPS Office，经典 GUI）正常弹出——所以是"有的条目能开、有的不能"，不是列表整体失效。

机理（对照主帖根因，一层之差）：

• 主帖的 reveal 路径：revealNativePath → explorer.exe /select,（委托）→ SW_HIDE 沿委托链传播。
• 本条：下拉条目点击 → openWorkspacePath({path, application: <handler id>}) → openFileApplication → win32 → windowsFileApplications 用 powershell.exe（被 runNativeCommand 无条件 windowsHide: true 隐藏）跑 C# DshFileAssociations::Open → handler.Invoke（shell 关联启动） → SW_HIDE 沿这条链传播到被启动的应用。
• 应用差异：Electron 应用（VS Code）尊重继承的 SW_HIDE（首窗口隐身）；经典 GUI（WPS）强制自绘窗口，不受影响——所以"有的条目能开、有的不能"。
• 顶层默认图标能正常打开：它走的是不带 application 参数的请求 → explorer.exe <path> 委托——与本讨论已确认的修复（解除 explorer 委托链的隐藏）是同一条路径。

建议修复：windowsFileApplications 的 powershell 载体是隐藏的，而 handler.Invoke 的关联启动会继承启动链的 show 状态——官方修这一族时建议一并考虑（例如 C# 侧显式以 SW_SHOWNORMAL 启动关联应用，或该载体不用 windowsHide）。

本地缓解（供参考，暂未部署）：前端对 default 条目省略 application 参数、改走 explorer.exe 委托（与顶层图标同路径）即可绕过；命名条目里的 Electron 应用仍会隐身，属上游可修范围。

环境：Windows 11 (build 26200)；Desktop 0.1.7-rc.2（官方安装版）。

[PerryLink]

恭喜定案——但你的修法覆盖不到你刚发现的第三个形态，这条得在合并前说清

1. 先说 A/B 结论

你跑完两层验证（最小复现 + 真实 runner 里只对 explorer.exe 放行 windowsHide）并得到"窗**口正常弹出并选中目标文件"，因果成立。这一条我接受，也谢谢你把实验做完——它把我原来的"强假设"变成了结论。

2. 但请注意一个修法范围问题

你现在的补丁是"仅对 explorer.exe 放行 windowsHide"。而你自己发现的第三个形态——下拉"打开方式"里的默认应用条目（如 Visual Studio Code (默认)）静默失败——走的不是 explorer.exe 那条载体。

我在源码里核到了一处旁证：packages/host/open-in-app/src/resolver.ts

export const launchDetachedApp: OpenInAppLauncher = (command, args, options) => …   // :74
…
launch: internals.launch ?? launchDetachedApp                                       // :148

⇒ 也就是说 "打开方式"这类入口选的是 launchDetachedApp（分离启动应用本体），而不是 runExplorer（委派给资源管理器）。两者是不同的启动载体：

载体	用于	你的补丁是否覆盖
runExplorer → explorer.exe /select,	"显示文件位置"（reveal）	✅ 覆盖
launchDetachedApp	"打开方式"下拉里的应用条目（含默认应用）	❌ 不覆盖

所以：如果只按当前补丁合并，你主帖的 reveal 症状会好，而你第三个形态仍然坏。 请在报告里明确写出这一点——这正好也解释了你观察到的"有的条目能开、有的不能"（非默认条目如 WPS 是经典 GUI 进程，不受影响）。

3. 建议的最终修法（一条覆盖两个载体）

不要在 runExplorer 里放行，而是把"是否隐藏窗口"变成调用方的参数：

• reveal 路径要显示（它靠委派出的窗口），detached 启动路径也不应隐藏（Electron 应用被 SW_HIDE 起就永远不显示）；
• 即：把 windowsHide: true 从 runner 的全局常量改为按调用点决定。这与你"只对 explorer 放行"是同一个方向，但放行的集合要包含两个载体，否则会漏。

4. 一条同日同族的线索（建议引用）

同一天有人报告：同一个 launchDetachedApp 还会把 ELECTRON_RUN_AS_NODE=1 泄漏给被启动的 Electron 应用，导致 VS Code / Cursor 等全部静默失败（#7811）。

⇒ 这两条合起来说明：launchDetachedApp 这条路径需要一次整体的策略梳理（窗口显示标志 + 环境变量清洗），而不是各打一个补丁。建议你在报告里引用它，并建议维护者把两处一起改——这能显著提高你这篇被一次性修掉的概率。

5. 版本

你验的是 0.1.7-rc.2，就是当前最新，无需再升级。⚠️ 只是别把核换成 npm 的 latest（仍停在 0.1.5-rc.3，更旧）。