[Desktop 0.1.7-rc.2] File card "Show file location" is a silent no-op — root cause: windowsHide:true hides Explorer's window

[jk3320-ethan]

Summary

On DSH Desktop 0.1.7-rc.2, a delivered-file card's "Show file location" (显示文件位置) appears to do nothing: no Explorer window, no error, no toast. The same action works on the 0.1.5-rc.3 web engine on the same machine.

I traced it to a single process-creation flag and reproduced it with a controlled A/B test (below).

Root cause

runNativeCommand in @deepseek-ai/dsh-native-command creates the child process with windowsHide: true:

const runNativeCommand = (command, args, signal) => new Promise((resolve, reject) => {
  execFile(command, [...args], {
    encoding: "utf8",
    signal,
    windowsHide: true,          // <-- Explorer's window is created with SW_HIDE
  }, (error, stdout, stderr) => { /* ... */ });
});

runExplorer (the /select, / open-via-shell path) goes through that same runner, and it correctly tolerates Explorer's delegated-handoff exit code 1:

async function runExplorer(args, signal, run) {
  try { await run("explorer.exe", args, signal); }
  catch (error) { signal.throwIfAborted();
    if (!(error instanceof Error) || !("code" in error) || error.code !== 1) throw error; }
}

So: the child is created hidden, the hand-off exits 1 (which the code treats as success), the route returns 204, and the user sees nothing at all. The failure is completely silent from both the UI and any log.

Controlled A/B (same machine, same process tree, only the flag differs)

Script: spawn explorer.exe /select,<file> with Node execFile; detect the window via Get-Process explorer | MainWindowTitle.

	options	callback	window afterwards
A	windowsHide: true (what DSH does today)	err=1	none
B	flag omitted	err=1	appears

Both runs return exit code 1 — the delegated hand-off code — so the exit code is not the differentiator; the flag is.

Proposed fix

1. Do not set windowsHide for GUI hand-offs. For explorer.exe (and any launcher expected to show a window) omit the option, or make it per-launch: true for console tools, false for GUI launchers.
2. Check the sibling path too: launchDetachedApp forwards windowsHide: options.windowsHide to spawn, so the shell-open / editor / Git-GUI launches inherit the same hazard.
3. Consider surfacing a diagnostic when a hand-off reports success but no window appears — today the /api/present.open route returns 204 either way, so users cannot tell a silent failure from success.

Environment

OS	Windows 11 (zh-CN), standard non-elevated user, process integrity Medium
Affected	DSH Desktop 0.1.7-rc.2 (bundled Electron 44.0.0), GUI on http://127.0.0.1:19387
Works	web engine 0.1.5-rc.3 (dsh web), http://127.0.0.1:3080
Notes	Both share one DSH_HOME; no third-party plugins were involved in this diagnosis

What was ruled out first

• Routes exist. GET/POST /open-in-app/apps and /open-in-app/open return 401 without the GUI token while a bogus path returns 404; /api/present.open from the page returns 204.
• Not the PowerShell execution policy (Process = Bypass; a .ps1 runs fine).
• Not a machine-wide GUI hand-off problem: spawning explorer.exe "<dir>" from the same session opens a window (verified via the process's MainWindowTitle).
• Not the empty app list. The card menu also shows "cannot obtain application list" (无法获取应用列表), but @deepseek-ai/dsh-host-open-in-app's README documents that the catalog is fixed at build time and "the package does not enumerate an unrestricted OS application list" — that line is expected, and the reveal action does not depend on it.
• Not a profile misconfiguration: reproduced with a clean profile and no user patch layer.

Why the web engine works and the desktop engine does not

Not fully explained. Both run the same plugin code, so the likely difference is the parent process context (the desktop host is Electron; the web engine is a console Node process) affecting the STARTF_USESHOWWINDOW / SW_HIDE semantics of the child. The A/B above was measured in the desktop process tree, which is where the bug is visible. I did not test the same A/B under the web host, so I am reporting this as an open question rather than a claim.

Happy to run any additional probe you specify, or to collect a specific log.