dsh-open-folder-visible
Windows fix for DSH: makes the Session-header "open workspace in File Explorer"
action raise a visible window.
The problem
The Session header has an "Open In…" split button whose default action opens the
session's workspace directory in File Explorer (also bound to Ctrl+Alt+O).
On Windows, clicking it starts Explorer, creates the correct directory window —
and that window is invisible. The button settles back to idle and reports
nothing, so the click looks like it did nothing at all.
Why
The shipped explorer catalog entry in @deepseek-ai/dsh-host-open-in-app is
kind: 'shell-open', which on Windows ends at @deepseek-ai/dsh-native-command:
execFile('explorer.exe', ['<file:// URI>'], { encoding: 'utf8', signal, windowsHide: true })
windowsHide: true exists to suppress the transient console window a CLI child
would flash. Applied to Explorer it means the window is created with
IsWindowVisible() false.
Upstream judges the launch by exit code alone, and Explorer's exit 1 counts as a
delegated handoff (runExplorer), so the route answers { ok: true } whether or
not a window ever became visible.
Measured
Same host, same call shape, only the flag differs:
| Call | New window | IsWindowVisible() |
|---|
windowsHide: true (shipped) | 1 | false (6/6, still false 9 s later) |
windowsHide: false | 1 | true (6/6) |
The fix
The Host half adds one route, POST /open-folder-visible/open, that spawns the
same explorer.exe with windowsHide: false. Everything else mirrors the
shipped opener: an argv array (never a shell string), Explorer's exit 1 accepted
as a delegated handoff, and a watch window so a launcher still running is counted
as launched rather than killed.
The browser half wraps globalThis.fetch and reroutes only the file-manager
launch to that route. Everything else — every other application, every other
request on the page — is passed through untouched.
What this deliberately does not do
It does not replace the split button. The shipped button, its application
menu, its icons, its per-gesture feedback and the Ctrl+Alt+O shortcut
(workspace.openLocal) all stay exactly as they are. Replacing the component
would mean re-registering that shortcut, and forgetting to is how a "fix" ends up
removing the hotkey.
Install
dsh plugin --profile web add github:King20260919/dsh-open-folder-visible
Installing any plugin runs third-party code with your own permissions. Pin a
commit if you want a fixed revision:
github:King20260919/dsh-open-folder-visible#<sha>.
Restart DSH after installing: the Host half registers a route at load time.
Configuration
| Field | Default | Meaning |
|---|
launchWatchMs | 1500 | Early-failure watch window for the explorer.exe handoff. Launch success is decoupled from process exit, because Explorer exits as soon as it has asked the running shell to raise the window. |
Known limitations
- Windows only. On other platforms the route answers
501; nothing else
changes.
- This fixes the workspace-open action only. The file-location action
("reveal in File Explorer",
explorer.exe /select,<file>, used by the
delivered-file cards and the changed-files review) is affected by the same
windowsHide flag through a different code path
(@deepseek-ai/dsh-api-session-controller → revealNativePath), and is not
covered here.
- It reroutes one request by wrapping
globalThis.fetch. If a future release
changes the shipped launch route or the request body shape, the reroute simply
stops matching and the shipped behaviour returns — the wrapper never breaks the
original request.
License
MIT
