revealNativePath silently fails on Windows: Explorer window is created hidden, and non-ASCII paths are passed as percent-encoded file:// URLs

[bolide737]

Package: @deepseek-ai/dsh-native-command (verified on 0.1.5-rc.2)
Surface: the deliverable card's ▾ menu → "Show in File Explorer" / "在文件资源管理器中显示"
Platform: Windows only (the manager === "explorer" branch of revealNativePath)

Summary

Clicking "Show in File Explorer" on a delivered file appears to do nothing. The host request
succeeds, the UI settles on a success state ("Requested display in file manager"), and no Explorer
window becomes visible.

There are two independent defects in the same code path, and both must be fixed:

1. The Explorer window is created hidden. revealNativePath spawns explorer.exe directly
   through runNativeCommand, which hard-codes Node's windowsHide: true. That flag only hides the
   direct child. Elsewhere in the harness this is correct — openNativePath spawns
   powershell.exe, and Explorer is launched by PowerShell, so only the console is hidden. Here the
   direct child is explorer.exe, so the hidden flag lands on the window itself.

2. Non-ASCII paths are percent-encoded before being handed to /select,. The path is converted
   with pathToFileURL(windowsPath, { windows: true }).href, which percent-encodes every non-ASCII
   segment. explorer.exe does not percent-decode the /select, argument, so the target resolves
   nowhere and Explorer silently falls back to opening the Desktop.

Steps to reproduce

Use a workspace path containing non-ASCII characters (e.g. D:\工作文件\video.mp4).

Defect 2, minimal, no harness:

explorer.exe "/select,file:///D:/%E5%B7%A5%E4%BD%9C%E6%96%87%E4%BB%B6/video.mp4"   -> opens the Desktop
explorer.exe "/select,D:\工作文件\video.mp4"                                        -> opens the correct folder, file selected

Defect 1, via Node (this is what the harness does):

const { execFile } = require('node:child_process');
execFile('explorer.exe',
  ['/select,', 'file:///D:/%E5%B7%A5%E4%BD%9C%E6%96%87%E4%BB%B6/video.mp4'],
  { windowsHide: true }, () => {});

A CabinetWClass window is created but IsWindowVisible() returns false.

Via the product: deliver a file whose path contains non-ASCII, open the card's ▾ menu, choose
"Show in File Explorer".

Measured behaviour

Renaming a directory while a process holds it is not involved here; these are direct observations of
the argv/flag combinations, read back with EnumWindows + GetWindowText + IsWindowVisible.

argv	path form	resulting window
["/select,", url]	file:///D:/%E5%B7%A5... (percent-encoded CJK)	Desktop
["/select," + url]	file:///D:/%E5%B7%A5... (percent-encoded CJK)	Desktop
["/select," + path]	D:\工作文件\video.mp4	correct folder
["/select," + url]	file:///D:/工作文件/video.mp4 (not encoded)	correct folder
["/select," + url]	file:///C:/Windows/win.ini (ASCII)	correct folder
["/select,", path]	D:\工作文件\video.mp4	correct folder

spawn options	window visible
{ windowsHide: true }	false
{ windowsHide: false }	true

Note that splitting /select, and the path into two argv entries is not the cause — Explorer
re-joins them. Fixing only that changes nothing; the path form and the hidden flag are the defects.

explorer.exe exits with code 1 in every case above, including the successful ones, which is why the
existing error.code !== 1 tolerance is reasonable and should stay. The problem is that the exit code
carries no information about where the window landed, so openWorkspacePath returns
{ opened: true } and the card reports success regardless.

Root cause

node_modules/@deepseek-ai/dsh-native-command/lib/index.js, the explorer branch of
revealNativePath:

const target = pathToFileURL(windowsPath, { windows: true }).href.replaceAll(",", "%2C");
try {
    await run("explorer.exe", ["/select,", target], signal);
} catch (error) {
    signal.throwIfAborted();
    if (!(error instanceof Error) || !("code" in error) || error.code !== 1) throw error;
}

and in runNativeCommand:

execFile(command, [...args], {
    encoding: "utf8",
    signal,
    windowsHide: true          // <- hides explorer.exe's own window
}, (error, stdout, stderr) => { ... });

Suggested fix

1. Pass a single argv token containing a plain Windows path, not a URL:

   await run("explorer.exe", [`/select,${windowsPath}`], signal, { windowsHide: false });

   The %2C escaping exists only because a comma is meaningful inside a file:// URL; with a plain
   path it is unnecessary.

2. Give runNativeCommand a way to opt out of hiding, defaulting to today's behaviour so the console
   launchers are unaffected:

   const runNativeCommand = (command, args, signal, options = {}) => new Promise((resolve, reject) => {
       execFile(command, [...args], {
           encoding: "utf8",
           signal,
           windowsHide: options.windowsHide ?? true
       }, ...);
   });

   (An alternative worth considering is routing the reveal through the same openNativePath
   PowerShell path the working "Open locally" button uses, since that path is already proven correct
   for non-ASCII directories.)

With both changes applied locally, revealNativePath was verified end to end on Windows: the new
window is Visible = True, titled with the target folder, and Document.SelectedItems() contains the
requested file.

Additional note: the fix cannot be carried across versions

This deserves a mention because it determines how the fix can be delivered at all.

The only way to apply it today is to edit the installed file under
%LOCALAPPDATA%\npm-cache\_npx\<hash>\node_modules\@deepseek-ai\dsh-native-command\lib\index.js.
That <hash> directory is a function of the resolved dsh version: when the harness moved from
0.1.5-rc.1 to 0.1.5-rc.2 a new _npx directory appeared and the patched copy was silently
left behind in the old one — the bug came back with no signal to the user.

So the fix really needs to land upstream; until then every upgrade silently reverts it. If a supported
way to override a bundled package is out of scope, it would still help to document explicitly that
patching under _npx is unsupported and is discarded on version change.

Limitations of this report

• Verified on one Windows 11 (10.0.26100) machine with Node v24.21.0, against the installed
  0.1.5-rc.2 tree. Not tested on macOS/Linux (finder / directory branches are separate).
• The windowsHide behaviour was measured with CreateProcess's CREATE_NO_WINDOW; I did not trace
  further into how explorer.exe honours it.
• The patch described above is a local edit, not a submitted change: it has been tested only on the
  reporter's machine.

[mocilukalbj]

Independent WSL reproduction (WSL2, dsh 0.1.5-rc.2) — confirms defect 2, and isolates it to the percent-encoding. The WSL variant of this bug is reachable, and it reproduces as "the file manager only opens This PC".

On WSL the branch is entered through the isWsl() special case: nativeFileManager() returns "explorer" for platform === "linux" && isWsl(), so the deliverable card's ▾ menu → "Show in File Explorer" / "在文件资源管理器中显示" is offered on a Linux host process. wslpath -w already returns a correct UNC path (CJK preserved), and the same pathToFileURL(..., { windows: true }) line then rewrites it:

$ wslpath -w /home/<user>/projects/<project>/中文.csv
\\wsl.localhost\<Distro>\home\<user>\projects\<project>\中文.csv

explorer.exe ["/select,", "file://wsl.localhost/<Distro>/home/<user>/projects/<project>/%E4%B8%AD%E6%96%87.csv"]

Window-level matrix (Shell.Application.Windows() enumeration + HWND diff, no eyeballing; explorer.exe exits 1 in every case, success or failure, so the exit code carries no signal):

/select, target	form	resulting window
ASCII file (README.md)	file://wsl.localhost/... (current code)	correct folder ✅
ASCII target carrying ASCII percent-escapes (%20, %74-style)	current code	correct folder ✅
CJK file (中文.csv)	current code (percent-encoded %E4%B8%AD%E6%96%87…)	This PC — Document.Folder.Self.Path = ::{20D04FE0-3AEA-1069-A2D8-08002B30309D} ❌
same CJK file	raw UNC \\wsl.localhost\...\中文.csv	correct folder ✅
nonexistent target	file:// or UNC	This PC (fallback path, proves the silent fallback)

So the failure is not "Explorer rejects file://" — ASCII file:// targets resolve fine. It is specifically the percent-encoded non-ASCII target that Explorer cannot resolve, and a plain path fixes it (matching your table).

Three notes for the proposed fix, from the WSL side:

1. windowsHide is not a factor on WSL (it is a Windows-only flag and the host process is Linux), so the WSL symptom is defect 2 alone.
2. The fallback view differs by host: Desktop on your Windows setup, This PC under WSL — which is probably why the WSL variant gets reported as "it only opens This PC" rather than "nothing happens".
3. The same line also carries .replaceAll(",", "%2C"), and a comment states the URI form exists to preserve commas and whitespace in the path. If the fix switches to plain paths, a path containing a comma should be covered too (e.g. /select,"<plain path>"); we did not test that case.

The line is still present on master (packages/util/native-command/src/path-opener.ts, revealNativePath), so this is not fixed as of 2026-09-18.

[bolide737]

Correction to my own "Suggested fix" — and the comma case is worse than untested

Thanks for the WSL reproduction. Two things in it are worth more than a second confirmation:

• On WSL windowsHide cannot be involved, so that symptom isolates defect 2 alone. That is a stronger argument than my Windows evidence, where both defects were present at once.
• The fallback destination differs by host — Desktop on Windows, This PC under WSL. That explains a reporting split I would not have predicted: one root cause surfacing as "nothing happens" for one group and "it only opens This PC" for another.

You were right about the comma, and my proposed fix was wrong for a second reason too.

I had suggested gluing /select, and the path into a single argv element. Measured now, judging by the resulting folder (Document.Folder.Self.Path plus SelectedItems()) rather than the window title — a fallback still produces a window, so the title alone misleads:

argv	path	result
["/select," + p]	plain	correct folder
["/select," + p]	with a space	Documents
["/select," + p]	with a comma	Desktop
["/select,", p]	plain	correct folder
["/select,", p]	with a space	correct folder, file selected
["/select,", p]	comma, no space	Desktop
["/select,", p]	comma and space	correct folder
["/select,", p]	comma in the directory name	Desktop

1. Gluing is worse than I made it sound. With a space in the path, Node has to quote the argument, and the quote lands before /select, — "/select,D:\...\sp ace.txt" — which Explorer does not parse. My suggestion would have traded a non-ASCII bug for a space bug, and spaces are far more common. Withdrawn.

2. The right shape is the split one, ["/select,", windowsPath]: "/select, stays unquoted at the start and Node quotes only the path when it needs to. That fixes non-ASCII and keeps spaces working. My earlier line "splitting is not the cause" held only for the URL form; as a general claim it was wrong.

3. Your comma case fails outright. Explorer wants the path quoted even when it contains no whitespace, and Node's argv model cannot emit quotes around an argument that has none — literal quotes inside the argument are escaped to \" and are not accepted. The only form I got working was appending a trailing space to force quoting, which is a hack, not a fix.

4. That also means the split change is not a strict improvement on its own. The current file:// form does handle commas — I verified that file:///D:/.../c%2Clab/a%2Cb.txt opens c,lab with a,b.txt selected, so %2C is doing real work — and it handles spaces via %20. Switching to plain paths trades "non-ASCII broken" for "comma broken". Both need to be right before this line changes.

Where I would look next. Keep the path away from explorer.exe's command-line parser entirely — the same reason openNativePath already shells out to PowerShell instead of building an explorer command line. I tried SHOpenFolderAndSelectItems with the path handed over out of band; every call fell back to Documents, so I am not claiming it works — almost certainly my own P/Invoke rather than the API. Flagging it only as the direction I would try next, since it removes the quoting problem instead of working around it.

[bolide737]

Provenance, which I should have stated up front.

This report — and the correction above — were drafted by an AI coding agent running on my machine, during the session in which we diagnosed and fixed the problem locally. The reproduction steps, the measured tables and the source citations came from actually running the commands shown; the Limitations sections state what was and was not tested, and the SHOpenFolderAndSelectItems attempt is marked unverified because it genuinely did not work.

I reviewed it and stand behind the technical content, but please weigh it knowing how it was produced. The local patch in particular has been reviewed by nobody other than the agent and me.