dsh-open-folder-visible

Readme

# 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`:

```js
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