前言¶
在 DSH Web GUI 的 Session 頭部，「在應用中打開工作目錄」分裂按鈕會把當前工作目錄交給本機應用打開。Windows 上該能力走 shell-open 通道，由 @deepseek-ai/dsh-native-command 執行。若你遇到過：按鈕變回空閒、界面不報錯，但資源管理器窗口始終沒有彈出——這與上游在某些主機上的已知限制一致。下面介紹社區插件 dsh-open-folder-fix 如何在不破壞 VS Code、Windows Terminal 等其它「在應用中打開」選項的前提下，只修正 Explorer 打開目錄的行爲。
這是什麼¶
dsh-open-folder-fix 由 Martlet-Tech 維護，倉庫地址爲 github.com/Martlet-Tech/dsh-open-folder-fix。插件通過 Cordis bundle patch 與瀏覽器注入，在 Windows 上把打開工作目錄的 Explorer 調用從上游的 explorer.exe "<file:// URI>" 改爲 explorer.exe /e,<目錄>，解決「報告成功卻不開窗」的問題。
社區目錄頁：skillhub.cn/plugins/Martlet-Tech/dsh-open-folder-fix。SkillHub 爲 DSH 社區插件目錄，與 DeepSeek / 幻方無官方從屬關係；安裝方式以目錄頁與 DSH 當前版本的插件管理文檔爲準。已抓取資料中未給出固定的 CLI 安裝命令，請勿自行拼接未在文檔中出現的 dsh plugin add 形式。
問題背景¶
上游在 0.1.7-rc.1 等版本對 Windows 使用類似下面的調用：
explorer.exe "<目錄的 file:// URI>"
更早版本則走 PowerShell Invoke-Item。兩者在部分 Windows 主機上症狀相同：dsh-native-command 的 Known Limitations 指出，在非交互會話等環境下，explorer.exe 可能不調用文件關聯，約 1 秒後仍以退出碼 1 返回；上游把退出碼 1 當作「已交接給桌面進程」，再配合 launchWatchMs 看門狗，導致「窗口未開」與「已成功打開」在 DSH 側無法區分。
README 中在 Windows 10 19045.7663 上的對比示例：openNativePath 報告成功但 Explorer 窗口數不變；而 explorer.exe /e,D:\Projects\dshell 能穩定新開窗口。
核心功能¶
Host 側¶
- 註冊獨立路由
POST /open-folder-fix/open，路徑刻意不與上游/open-in-app/*重疊，避免webServer.register重複註冊導致插件加載失敗。 - 非 Windows（非
win32）請求返回 501；macOS / Linux 仍使用上游行爲。 - 可配置項
launchWatchMs（默認 1500）：觀察explorer.exe交接後早期 spawn 失敗的時間窗口；成功不與進程退出碼綁定（Explorer 委派後常返回退出碼 1，與上游runExplorer的處理一致）。
瀏覽器側¶
- 從上游公開的
/open-in-app/apps讀取已安裝應用列表；僅對explorer這一 id 轉發到本插件路由，其餘應用（VS Code、Windows Terminal、Git Bash 等）仍 POST 到上游/open-in-app/open。 - 通過
cordis.patch.yml禁用上游ui-open-in-app瀏覽器半邊，避免與插件爭搶同一 slot cell id（open-in-app）導致註冊順序不確定。 - 上游
@deepseek-ai/dsh-host-open-in-app保持掛載，繼續提供應用目錄與圖標；Explorer 圖標仍走/open-in-app/icon/explorer。
包結構（便於理解行爲）¶
package.json bundle 清單：聲明 dsh.bundle.patch 與 dsh.client
cordis.patch.yml 禁用上游 ui-open-in-app，插入本插件的 Host 行
index.js Host：註冊 POST /open-folder-fix/open
client.js 瀏覽器：接管 Session 頭部分裂按鈕
插件僅使用 Node 內置模塊，不 import @deepseek-ai/dsh-native-command 的 revealNativePath（/select, 用於定位文件，與本插件打開工作目錄無關）。
配置¶
Host 導出的 Config 必須符合 Standard Schema（含 ~standard.validate）。Cordis 的 resolveConfig 在發現插件導出 Config 時會無條件調用 Config['~standard'].validate(config)；若寫成普通字段描述對象，會導致 DSH 組合樹啓動階段拋錯、整個 DSH 無法啓動。正確實現見倉庫 index.js 中的 Config。
| 配置項 | 說明 |
|---|---|
launchWatchMs |
默認 1500，範圍校驗見 Config.validate；僅用於 spawn 錯誤等早期失敗觀察 |
安裝與啓用¶
- 在 SkillHub 目錄頁 查看當前是否可安裝及版本（資料中 package 版本爲 1.0.0）。
- 按你使用的 DSH 版本，通過 profile 的 bundle / 插件管理流程安裝該 bundle（具體命令以目錄頁與官方文檔爲準；資料未提供可引用的固定 CLI 字符串）。
- 啓用後刷新 Web GUI；若 profile 裏包爲符號鏈接指向本地開發目錄，改代碼後刷新頁面即可生效，無需重複
install_bundle。
重複安裝注意： 同路徑再次 install_bundle 可能觸發上游 plugin-manager 的 ambiguous-install（依賴變化識別邏輯）。開發調試時優先依賴符號鏈接與刷新，而非反覆重裝。
典型用法¶
安裝並啓用 bundle 後，無需額外 CLI：
- 在 DSH 中打開一個 Session，確認工作區目錄在 Windows 上有效。
- 點擊 Session 頭部「在應用中打開工作目錄」分裂按鈕，選擇 Explorer（或列表中與
explorerid 對應的項）。 - 預期行爲：資源管理器新開窗口並進入該工作目錄。其它應用入口仍走上游邏輯，行爲與未裝本插件時一致。
Host 側實際執行的 Explorer 形式爲：
explorer.exe /e,<目錄>
README 還記錄了 explorer.exe <目錄>、explorer.exe /select,<父目錄> 等變體的行爲差異；本插件選用 /e,<目錄> 作爲穩定新開窗口的方案。
適用場景與注意¶
適合誰： 在 Windows 上使用 DSH Web GUI，且「打開工作目錄」經常無窗口、無報錯的技術用戶與智能體開發者。
邊界：
- 僅 Windows 有意義；其它平臺請依賴上游。
- 不修改上游 native-command 裏「在資源管理器中顯示某個文件」的路徑。
- 插件 Host 代碼在 DSH 進程權限下運行；安裝前應閱讀倉庫源碼與許可證（package.json 爲
@local/dsh-open-folder-fix，private: true，以 GitHub 倉庫爲準）。
DSH 生態強調「一切皆插件」；本插件是社區維護的補丁型 bundle，不是 DSH 核心發行版的一部分。
結尾¶
dsh-open-folder-fix 用最小侵入的方式修正 Windows 上 Explorer 打開工作目錄的參數，並保留上游應用列表與其它應用的啓動路徑。若你正被「按鈕成功但文件夾沒出來」困擾，可以從目錄頁進入倉庫閱讀實測表格與 patch 設計，再決定是否加入 profile。
- 目錄頁：https://www.skillhub.cn/plugins/Martlet-Tech/dsh-open-folder-fix
- GitHub：https://github.com/Martlet-Tech/dsh-open-folder-fix
