Windows: revealNativePath silently reveals nothing — windowsHide: true hides the Explorer window it spawns

[1574919552]

Title

Windows: revealNativePath silently reveals nothing — windowsHide: true hides the Explorer window it spawns

Affected

@deepseek-ai/dsh-native-command@0.1.5-rc.3, still present in 0.1.7-rc.2 (published 2026-09-24; verified by
downloading the published tarball and reading lib/index.js).

Environment: Windows 10 19045, Node 24.15.0, dsh@0.1.5-rc.3, dsh web.

Symptom

Deliverables card → menu → "Show in File Explorer" reports success (the card shows
"已请求在文件资源管理器中显示" / "Requested display in file manager", i.e. POST /api/present.open?...&action=reveal
returned 204), but no Explorer window appears.

Root cause

runNativeCommand spawns every host command with windowsHide: true
(lib/index.js:17-22 in 0.1.5-rc.3; lib/index.js:18-37 in 0.1.7-rc.2). On Windows Node maps that to
STARTUPINFO.wShowWindow = SW_HIDE (plus CREATE_NO_WINDOW). That is the right default for the console helpers
this runner was written for (reg.exe, powershell.exe, wslpath), but explorer.exe is a GUI process: the
window it creates exists yet is never shown.

Measured on the same command with only that flag changed:

spawn options	new window	IsWindowVisible
windowsHide: true	created (found via Shell.Application.Windows())	false
windowsHide: false	created	true

The process starts and exits normally, so the route reports success.

Repro (self-contained; opens at most 2 windows)

Add-Type -Namespace W -Name U -MemberDefinition '[DllImport("user32.dll")] public static extern bool IsWindowVisible(System.IntPtr hWnd);'
$target = 'file:///C:/Windows/win.ini'
node -e "require('child_process').execFile('explorer.exe',['/select,','$target'],{windowsHide:true},()=>{})"
Start-Sleep 4
(New-Object -ComObject Shell.Application).Windows() |
  Where-Object { $_.LocationURL -eq 'file:///C:/Windows' } |
  ForEach-Object { "{0} visible={1}" -f $_.HWND, [W.U]::IsWindowVisible([System.IntPtr][int64]$_.HWND) }

The window is present with visible=False; repeat with {windowsHide:false} and it reports visible=True.

Secondary issue that makes the failure silent

runExplorer accepts any explorer.exe exit 1 as a successful delegated handoff
(lib/index.js:233 in 0.1.5-rc.3; lib/index.js:146 in 0.1.7-rc.2). A genuine failure therefore also returns 204
and the UI claims success. Distinguishing real failures (or at least logging stderr) would have surfaced this bug
immediately instead of presenting it as success.

Suggested fix

Give the runner a per-call override, and keep the GUI launcher visible:

-const runNativeCommand = (command, args, signal) => new Promise((resolve, reject) => {
+const runNativeCommand = (command, args, signal, options = {}) => new Promise((resolve, reject) => {
 	execFile(command, [...args], {
 		encoding: "utf8",
 		signal,
-		windowsHide: true
+		windowsHide: true,
+		...options
 	}, (error, stdout, stderr) => {

then at the explorer.exe call site — in 0.1.7-rc.2 there is now exactly one, inside runExplorer, which serves
both open and reveal:

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

In 0.1.5-rc.3 the site is await run("explorer.exe", ["/select,", target], signal);.
Alternatively, route explorer.exe through the visibility policy dsh-host-open-in-app already applies
(launchDetachedApp passes windowsHide: options.windowsHide, false for GUI adapters) — the codebase has the
concept; only the generic runner lacks it.

Scope

Windows only — macOS open -R and Linux xdg-open are unaffected. In 0.1.7-rc.2 the blast radius is wider:
openWindowsPath now also goes through runExplorer, so "open in default application" would open invisibly as
well, not just "show in file manager".

Why it may have been missed

The comments assume explorer.exe hands the request to the already-running desktop process and exits 1; on that
path the window is created by the shell process and stays visible. The hidden-window case needs the spawned
explorer.exe to create the window itself, as it does on this machine. Linux/macOS CI would not exercise it.

Unrelated but worth noting: the new explorerTarget() escaping work in 0.1.7-rc.2 (commas, equals signs,
non-ASCII percent-escapes, \\?\ prefixes) is exactly the kind of care this call site needs — the command line
was never the problem.

[andrii-dolzhenko]

Your diagnosis looks correct.

The visibility issue has also been independently reproduced in earlier reports: revealNativePath() sends explorer.exe through the shared native-command runner, while that runner applies windowsHide: true. For console helpers that default makes sense, but for Explorer it can create a real window that remains hidden.

I think the narrowest fix is the one you suggested: keep windowsHide: true as the runner default, allow a per-call override, and invoke explorer.exe with windowsHide: false.

That avoids changing the behavior of reg.exe, PowerShell, wslpath, etc. while fixing the one caller whose GUI is actually meant to be visible.

I would also treat the unconditional acceptance of Explorer exit code 1 separately. Even if exit 1 is commonly the delegated-shell path, accepting every such exit as success makes genuine failures indistinguishable from a successful handoff. At minimum, logging stderr/context there would make this much easier to diagnose.

So yes — this looks like a Windows reveal-path bug rather than a path-resolution problem, and a per-call visibility override seems like the minimal fix.