[Bug] Windows: "Reveal in File Explorer" silently fails - two causes: percent-encoded file:// URL AND windowsHide: true hiding explorer's own window

[liangl1985]

Summary

On Windows, the deliverable card action Reveal in File Explorer silently does nothing for any path containing non-ASCII characters (e.g. Chinese). The sibling action Open with default application works fine. The failure is fully silent: the host call returns successfully and no error surfaces in the UI.

Environment

• DSH Desktop 2.0.10 (dsh-plugin-desktop)
• @deepseek-ai/dsh 0.1.5-rc.2
• Windows 11 zh-CN; WPS Office as the default handler for .docx
• Package: @deepseek-ai/dsh-native-command (used by dsh-client-ui-deliverables → sessionController.openWorkspacePath)

Root cause — TWO layers (both must be fixed)

Layer 1 — a percent-encoded URL is handed to explorer.exe

revealNativePath() in @deepseek-ai/dsh-native-command/lib/index.js:

const target = pathToFileURL(windowsPath, { windows: true }).href.replaceAll(",", "%2C");
await run("explorer.exe", ["/select,", target], signal);

pathToFileURL() percent-encodes non-ASCII segments, so the command actually runs as

explorer.exe /select,file:///E:/lina/0.%E4%BA%A7%E5%87%BA%E7%89%A9/2026-09-13-03_%E5%90%88%E5%90%8C.../report.docx

explorer.exe /select, does not percent-decode, so the target cannot be resolved.

Layer 2 (decisive) — windowsHide: true hides explorer's own window

runNativeCommand() in the same file hard-codes:

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

For powershell -Command Invoke-Item (used by "open with default application") this is harmless — the real application (e.g. WPS) is a separate process launched later, so hiding the PowerShell console costs nothing. But for explorer.exe /select, explorer itself is the hidden child process: the window never appears.

Worse, it does not error out: explorer still exits with code 1, which revealNativePath explicitly swallows via if (... error.code !== 1) throw error;. Net effect: the call succeeds silently and nothing happens — which is why this is so hard to diagnose from the UI.

Evidence

A. Layer 1 (URL encoding)

Invocation	Result
explorer.exe /select,file:///E:/lina/0.%E4%BA%A7... (current)	nothing happens
explorer.exe /select,"E:\lina\0.产出物...\x.docx" (native path)	File Explorer opens with the file selected

B. Layer 2 (windowsHide) — controlled comparison, same machine, same non-ASCII path

windowsHide	Observed
true (current)	no window at all
false	File Explorer opens with the file selected

Suggested fix (both layers)

// runner: let callers opt out of hiding (PowerShell path keeps hiding its console)
const runNativeCommand = (command, args, signal, options = {}) => new Promise((resolve, reject) => {
    execFile(command, [...args], {
        encoding: "utf8",
        signal,
        windowsHide: options.windowsHide !== false
    }, (error, stdout, stderr) => { /* unchanged */ });
});

// reveal: native path, single argv, visible window
const target = windowsPath;                 // no pathToFileURL()
await run("explorer.exe", ["/select," + target], signal, { windowsHide: false });

Verified locally

Both changes applied on DSH Desktop 2.0.10 / dsh 0.1.5-rc.2. Calling revealNativePath() directly with a Chinese path now opens File Explorer with the file selected, and the deliverable-card menu action works as well after restarting DSH. (Layer 1 alone is NOT enough — with only that change the action still does nothing, because of Layer 2.)

Impact

Every Windows user whose workspace path contains non-ASCII characters (Chinese user names / directory names — extremely common on zh-CN systems) loses the reveal action entirely, and it fails silently with a success return.

Related existing reports

• issue: 非常逆天的bug,中文路径选择截断. 目前看来bug可能有点多 #107 — 「非常逆天的bug,中文路径选择截断」
• 当项目文件夹名称同时包含英文和中文时，DSH无法选择其作为工作区 #4648 — 「当项目文件夹名称同时包含英文和中文时，DSH 无法选择其作为工作区」
• bug:自定模式在window下无法打开所载配置目录 #3463 — 「bug: 自定模式在 window 下无法打开所载配置目录」

If those share this root cause (paths passing through URL encode/decode chains), this analysis may serve as the common starting point.

[liangl1985]

这是我的DSH私人秘书找到的BUG，且授权她上传BUG，希望官方进行修复，省的我每次更新后都要自己修这个问题。莉娜棒棒的

[liangl1985]

Update (2026-09-14) — the original post only described the first cause. After applying a local fix for cause #1 alone, the action still did nothing; continued investigation found the decisive second cause: windowsHide: true in runNativeCommand() hides explorer.exe itself, so the window never appears while the call still returns success (explorer exits 1, which revealNativePath swallows).

The post body above now documents both causes, the controlled comparison (windowsHide true -> no window; false -> File Explorer opens with the file selected), and a fix covering both.

TL;DR: fixing only the percent-encoding will not resolve this issue.

[Meowrium]

Independent reproduction of both layers, plus the operand matrix a fix has to satisfy

@deepseek-ai/dsh@0.1.5-rc.1 (global npm install), Windows 10 x64, Node v26.3.0, @deepseek-ai/dsh-native-command@0.1.5-rc.1. Same symptom: the card shows 「已请求在文件管理器中显示」 / "Requested display in file manager" (presented.revealed) and no window appears — the route really does return 204, so the UI is telling the truth as far as it can see. I hit this from a delivery card in the Web UI and reproduced it by calling the module directly.

Layer 2 — mechanism and a readout that proves the window exists

windowsHide: true is not just "hide the console": Node sets STARTF_USESHOWWINDOW + wShowWindow = SW_HIDE in the child's STARTUPINFO, and Explorer creates its window through ShowWindow(SW_SHOWDEFAULT), i.e. it takes wShowWindow from its own startup info. The reveal window is therefore created hidden but real — and enumerable through Shell.Application:

(New-Object -ComObject Shell.Application).Windows() | ForEach-Object {
  [pscustomobject]@{ HWND=$_.HWND; Visible=$_.Visible; Url=$_.LocationURL; Sel=(($_.Document.SelectedItems()|ForEach-Object{$_.Path}) -join ';') }
}

A/B, identical path and identical argv, only the flag differs:

windowsHide	window exists	Visible	LocationURL	Selected
true (current)	yes	false	correct	correct
false	yes	true	correct	correct

So every click leaves one invisible window behind; a machine can accumulate several stuck ones. Worth remembering when someone reports "nothing happens, and eventually the desktop feels cluttered".

Upstream states this rule in another package: packages/host/open-in-app/src/catalog.ts documents "windowsHide is reserved for CLI adapters whose child process opens the visible GUI", leaves it undefined for every GUI entry, and sets true only for the headless GitHub Desktop cli.js adapter. The same comment notes that a bare explorer.exe <dir> spawn "does not reliably raise a window", which is why file managers there go through the shell open verb. The reveal path never got that treatment.

Layer 1 — operand form: one caveat on the suggested fix

Every cell measured against a file that exists, windowsHide: false so visibility is not a factor, previous window closed before each run, 3 repeats where marked:

/select, operand	ASCII	space	#	comma (no space)	CJK (3/3)	CJK+space+comma+#
percent-encoded file URI (current)	✓	✓	✓	✓	✗ empty window	✗ empty window
native path as its own argv element (['/select,', p])	✓	✓	✓	✗ empty window	✓	✓
'/select,' + p as a single element	✓	✗ Documents	✓	✗ empty window	✓	✗ Documents
/select,"<p>" (quotes inside the element)	✗	✗	✗	✗	✗	✗

Two things fall out of this:

• The failure shape identifies the layer. A malformed operand makes Explorer fall back to Documents; an operand that parses but names something it cannot reach gives an empty window (LocationURL = ""). Handy when triaging reports.
• '/select,' + windowsPath (the single-element form) fixes the CJK case but still breaks for space-containing paths: Windows quotes any element containing a space, quoting /select, along with the path, so C:\my files\x.txt lands in Documents. The two-element form keeps the path quoted while leaving /select, unquoted, which is what makes it survive spaces and commas. Conversely the encoded URI is the only form that survives a comma without a space, so pathToFileURL cannot simply be dropped.

Why CI cannot see either defect

packages/util/native-command/tests/path-opener.spec.ts pins exactly these argv forms and never observes a window: :158 (options.windowsHide === true), :334, :350 (WSL /mnt/c/work/报告.txt → file:///C:/work/%E6%8A%A5%E5%91%8A.txt — the broken encoding, asserted as correct), :409. Whichever fix is chosen, those assertions change, and a window-level check (the PowerShell readout above) is worth adding as an e2e.

What I applied locally and verified end to end

1. The Explorer launch gets its own runner with windowsHide: false; console-hiding stays on the shared runner for reg.exe / PowerShell probes.
2. Operand selection: a path containing anything outside the printable ASCII range → native path as its own argv element; pure ASCII → keep the encoded URI (comma-safe).

Verified after a dsh restart: Visible = true with the correct LocationURL and Selected for ASCII, space, #, comma, CJK and mixed paths, both by calling revealNativePath() directly and through the delivery-card menu. The only input that still needs a special case is ASCII-with-comma; calling SHOpenFolderAndSelectItems instead would remove the whole matrix, if you would rather not keep operand heuristics in the package.

(Cross-ref: #6638 reports the same failure and attributes one defect to the two-element argv split — my measurements say the split is not the cause; details in that thread.)

[liangl1985]

感谢你的独立复现与机制级证明 —— STARTUPINFO / SW_SHOWDEFAULT 那段读数是关键的缺失拼图；而「每次点击都会留下一个不可见窗口」这一点，我们完全没有测到。

你的操作数矩阵还抓出了我第一版修复里的一个缺陷：我最初用的是单元素形式（["/select," + p]），按你的测量，路径含空格时会落到 Documents。本机已改回两元素形式。

另一台机器上的本地确认（DSH Desktop 2.0.10 / @deepseek-ai/dsh 0.1.5-rc.2 / Windows 11 zh-CN），用你给的 Shell.Application 读数做校验：

• 修复形式 = 两元素原生路径 + windowsHide: false；
• 中文路径（含全角括号）→ Visible = true、LocationURL 正确、SelectedItems 命中目标文件；
• 含空格的路径（E:\DSH Desktop\...）→ 同样全部正确。

我没有采用「纯 ASCII 走编码 URI」这一支：两元素原生形式只在「纯 ASCII 且含逗号」这一种情形下失败，过于罕见，我更倾向保持代码简单；不过若维护者愿意接受一次 shell API 调用，SHOpenFolderAndSelectItems 看起来确实是更干净的终局。

窗口级 e2e 我完全同意 —— 你列的那四行 spec 在两种缺陷同时存在时都会通过，所以只有断言 Visible / LocationURL / SelectedItems，才真正卡得住这个 bug。