资源管理器可见窗口 King20260919/dsh-open-folder-visible

dsh-open-folder-visible

修正 DSH 在 Windows 上「打开工作目录」无效的问题：让会话头部的「用 文件资源管理器 打开」真正弹出可见的窗口。

问题

会话头部有一个 "Open In…" 分体按钮，默认动作是在文件资源管理器中打开当前会话的工作目录（同时也绑定 Ctrl+Alt+O）。

在 Windows 上点它：Explorer 启动了、正确的目录窗口也创建了——但那个窗口是不可见的。按钮随即回到空闲、不报任何错，于是这一下点击看起来什么都没发生。

原因

上游 @deepseek-ai/dsh-host-open-in-app 里 explorer 条目的启动方式是 kind: 'shell-open'，在 Windows 上最终落到 @deepseek-ai/dsh-native-command：

execFile('explorer.exe', [''], { encoding: 'utf8', signal, windowsHide: true })

windowsHide: true 的本意是抑制 CLI 子进程一闪而过的控制台窗口。套用到 Explorer 上，效果是窗口被创建出来，但 IsWindowVisible() 为 false。

上游只用退出码判定成败，而 Explorer 的退出码 1 被当作"已交接给桌面进程"
（runExplorer），所以无论窗口有没有真的可见，路由都返回 { ok: true }。

实测

同一台机器、同样的调用形态，只有这个 flag 不同：

| 调用 | 新窗口 | IsWindowVisible() |
| windowsHide: true（上游现状） | 1 | false（6/6，9 秒后仍为 false） |
| windowsHide: false | 1 | true（6/6） |

修法

Host 半边新增一条路由 POST /open-folder-visible/open，用 windowsHide: false 启动同一个 explorer.exe。其余全部对齐上游：argv 数组（绝不拼 shell 字符串）、 Explorer 退出码 1 视为已交接、看护窗口让仍在运行的启动器计为已启动而非被杀。

浏览器半边包一层 globalThis.fetch，只把文件资源管理器这一个启动请求改道到该路由，其它一切——其它应用、页面上其它请求——原样透传。

有意不做的事

它不替换那个分体按钮。上游的按钮、应用菜单、图标、手势反馈以及 Ctrl+Alt+O 快捷键（workspace.openLocal）全部保持原样。替换组件就意味着要重新注册那个快捷键，而漏掉它正是「修一个 bug 顺手删掉一个热键」的典型来路。

安装

dsh plugin --profile web add github:King20260919/dsh-open-folder-visible

安装任何插件都等于在你的机器上跑第三方代码，权限和你本人一样大。想锁定版本可以用 github:King20260919/dsh-open-folder-visible#。

安装后请重启 DSH：Host 半边在加载时注册路由。

配置

| 字段 | 默认值 | 含义 |
| launchWatchMs | 1500 | explorer.exe 交接的早期失败看护窗口。启动成功与否不与进程退出绑定，因为 Explorer 把请求交给正在运行的 shell 后就退出。 |

已知边界

- 仅 Windows 有意义。 其它平台该路由返回 501，其余行为不变。
- 只修「打开工作目录」这一个动作。 「显示文件位置」（在资源管理器中定位文件， explorer.exe /select,，用于交付卡片与变更对比页）受同一个 windowsHide 影响，但走的是另一条代码路径（@deepseek-ai/dsh-api-session-controller → revealNativePath），本插件未覆盖。
- 它靠包一层 globalThis.fetch 改道一个请求。若未来版本改了上游的启动路由或请求体形状，改道只是不再匹配、退回上游行为——这个包装绝不会弄坏原请求。

许可

MIT