[Bug] "Reveal in File Explorer" creates a permanently invisible window on Windows

[pig1and1]

Summary

On Windows, the Reveal in File Explorer action (the file-card menu item that hands the
path to session-controller's reveal request -> revealNativePath) creates an Explorer
window that is permanently invisible. No error is surfaced anywhere -- the UI simply
appears to do nothing, so it reads as a dead button.

Affected

• Package: @deepseek-ai/dsh-native-command
• Files: packages/util/native-command/src/path-opener.ts (revealNativePath),
  src/runner.ts (runNativeCommand)
• Platform: Windows (win32) only
• Version: reproduced on dsh 0.1.5, commit c291e7961a

Root cause

revealNativePath spawns Explorer through the shared runner, which hard-codes
windowsHide: true because it was built for console tools:

export const runNativeCommand: NativeCommandRunner = (command, args, signal) =>
  new Promise((resolve, reject) => {
    execFile(command, [...args], { encoding: 'utf8', signal, windowsHide: true }, ...)
  })

// path-opener.ts -- the explorer branch
await run('explorer.exe', ['/select,', target], signal)

On Windows windowsHide: true makes libuv pass STARTF_USESHOWWINDOW with SW_HIDE, so the
child's first window is created hidden. For a console tool that is exactly right. For a GUI
launcher whose entire purpose is to show a window, it is fatal.

Evidence

After triggering the reveal, enumerating shell windows via
Shell.Application.Windows() and querying the window manager:

hwnd=331036  class='CabinetWClass'  title='meta - File Explorer'  (title is OS-localized)
             rect=(995,226)-(2134,867)   <- on-screen, inside a 2560x1440 desktop
             IsWindowVisible = False     <- the only wrong thing about it

The window exists, with the right class, the right title and on-screen coordinates -- it is
simply not visible.

Controlled A/B on the same machine, isolated in a standalone Node script that does not
involve DSH at all (so this cannot be a plugin or composition issue):

spawn options	new windows	of which visible
{ windowsHide: true }	1	0
{ windowsHide: false }	1	1

Both cases return exit code 1, which the current code already tolerates as "Explorer delegated
to the existing desktop process" -- so the failure is silent by construction.

Why it is easy to misdiagnose

1. Counting shell windows is not enough. Both spawn options produce exactly one new shell
   window, so windowsHide looks innocent unless you check IsWindowVisible. This cost me a
   full wrong conclusion before I re-tested visibility.
2. SetForegroundWindow also returns False, which makes it look like the well-known
   "background process cannot steal foreground" limitation. That is a symptom, not the cause:
   a hidden window cannot be foregrounded. Chasing foreground-lock workarounds goes nowhere.

Suggested fix

Give Explorer a runner that does not hide windows, while keeping the hiding runner for the
console tools (the PowerShell opener, registry probes, wslpath):

export const runNativeCommandVisible: NativeCommandRunner = (command, args, signal) =>
  new Promise((resolve, reject) => {
    execFile(command, [...args], { encoding: 'utf8', signal, windowsHide: false }, ...)
  })

// path-opener.ts -- the explorer branch only
await (internals.run ?? runNativeCommandVisible)('explorer.exe', ['/select,', target], signal)

Keeping the internals.run ?? indirection preserves the existing test seam
(PathOpenerInternals.run), so adapter tests that inject a runner keep working unchanged.

Verified after the change

The same host-side call, from inside the running host process:

new windows: 1   of which VISIBLE: 1

whereas the pre-patch windows in the same session were all visible=False. The user then
confirmed that clicking the menu item now brings the Explorer window up on screen.

Environment

• Windows 11, 2560x1440
• Node from C:\Program Files\nodejs\node.exe
• dsh 0.1.5 (c291e7961a), profile web
• No third-party plugin involved: the reproduction used a standalone Node script, and a search
  across all installed profile plugins found no reference to openPath / revealPath /
  nativeOpen / session-controller.

[PerryLink]

Verified against the checkout at commit c291e7961a (= dsh 0.1.5) and reproduced independently on Windows 11 (build 26200, Node 22.22.3). The root-cause analysis is correct, and the suggested fix is the right minimal change. Details below.

Confirmed in the source

• packages/util/native-command/src/runner.ts:27 hard-codes windowsHide: true in the shared runNativeCommand, built for console tools (as its README says: the option suppresses the transient console window).
• packages/util/native-command/src/path-opener.ts:250 runs explorer.exe ['/select,', target] through that same runner. The WSL branch shares this exact call (it sits inside the manager === 'explorer' branch after wslpath translation), so the fix covers WSL-hosted reveals too.
• path-opener.ts:251-255 tolerates exit code 1 as "delegated to the existing desktop process" — confirmed: in my tests both spawn variants exit 1, so the failure is silent by construction, exactly as you said.
• The PathOpenerInternals.run test seam survives your diff (internals.run ?? runNativeCommandVisible), so every adapter test that injects a runner keeps working unchanged.
• The only GUI spawn routed through this runner is the Explorer reveal: the PowerShell opener's Invoke-Item hands off via ShellExecute (its own show state), and open-in-app probes only console commands with it. open-in-app already makes the same per-launch distinction elsewhere (OpenInAppLaunch.windowsHide, unset = visible) and its catalog comment even notes that a direct explorer.exe spawn "does not reliably raise a window".

Mechanism — confirmed, one small precision fix

Node's windowsHide maps to libuv's UV_PROCESS_WINDOWS_HIDE. In libuv's deps/uv/src/win/process.c (Node v22.x), STARTF_USESHOWWINDOW is set on the STARTUPINFO unconditionally; windowsHide flips wShowWindow from SW_SHOWDEFAULT to SW_HIDE (and with piped stdio also adds CREATE_NO_WINDOW, which CreateProcess ignores for GUI-subsystem apps like explorer.exe). So the operative propagation is exactly SW_HIDE through STARTF_USESHOWWINDOW — the show state then travels through Explorer's instance handoff to the new window. Your description is functionally right; pedantically it's the wShowWindow value that differs, not the presence of the flag.

Independent reproduction (standalone Node script, no DSH involved)

Enumerating Shell.Application.Windows() and checking IsWindowVisible/WS_VISIBLE, same A/B you ran:

spawn options	new windows	of which visible	exit code
{ windowsHide: true }	1	0	1
{ windowsHide: false }	1	1	1

The hidden window had the correct title (the target's folder), an on-screen rect (1042,1689)-(2173,2423), and stayed IsWindowVisible=False / WS_VISIBLE unset for the full 45 s I watched it — "permanently invisible" confirmed, and each repeated click adds another one. I also reproduced SetForegroundWindow → False on a visible window, confirming your warning that it is a symptom-level red herring (a hidden window can't be foregrounded, but a visible one can also refuse, so chasing the foreground lock goes nowhere).

Fix

Your minimal fix is correct and safe: windowsHide: false is the Node default, and explorer.exe has no console window to flash, so a visible runner can only help. Two small suggestions:

1. Add a regression test: the existing execFile seam in packages/util/native-command/tests/path-opener.spec.ts (the "uses the native runner for a file-manager handoff" test, plus the exit-1 tests) can assert options.windowsHide === false for the explorer.exe call, mirroring the existing windowsHide === true assertion at spec line 158.
2. Cosmetic: instead of duplicating the runner body, have runNativeCommandVisible share an internal implementation parameterized by windowsHide — your version is fine as-is.

Not verified / caveats

• The post-fix end-to-end click (menu item → window appears) is your environment; I verified only the deciding variable (spawn flag → window visibility), which the A/B above covers.
• Only tested on Windows 11 build 26200 here; the reporter's build differs. The propagation lives in explorer.exe's handoff and could vary by build, but it reproduced on a second, different build, which strengthens the report.
• openNativePath (the powershell.exe Invoke-Item branch) was not re-tested here; it should be unaffected because ShellExecute carries its own show command rather than the PowerShell process's STARTUPINFO.
• Until a fixed release ships there is no clean in-app workaround; the invisible windows accumulate per click and go away on Explorer restart / sign-out (not verified).

[pig1and1]

Thanks for the detailed verification -- and for the mechanism correction. You are right: libuv sets
STARTF_USESHOWWINDOW unconditionally and windowsHide flips wShowWindow from SW_SHOWDEFAULT
to SW_HIDE; it is that value which propagates through Explorer's instance handoff, not the
presence of the flag. I have corrected my wording.

Filling in the items you marked as not verified.

Reporter's environment -- and a correction to the "two builds" argument

• Windows 11 Pro, build 26200
• Node v24.19.0
• dsh 0.1.5 (c291e7961a)

One correction: the Windows build here is also 26200 -- the same as yours. So this does not
currently constitute reproduction on two different Windows builds. What is cross-environment is
the Node version (yours 22.22.3, mine 24.19.0), and that is where the libuv code path in
question actually lives. The evidence still holds, but for a narrower reason than "two builds", and
I would rather the record said so.

Post-fix end-to-end click

Verified two ways on this machine.

1. Host-internal call, same binary switch. Invoking sessionController.revealPath(path, signal)
   from inside the running host process (a temporary dynamic Cordis probe), then enumerating
   Shell.Application.Windows() and checking IsWindowVisible:

   host build	new windows	of which visible
   pre-patch	1	0
   post-patch	1	1

   Same entry point, same machine, only the loaded module changed -- so the fix is confirmed at the
   exact call path the UI uses, not merely at the spawn-flag level.

2. Real GUI click. After restarting the host so it reloaded the patched build (the old module
   was cached in the long-running process), the reporter clicked the menu item and the Explorer
   window appeared on screen.

The accumulated invisible windows can be cleaned up without touching Explorer

You noted they "go away on Explorer restart / sign-out (not verified)". Related observation from
this side: the user cannot close them at all -- they are absent from the taskbar and unreachable
via Alt+Tab, so they simply pile up. Seven had accumulated here before I intervened.

They are closable programmatically, with no Explorer restart:

$shell = New-Object -ComObject Shell.Application
foreach ($w in @($shell.Windows())) {
  if (-not [WinApi]::IsWindowVisible([IntPtr][int64]$w.HWND)) { $w.Quit() }
}

That closed all seven and left the visible one untouched. Not worth shipping as a feature, but a
better answer than "restart Explorer" if a user asks how to get rid of them.

Your two suggestions

1. Regression test -- agreed, and your pointer to the existing windowsHide === true assertion
   at path-opener.spec.ts:158 is exactly the right thing to mirror for the explorer.exe call.
2. Share one parameterized runner body -- agreed. Duplicating the body was the expedient form of
   the patch; a single implementation parameterized by windowsHide is cleaner, and I would take
   that over the copy.

Foreground behaviour -- confirming your red herring, from the other side

You reproduced SetForegroundWindow -> False on a visible window, which matches what I saw on the
hidden ones (all False). So the practical shape after the fix is: the window becomes visible and
present in the taskbar, but does not raise itself. That is enough for the click to feel like it
worked -- but worth knowing if someone reports "it works, I just have to hunt for it".

[PerryLink]

All three accepted — thanks for filling in the items I left open:

• Two-builds claim: agreed, too strong. Both are build 26200; the cross-environment variable is the Node version (22.22.3 vs 24.19.0), which is also the better argument since the libuv code path in question lives in Node.
• Your host-internal A/B at the real call path (pre 0/1 → post 1/1) plus a real GUI click closes the only gap I couldn't verify, and it's stronger evidence than my spawn-level A/B.
• The Shell.Application enumeration/quit snippet is the right answer for the piled-up invisible windows — better than "restart Explorer".

Agreed on both code suggestions (mirror the path-opener.spec.ts:158 windowsHide assertion for the explorer call; one parameterized runner body). Nothing further needed from my side.

[pig1and1]

Implementing the fix for anyone who lands here later.

runNativeCommand hard-codes windowsHide: true, and on Windows libuv sets
STARTF_USESHOWWINDOW unconditionally while windowsHide flips only the
wShowWindow value it passes -- SW_SHOWDEFAULT becomes SW_HIDE. So Explorer
was spawned with its first window already hidden.

The change adds a second runner that omits windowsHide and uses it for the
Explorer invocation only; console tools (the PowerShell opener, registry probes,
wslpath) keep the hidden runner, since they genuinely need their console
suppressed. The internals.run test override still wins, so adapter tests keep
their injected runner.

packages/util/native-command/src/runner.ts       + runNativeCommandVisible
packages/util/native-command/src/path-opener.ts    revealNativePath uses it

Measured with a bare Node script that loads no DSH plugin:

spawn options	windows created	of which visible
windowsHide: true	1	0
windowsHide: false	1	1

After the change revealNativePath creates a window with IsWindowVisible = true.

One note for whoever picks this up: counting windows is not enough. The count is
identical either way -- only visibility differs -- so IsWindowVisible is the
check that actually answers "did the window appear".

Branch on my fork (not a PR; I read that external PRs are not being taken right
now):

pig1and1@e4fe5b9

Leaving it here as reference for whenever you get to it.

[pig1and1]

One more detail worth adding, since it changes what the fix implies elsewhere.

A child that reads its own STARTUPINFO reports both effects of windowsHide at once:

spawn options	console	dwFlags	wShowWindow
windowsHide: false	inherited	0x101	10 (SW_SHOWDEFAULT)
windowsHide: true	none	0x101	0 (SW_HIDE)

So STARTF_USESHOWWINDOW really is unconditional and windowsHide flips only
wShowWindow -- but libuv also passes CREATE_NO_WINDOW, which is why the child
loses its console entirely.

That second half matters for anyone reaching for windowsHide: true to silence a
popup: children created without a console die under the Windows ACL sandbox with
STATUS_DLL_INIT_FAILED (0xC0000142) during DLL initialization. That is documented
on your side already (packages/sandbox/sandbox-windows-acl/README.md), and
discussion #1564 reaches the same conclusion -- keep dwCreationFlags = 0 and hide
via STARTF_USESHOWWINDOW + SW_HIDE instead.

The rule the two halves add up to, and the one open-in-app/src/catalog.ts already
states:

windowsHide is reserved for CLI adapters whose child process opens the visible GUI.

So ask two questions: does the child open a window itself (Explorer, an Electron app)?
never hide it. Is it just a CLI pipe (collecting output, or its own child opens the
GUI)? hiding it is correct.

Two other projects hit the same thing in the same month, in both directions:
omdsh-dev/dsh-open-in-vscode#4 (a GUI child hidden -- the window never appears) and
chenkai2/dsh-daemon#1 / anthropics/claude-code#89072 (a console child not hidden,
because the parent had no console to pass down, so Windows allocates a new visible one).