Reveal-in-file-manager reports success while the Explorer window stays invisible

[gkpsdsg]

Status: RESOLVED — fixed locally by the reporter on 2026-09-23; see "Resolution" at the
end. Root cause corrected on 2026-09-25: the invisible window is caused by
windowsHide: true on the spawned explorer.exe, not by the token-restricted sandbox.
The earlier attribution in this report was measured from inside a sandbox child and confused
the test environment with the cause; the A/B measurement under a plain user token is in
"Correction" below. The fix is unchanged, and the fix still matters (the bug reproduced on
0.1.7-rc.2).

Summary

With the Windows ACL sandbox active (workspace-write, the default), revealing a file in Explorer
from the GUI ("open" → "show in file manager") reports success and does nothing visible. The
folder window is created, the target file is even correctly selected inside it, but the window is
never shown, and the process exits with code 1 — which the caller accepts as a successful handoff.

The user sees a success toast ("已请求在文件管理器中显示" / "requested to show in file manager") and
no window.

Environment

• Windows 11 (Chinese locale), Windows PowerShell 5.1
• Originally reported on @deepseek-ai/dsh 0.1.5-rc.3; re-verified on 0.1.7-rc.2 (2026-09-25),
  where the reveal is still broken and the same fix is still required
• dsh web GUI, profile web, file policy workspace-write

Reproduction

1. Start dsh web with the default workspace-write policy.
2. Ask the agent to create any file in the session workspace.
3. In the GUI, use the file card's menu → show in file manager.
4. Observe: the toast reports success; no Explorer window appears (check the taskbar — nothing was
   added there either).

What was measured (2026-09-23)

EnumWindows + Shell.Application were used to inspect the windows after the reveal. Three windows
for the same folder existed:

Window	Created by	Visible	SelectedItems()
HWND=3148338	COM Shell.Application.Explore	True	the target file
HWND=197996	explorer.exe /select, (the DSH path)	False	the target file
HWND=329818	explorer.exe /select, (the DSH path)	False	the target file

So the reveal is doing its job — the folder is open and the file is selected — it just leaves the
window hidden.

Correction (2026-09-25): the cause is windowsHide, not the restricted token

The 2026-09-23 investigation ran its probes from a sandbox child and attributed the invisible
window to that child's restricted token. A controlled A/B under the same token the host actually
uses (a plain, unrestricted user token) shows that attribution was wrong: upstream's code produces
the invisible window there too.

Method: two separate scratch folders, two probe files, and revealNativePath imported from the
unpatched lib/index.js.orig versus the patched lib/index.js, in one process, same token.
Window state read back through Shell.Application:

Stage	node exit	Window	Visible	Selected	Foreground window
baseline	—	—	—	—	Chrome
upstream index.js.orig	0 ("success")	hwnd=655550 for _reveal_a	False	probe.txt	still Chrome
patched index.js	0	new hwnd=460902 for _reveal_b	True	probe.txt	_reveal_b - 文件资源管理器

The mechanism is in the shared runner, runNativeCommand
(@deepseek-ai/dsh-native-command/lib/index.js):

execFile(command, [...args], { encoding: "utf8", signal, windowsHide: true }, …)

windowsHide: true is correct for a helper that should never flash a console — but
explorer.exe /select, is not such a helper: the folder window it hands to the shell is created as
part of a process launched hidden, and it stays hidden. Explorer then exits 1, and runExplorer
deliberately accepts exit 1 as a delegated handoff, so nothing surfaces.

That single flag explains both halves of the bug: the window is never shown, and the caller is told
the handoff succeeded.

Why the COM route is immune

Shell.Application is hosted by the already-running explorer.exe, so the window is created by
that process and our hidden-child launch flag never applies to it. That is why routing the reveal
through COM displays the window, and why the sandbox token was never the deciding variable.

(Side note, measured on 0.1.7: from inside the sandbox the COM route cannot be used — the child
runs at Low integrity, New-Object -ComObject Shell.Application fails with "拒绝访问", and piped
stdio to a child fails with spawn EPERM. This does not affect the real path: the reveal is served
by the host process — HTTP route → dsh-client-ui-deliverables →
ctx.sessionController.openWorkspacePath → revealNativePath, see
dsh-api-session-controller/lib/index.js.)

Root cause

@deepseek-ai/dsh-native-command, revealNativePath(). On 0.1.7-rc.2 (unchanged in substance from
0.1.5-rc.3, the encoding helper around it was refined):

if (manager === "explorer") {
    let windowsPath = path;
    if (platform === "linux") { /* wslpath … */ }
    await runExplorer(["/select,", explorerTarget(windowsPath)], signal, run);
    return;
}

Two problems compound here:

1. The window is never shown — because runNativeCommand starts the child with
   windowsHide: true (corrected attribution; see above).
2. The failure is swallowed — explorer.exe exits 1, and runExplorer deliberately treats exit
   code 1 as a delegated handoff. So a reveal that displayed nothing is indistinguishable from a
   successful one, and the UI reports success.

Secondary observation (unrelated to the invisibility): on 0.1.5-rc.3 the /select, target was a
file:// URI rather than the native path the switch documents. 0.1.7 encodes that target more
carefully (explorerTarget() decodes non-ASCII escapes and escapes both , and =), so this is
mostly addressed upstream.

Resolution (applied locally by the reporter, 2026-09-23; re-applied to 0.1.7-rc.2 on 2026-09-25)

Route the reveal through the running shell's COM object instead of spawning explorer.exe.
Shell.Application is hosted by the already-running explorer.exe, so the window it creates is
displayed:

await run("powershell.exe", [
    "-NoProfile", "-NonInteractive", "-ExecutionPolicy", "Bypass",
    "-File", REVEAL_COM_SCRIPT,   // lib/reveal-com.ps1
    windowsPath
], signal);

The helper (abridged):

$shell = New-Object -ComObject Shell.Application
# reuse an existing window for the folder; Explore() only when none exists
$shell.Explore($parent)
$window = <first shell window for $parent>
$window.Document.SelectItem($window.Document.Folder.ParseName($leaf), 1 + 4 + 8)
$window.Visible = $true
# Document.Focus() does not exist on this shell object; raise the window instead:
# SetForegroundWindow is refused by the Windows foreground lock, so attach to the
# foreground thread first, then BringWindowToTop + SetActiveWindow + SetForegroundWindow,
# falling back to FlashWindowEx so the taskbar button blinks.

Measured after the change (2026-09-25 run, host-equivalent token):

• upstream: window created, Visible = False, foreground stays on the browser
• patched: window created, Visible = True, SelectedItems() = [target file], foreground switches
  to the Explorer window
• re-applied to a clean 0.1.7-rc.2 install via a version-checked, idempotent patch script; the user
  confirmed in the GUI that the window now pops up and shows the file

Three behaviours worth keeping if upstream rewrites the helper:

• Reuse an already-open window for the folder. Calling Explore() every time piles up duplicate
  windows; during this investigation three appeared.
• Never let a cosmetic step fail the reveal. Document.Focus() throws
  does not contain a method named 'Focus' on this shell object while the window is visible and the
  file is selected; making that fatal would report a working reveal as failed — the same class of bug
  as the swallowed exit code 1.
• Let it fail loudly, not silently. Even with the fix, the helper returns a distinct exit code
  when no window can be raised, so a future regression is visible instead of being reported as
  success.

A minimal upstream alternative, if spawning PowerShell is unwanted: keep the explorer.exe hand-off
but stop hiding it (windowsHide: false, or a per-call override for the reveal), and keep the
"distinguish a real failure from exit 1" handling.

I am happy to open a PR with the helper and the small call-site change if the approach is acceptable.

[PerryLink]

Your diagnosis is right and it is still unfixed upstream — but two of your framings need adjusting

1. Your quoted code is byte-exact, and the exit-1 tolerance is deliberate, not careless

At @deepseek-ai/dsh 0.1.5-rc.3, packages/util/native-command/src/path-opener.ts:247-255:

// Explorer parses commas itself; a file URI preserves commas and whitespace in the path.
const target = pathToFileURL(windowsPath, { windows: true }).href.replaceAll(',', '%2C')
try {
  await run('explorer.exe', ['/select,', target], signal)
} catch (error) {
  signal.throwIfAborted()
  // Explorer can exit 1 after delegating to the existing desktop process.
  if (!(error instanceof Error) || !('code' in error) || error.code !== 1) throw error
}

That comment is load-bearing. It was introduced by 74bf7aaa2f (2026-09-09) and it is test-pinned (tests/path-opener.spec.ts: "accepts Explorer delegate exit 1 through the native runner"). At the newest ref it is factored into a documented helper whose doc says: "Explorer exits 1 after handing the request to the desktop process already running, so exit 1 means the shell took it." So please don't read it as a naive swallow — it encodes a measurement.

2. But upstream has already written down the blind spot you found

This is the part worth quoting back at them. An in-tree note records:

Every one of these handoffs, successful ones included, exits 1. … Exit 1 therefore records the delegation rather than the outcome … Nothing here observes a window, and reveal's /select, highlight stays unverified.

and a README bullet (after a later correction) reads:

… explorer.exe invokes no file association and still exits 1 after about a second … so an open reports success having opened nothing … No fallback for that session is implemented.

So your observation is a real, acknowledged instance of exactly that gap — which is precisely why it deserves a proper record rather than a dismissal. Your instinct to keep the two traps documented is right.

3. ⚠️ One conclusion needs correcting: the sandbox does not confine this child

Your flags arithmetic is right — DISABLE_MAX_PRIVILEGE (0x1) | LUA_TOKEN (0x4) | WRITE_RESTRICTED (0x8) = 13. But the sandbox runner is documented as "the argv-prefix wrapper the sandbox seam spawns in place of the caller's command" — it confines model-facing bash/pwsh tool children. The reveal is a Host @Remote handler that runs through a plain no-shell execFile (packages/util/native-command/src/runner.ts, windowsHide: true) and never passes through the sandbox seam. So under workspace-write the reveal child inherits the Host's own token, not the restricted one.

⇒ The decisive question for your theory is: was your dsh Host itself started from inside an already-sandboxed shell (e.g. launched by the agent from a sandboxed pwsh)? If it was started from a normal terminal, the restricted token is not what hides the window and the cause lies elsewhere. Worth settling before attributing the invisibility to the token.

4. It is genuinely unfixed — you are not duplicating anything

• At 0.1.7-alpha.2 the file is byte-identical to rc.3 inside revealNativePath (git diff dsh-v0.1.5-rc.3..HEAD -- …/path-opener.ts touches only PathOpenIntent and a new openNativeAssociatedPath).
• At the newest ref (dsh-v0.1.7-rc.1) it is refactored into runExplorer() and the exit-1 tolerance is retained unchanged.

So there is no upstream fix to point at, and your local patch is not re-doing landed work.

5. Packaging: don't ship a .ps1 — this package has a better-fitting pattern

No .ps1 ships in any package (the ten in the repo are all apps/desktop build tooling), and packages/util/native-command/package.json declares no asset directory, so a shipped script would need a new files glob plus a build copy step. The same package already runs an inline PowerShell + COM adapter — src/file-applications-windows.ts:

await run('powershell.exe', [
  '-NoProfile', '-NonInteractive', '-STA', '-EncodedCommand', Buffer.from(script, 'utf16le').toString('base64'),
], signal)

with the script driving real Shell COM (SHAssocEnumHandlers, IShellItem, IDataObject, …). A Shell.Application-based reveal therefore belongs inline in path-opener.ts (or a sibling reveal-windows.ts) as an encoded script mirroring that adapter — zero packaging change.

One caveat to name in your report, because a reviewer will raise it: the package's own prose says native implementations "never invoke a shell", and a recent commit explicitly removed a PowerShell literal from that file. Citing file-applications-windows.ts as the in-package precedent is what makes the case.

6. The regression gap is itself part of the finding

Every reveal test injects a mocked runner; none spawns Explorer and none observes a window (the Agent Note states this outright). So a regression of exactly your kind cannot be caught by the suite as it stands. That is worth stating explicitly — it is the reason the two traps deserve to be documented, and it is a concrete ask (add an interactive-session smoke check, or at minimum keep the "nothing observes a window" caveat next to the tolerance).

7. Channel

CONTRIBUTING.md states plainly: "we are sorry that we cannot accept external pull requests at the moment." So a PR would not be accepted — this discussion is the right place, and the same document says the team reads Discussions when allocating resources. Also, since your status line says the fix was applied locally: the upstream copy is unchanged, so this record (plus the helper and the call-site change, inline as above) is the only durable form of your work.