[Bug] revealNativePath: explorer.exe /select, fails on Windows — path passed as a separate argv entry and as a percent-encoded file URL

[QingXP66]

Environment

DSH	0.1.5-rc.2
@deepseek-ai/dsh-native-command	0.1.5-rc.2
@deepseek-ai/dsh-api-session-controller	0.1.5-rc.2
@deepseek-ai/dsh-client-ui-deliverables	0.1.5-rc.2
OS	Windows 11 Pro, build 26100
explorer.exe	10.0.26100.8875
Node	v22.22.2

Summary

Clicking "Reveal in File Explorer" on a presented-file card does nothing visible.

The request succeeds end-to-end — HTTP 200, { opened: true }, no error in the UI — but no Explorer window opens on the target directory. In some runs Explorer instead opens the Desktop folder.

Root cause: revealNativePath() on Windows has two independent defects that both make the explorer.exe /select, invocation invalid, and the surrounding catch deliberately swallows Explorer's exit code 1, so the failure is indistinguishable from success.

Steps to reproduce

1. On Windows, have the agent present a file (any present tool call), so a file card appears in the conversation.
2. Open the card's overflow menu.
3. Click "Reveal in File Explorer".
4. Observe: no Explorer window appears at the file's directory (or the Desktop opens).

Reproduced with a path containing non-ASCII characters, e.g. E:\AI\AgentsWorkspace\DeepSeek_Harness\HalloWord\docs\browser-control-分享版.md.

Expected vs observed

Expected	Explorer opens the parent directory with the file selected
Observed	No window (or the Desktop folder opens)
HTTP response	200, body accepts the reveal
UI state	Reports success

Root cause

packages/util/native-command/src/path-opener.ts (module path-opener), Windows branch of revealNativePath:

if (manager === "explorer") {
    let windowsPath = path;
    if (platform === "linux") {
        const translated = await run("wslpath", ["-w", path], signal);
        signal.throwIfAborted();
        windowsPath = translated.stdout.replace(/[\r\n]+$/, "");
        if (windowsPath === "") throw new Error("wslpath returned no Windows path");
    }
    const target = pathToFileURL(windowsPath, { windows: true }).href.replaceAll(",", "%2C");  // defect 2
    try {
        await run("explorer.exe", ["/select,", target], signal);                              // defect 1
    } catch (error) {
        signal.throwIfAborted();
        if (!(error instanceof Error) || !("code" in error) || error.code !== 1) throw error; // masks the failure
    }
    return;
}

Defect 1 — /select, and the path are passed as two separate argv entries

runNativeCommand uses execFile without windowsVerbatimArguments:

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

Node therefore reconstructs a command line with a space between the two array entries:

explorer.exe /select, file:///E:/.../browser-control-%E5%88%86%E4%BA%AB%E7%89%88.md
                    ^^^^^^^ space here

explorer.exe requires /select,<path> to be one single argument. With the split, Explorer treats /select, as an empty target and falls back to opening the Desktop.

Defect 2 — the path is a percent-encoded file:// URL, not a native path

pathToFileURL(...).href escapes non-ASCII and spaces:

file:///E:/AI/.../docs/browser-control-%E5%88%86%E4%BA%AB%E7%89%88.md

Even when the argument is correctly merged into one, this escaped URL is not accepted by explorer.exe /select, (see variant c below). The native Windows path is required.

The pathToFileURL + replaceAll(",", "%2C") construction appears to have been introduced to handle paths containing commas. That intent is reasonable, but the chosen encoding introduced both defects above.

Evidence (measured on the reporting host)

Each variant was invoked with the exact same execFile semantics DSH uses (same argv array, same options), and the outcome was determined by enumerating Explorer windows through the Shell.Application COM object (.Windows().LocationURL) before and after.

Variant	argv passed	Resulting command line	Explorer window opened
a — current implementation	["/select,", fileURL]	explorer.exe /select, file:///...%E5%88%86...md	❌ C:\Users\csyt\Desktop (wrong)
b — proposed fix	[`/select,${windowsPath}`]	explorer.exe /select,E:\...\browser-control-分享版.md	✅ E:\...\HalloWord\docs (correct)
c — merged arg, file URL	[`/select,${fileURL}`]	explorer.exe /select,file:///...%E5%88%86...md	❌ no window at all

explorer.exe returned exit code 1 in all three variants, confirming that the exit code carries no signal here.

Why the bug is silent

The catch block intentionally accepts exit code 1 — per the doc comment, "Explorer exit 1 is accepted as a delegated handoff, not proof of selection." That assumption is correct in general; Explorer frequently exits 1 even on success.

The consequence, however, is that success and total failure are indistinguishable. The host route still returns success:

// packages/api/session-controller/src/index.ts
async openWorkspacePath(request, signal) {
    if (request.path.length === 0) throw new RemoteError("gateway/bad-request", ...);
    signal.throwIfAborted();
    try {
        if (request.action === "reveal") await this.revealPath(request.path, signal);
        else await this.openPath(request.path, signal);
        return { opened: true };
    } catch (error) { ... }
}

and the browser half only reacts to a non-ok response:

// packages/client/ui-deliverables/src/client/...
const response = await fetch(action === "open" ? url : `${url}&action=reveal`, { method: "POST" });
if (!response.ok) phase = response.status === 422 ? "nativeUnavailable" : failure;

So the UI reports success while nothing happens — the user has no signal to report or debug.

Proposed fix

 if (manager === "explorer") {
     let windowsPath = path;
     if (platform === "linux") {
         const translated = await run("wslpath", ["-w", path], signal);
         signal.throwIfAborted();
         windowsPath = translated.stdout.replace(/[\r\n]+$/, "");
         if (windowsPath === "") throw new Error("wslpath returned no Windows path");
     }
-    const target = pathToFileURL(windowsPath, { windows: true }).href.replaceAll(",", "%2C");
     try {
-        await run("explorer.exe", ["/select,", target], signal);
+        await run("explorer.exe", [`/select,${windowsPath}`], signal);
     } catch (error) {
         signal.throwIfAborted();
         if (!(error instanceof Error) || !("code" in error) || error.code !== 1) throw error;
     }
     return;
 }

Three changes:

1. Merge /select, and the path into one argv entry.
2. Drop pathToFileURL — pass the native Windows path. (The pathToFileURL import becomes unused and can be removed if nothing else needs it.)
3. Keep the exit-1 tolerance — that part is correct.

Open question: paths containing commas

The original %2C escaping suggests comma-containing paths were a known concern. With the single-argument form:

• Paths with spaces and non-ASCII characters: ✅ verified working (execFile quotes arguments containing spaces).
• Paths containing a comma: ⚠️ not verified — Explorer may split on the first comma after /select. Explicit quoting (/select,"C:\a,b.md") would be the safe form.

Suggest covering this in the fix and adding a regression test.

Not affected

The sibling menu item "Open with default app" is fine — it uses a different code path:

async function openWindowsPath(path, signal, run) {
    await run("powershell.exe", [
        "-NoProfile",
        "-Command",
        `Invoke-Item -LiteralPath ${powershellLiteral(path)}`
    ], signal);
}

Invoke-Item -LiteralPath has neither the /select, argument-splitting problem nor the URL-escaping problem. So the two menu items disagree:

Menu item	Status
Open with default app	✅ works
Reveal in File Explorer	❌ this bug

Suggested regression tests

For revealNativePath with an injected run spy, on platform: "win32":

1. Argument shape — assert run is called as ("explorer.exe", [/select,${nativePath}]): exactly one argument after the executable, and it starts with /select,.
2. No URL escaping — assert the argument contains the raw path and does not contain file:// or percent escapes.
3. Non-ASCII path — a path such as C:\docs\报告.md is passed through unchanged.
4. Comma path — pin the intended behaviour for C:\docs\a,b.md (quoted form).
5. Exit 1 tolerated, other codes propagated — unchanged from today's contract.

---

Reproduction script and a three-variant comparison are available on request.

[Meowrium]

Measurement check on defect 1 (two argv elements vs. one)

I reproduced this on @deepseek-ai/dsh@0.1.5-rc.1 / Windows 10 x64 / Node v26.3.0, and the split itself is not the cause. execFile hands argv to CreateProcess, which rebuilds the command line and re-quotes the elements that need it — so the documented /select,<path> form is produced by two elements whenever the path needs quoting:

invocation	result (target file exists)
['/select,', 'D:\AI\rv中文\plain.txt']	window at the parent dir, file selected (3/3)
['/select,', 'D:\AI\rv2 中文,#x\f.txt']	selected (space, comma and # all fine)
['/select,', <a path that does not exist>]	empty window (LocationURL = "")

That last row is most likely what looked like "Explorer opens the Desktop": an operand that parses but cannot be resolved produces an empty window, whereas a malformed operand (percent-encoded form, or quotes embedded in the element) makes Explorer fall back to Documents. That destination is a useful diagnostic — it separates "wrong operand" from "target not reachable".

What actually breaks your repro is the other two layers, both covered in #6629: (a) Explorer does not decode the percent-encoded file URL, so non-ASCII paths never resolve, and (b) windowsHide: true inside runNativeCommand hides Explorer's own window, so even a correctly parsed operand never shows up while the call still reports success (explorer exits 1, and revealNativePath swallows exactly that code).

One caveat on the fix shape so it does not regress: merging /select, and the path into a single element ('/select,' + windowsPath) only works while the path has no space — Windows then quotes the whole element, /select, included, and space-containing paths fall back to Documents. The two-element form is what keeps the path quoted while /select, stays unquoted; and the percent-encoded URI remains the only form that survives a comma without a space. Full matrix in #6629.