[Bug] revealNativePath does nothing on paths containing non-ASCII characters (e.g. CJK) - and reports success

[ryanbihai]

TL;DR — revealNativePath hands explorer.exe /select, a percent-encoded file:/// URL where the switch expects a filesystem path. Explorer resolves that fine for purely ASCII paths, but for a path containing non-ASCII characters (CJK) it does nothing at all — no window, no error, no dialog. Since explorer.exe exits 1 even on success, that silent no-op is swallowed by the existing catch, the route answers 204, and the Web client reports success. Net effect: "Reveal in File Explorer" on a CJK path looks like it worked and nothing happens.

Environment

dsh	0.1.5-rc.2 (also checked 0.1.5-rc.3, 0.1.6-alpha.2, 0.1.7-alpha.2)
OS	Windows 11, system locale zh-CN
Package	@deepseek-ai/dsh-native-command → revealNativePath
Surface	Web client, deliverable card → "Reveal in File Explorer"

Where

The logic is byte-identical in every published version I checked — 0.1.5-rc.2 lines 228–234, 0.1.7-alpha.2 lines 239–245:

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;
}

For C:\示例目录\报告.md that produces

explorer.exe "/select," "file:///C:/%E7%A4%BA%E4%BE%8B%E7%9B%AE%E5%BD%95/%E6%8A%A5%E5%91%8A.md"

Steps to reproduce

1. Create a file at a path containing non-ASCII characters, e.g. %TEMP%\示例目录\报告.md.
2. Press "Reveal in File Explorer" on it (or invoke revealNativePath directly).
3. Nothing happens. No window, no error, HTTP 204, the client shows the success toast.

Repeat with a pure ASCII path (%TEMP%\plain\report.md) and it works — which is why this goes unnoticed in ASCII-only environments.

Measurements

Selection state read through UI Automation (SelectionItemPattern.IsSelectedProperty) rather than inferred, because Shell.Application's Document refuses FocusedItem/SelectedItems with DISP_E_NOTACOLLECTION. Each trial uses a brand-new directory so Explorer window reuse cannot confuse the result. A = the code above, B = ["/select,", nativePath].

file name	A (upstream file:/// URL)	B (native path)
plain.md	opens + selects ✅	opens + selects ✅
spa ced.md	opens + selects ✅	opens + selects ✅
pl,ain.md	opens + selects ✅ (%2C works)	no window ❌
中文文件.md	no window ❌	opens + selects ✅
中文 文件.md	no window ❌	opens + selects ✅

A is consistent across five independent runs: 6/6 successes on ASCII-only names, 11/11 failures on any name containing CJK. Interleaving A and B with three repetitions each (to cancel the ordering effect described below) gives A 3/3 failures and B 3/3 opens on a CJK path.

Two separate defects

1. Correctness — non-ASCII paths never reveal. The percent-encoded URL form is not resolved by explorer.exe /select,. This is the common case for the users hit by it: any CJK project directory makes the feature a no-op. The same code path is used from WSL, after wslpath -w.

2. Observability — the failure is reported as success. explorer.exe returns 1 for both a successful handoff and a failure to resolve the path, and the catch deliberately treats 1 as success (the JSDoc even says "Explorer exit 1 is accepted as a delegated handoff, not proof of selection"). So handlePresentOpen returns 204, the client shows a success toast, and there is no log line, no non-2xx status, and no user-visible error anywhere. This is what made the bug expensive to diagnose — the user-visible symptom is "the button does nothing", and every instrument says it succeeded.

Suggested fix

The durable fix is to stop routing this through explorer.exe argument parsing at all and use the Shell API meant for it — SHOpenFolderAndSelectItems — which the package is already well placed to do, since it embeds and compiles C# for Windows file associations (WINDOWS_ASSOCIATIONS).

As a minimal interim change, keep the %2C substitution (it is load-bearing: a raw comma in the URL fails, verified 2/2, and a raw comma in a native path also fails 2/2) but stop percent-encoding non-ASCII:

// Only the comma is escaped: Explorer does not decode a UTF-8 percent-escape
// such as %E4%B8%AD, so the URL form silently no-ops on non-ASCII paths.
const target = `file:///${windowsPath.replaceAll("\\", "/").replaceAll(",", "%2C")}`;

What I could not verify

• Whether the interim fix above is complete. Individually I verified that the native path works for CJK (3/3 opens, 2/3 selections) and that %2C is required for commas, but I could not get a clean pass on the combination: Explorer coalesces rapid successive /select, invocations, so whichever variant runs later in a batch looks worse. That artefact is in my harness, not necessarily in the product — but it means I am proposing that line as a direction, not as a tested patch.
• Whether failing paths are code-page dependent. All measurements are from a zh-CN system; I did not test a non-Chinese Windows where the ANSI code page differs.
• A path containing % would become ambiguous under the interim fix (it would look like an escape), which is another reason to prefer the Shell API.

Happy to re-run anything or provide the matrix scripts if useful.

---

中文摘要：「在文件资源管理器中显示」对含中文的路径完全无反应（纯 ASCII 路径正常）。原因是 revealNativePath 把 pathToFileURL(...).href 这个百分号编码的 file:/// URL 传给了 explorer.exe /select,，而该开关期望的是文件系统路径；%E4%B8%AD 这类 UTF-8 转义不会被解析，于是 Explorer 静默什么都不做。又因为 Explorer 成功失败都返回 1，这个静默失败被现有的 catch 当作成功，接口返回 204，前端提示成功——所以现象是「点了没反应，但哪里都显示成功了」。五个版本的代码逐字相同。附了复现矩阵与两处缺陷说明。

[ryanbihai]

Follow-up after building a local fix — two refinements to the suggested fix above.

1. A naive swap to the native path regresses comma paths. ["/select,", nativePath] fails when the path contains a comma (2/2 trials), while the existing %2C URL form handles that case fine. So the , → %2C substitution should stay — it is load-bearing, not vestigial, and my first suggestion of dropping it in favour of a plain native path was wrong.

2. The narrowest change that keeps both working is to choose per path:

const target = windowsPath.includes(",")
	? pathToFileURL(windowsPath, { windows: true }).href.replaceAll(",", "%2C")
	: windowsPath;

With that, the function hands explorer.exe a native path for C:\示例目录\报告.md and C:\项目\中文 报告.md, and keeps the %2C URL form for C:\proj\pl,ain.md. Checked deterministically by injecting the function's own internals.run seam and printing the argv, so no GUI timing is involved.

A caveat that argues for the Shell API: a path containing both a comma and non-ASCII characters is served by neither form and stays broken.

One thing worth flagging for anyone reproducing this: explorer.exe coalesces rapid successive /select, invocations, so in a batch the variant that runs later tends to look worse. In one of my runs the patched form and the upstream form produced byte-identical argv for a comma path and still disagreed on the outcome. Interleaving the two variants and alternating their order is what made the numbers reproducible; single-pass batches were not.

Selection was read via UI Automation (SelectionItemPattern.IsSelectedProperty) throughout, since Shell.Application's Document object refuses FocusedItem/SelectedItems with DISP_E_NOTACOLLECTION and explorer.exe's exit code is 1 for both success and failure.