前言¶

DSH 開新會話時默認只認 Windows 目錄。如果你的項目構建、測試、運行都在 WSL 發行版裏（Windows 10/11 + WSL2 環境），常見做法是把工程路徑寫進 Windows 側，然後手動切到 Linux 終端裏執行，agent 的 bash 一類工具跑在 Windows 上，和真實的構建環境對不上。下面介紹的插件 dsh-remote-wsl 就是解決這件事的：它在 DSH 的「添加 workspace」流程里加了一個 Connect WSL 入口，讓你直接在 WSL 發行版裏瀏覽目錄、選一個 Linux 路徑作爲 workspace。插件由 MFJip612 維護，倉庫地址 https://github.com/MFJip612/dsh-remote-wsl ，許可證 MIT。它只使用 DSH 官方服務，不依賴也不調用任何第三方 WSL 插件。

這是什麼¶

一句話：讓 DSH 的 workspace 指向 WSL 發行版內的目錄，並把該 workspace 的終端和 agent 工具放到 Linux 一側執行。

已有做法的問題在於，Windows 路徑下的 workspace，agent 執行 bash 時用的是 Windows 側的工具鏈；而 WSL 項目的工具鏈在發行版裏，兩邊路徑、環境變量、文件系統視圖都不同。這個插件不需要你在項目里加任何包裝腳本，裝好之後在挑選目錄的對話框裏多一個選項。

核心功能¶

入口。 側欄 workspace 頭部的「+」和新會話頁的「Add workspace」共用同一個添加流程。對話框先問文件夾從哪裏來，第一項 Local folder 是原有的 Windows 目錄選擇，行爲不變；第二項 Connect WSL 是新加的行，展開後選擇發行版。

選發行版。 Connect WSL 對話框列出本機所有發行版（包括已停止的），並顯示運行狀態，右上角可以刷新。列表通過 wsl.exe -l -v --all 枚舉，自動識別 UTF-16LE 輸出，* 標出默認發行版，列表緩存 5 秒。

選項目。 選定發行版後，瀏覽從該發行版的默認用戶 $HOME 開始。麪包屑（如 Ubuntu / home / me）可點擊；搜索框過濾當前層級，也可以直接輸入 Linux 路徑跳轉；可以切換是否顯示隱藏文件夾；選中當前目錄後點 Confirm。

註冊爲 workspace。 Linux 文件系統上的項目註冊爲 \\wsl.localhost\<distro>\<path>（會自動探測 \\wsl$ 兜底形式）。/mnt/<drive>/... 下的項目則註冊爲真實 Windows 路徑（如 D:\work\proj），因爲 WSL 的 9P 共享不允許訪問 /mnt，只有真實盤符路徑可讀可寫，插件會記住它來自哪個發行版。註冊完成後，新會話裏它就是一個普通 workspace，只是執行平面不同。

發行版內的終端。 該 workspace 打開側欄終端時，實際執行的是 wsl.exe -d <distro> --cd <linux path>，即發行版的登錄 shell，起始目錄就是項目目錄。

發行版內的 agent 工具。 該 workspace 的會話中：

WSL workspace 裏會隱藏 Windows PowerShell 工具；普通 Windows workspace 不受影響。

安裝與啓用¶

從 DSH 的 Plugins 頁面安裝本地目錄，或者用命令安裝：

dsh plugin --profile web add github:MFJip612/dsh-remote-wsl

倉庫裏只有 TypeScript 源碼。安裝本地目錄前先執行 npm ci（會自動構建）或 npm run build。通過 GitHub 安裝時構建由 prepare 觸發；如果 pnpm 阻止了構建腳本，按安裝器提示在對應 profile 的 pnpm-workspace.yaml 裏放行那個確切的包鍵後重試。也可以執行 npm pack，安裝包含編譯產物的 tarball。

也可以在會話裏讓 agent 用插件管理器安裝該目錄。link: 只保證目錄中的文件可讀，不保證正在運行的 Host 會重載代碼。默認配置下，Host 側代碼改動需要完全退出並重啓 DSH，瀏覽器側改動只需刷新頁面。DSH 默認 HMR 配置是 root: []，只監聽配置文件。如果退出提示說有正在運行的任務，等它結束再重啓。

另外，運行要求 Node >= 24.9.0（見 package.json 的 engines），對 @deepseek-ai/cordis 的 peer 依賴是 >=4.0.5 <5。

配置項¶

在 profile 的 cordis.patch.yml 裏覆蓋插件行的 config：

- id: dsh-remote-wsl
  name: 'dsh-remote-wsl'
  config:
    terminal: true
    tools: true

文件變更與交付卡片¶

發佈前，WSL write / edit 會先進入官方 fs/write-intent / fs/edit-intent，讓 DSH 抓到編輯前內容，成功後記錄 fs/observed。工具結果複用原生 write/edit 的輸出格式、元數據與 diff 呈現；官方 workspace-changes 會在回合結束時生成修改文件列表和對比。只讀、越界、未觀察、版本過期的寫入仍然會被拒絕。

present 繼續使用官方執行器和 deliverables/presented 事件，插件把 Linux 絕對路徑、相對路徑、~/、掛載盤路徑轉換成 Windows 可訪問的路徑，保留描述、文件數上限、普通文件校驗和點擊預覽/打開行爲。指向其他發行版的 UNC 路徑會被拒絕。

修改文件列表會自動彙總文件工具成功改動的內容；單獨的文件卡片仍由模型調用 present 發出，插件不會爲每次源碼改動自動髮卡片。如果文件只通過 bash 改動，非 Git 目錄缺少文件工具的預抓取，需要單獨卡片時應顯式讓模型調用 present。

實現要點¶

入口占用官方 workspace 組件聲明的兩個單例槽位：sidebar.workspaces.directoryFlow 和 conversation.hero.workspace.directoryFlow，渲染自己的 Local folder / Connect WSL 選擇器，priority 比官方佔用者低，對話框畫在 shell.overlay。選擇 Local folder 時調用官方 ctx.uiWorkspace.pickDirectory()（或桌面端注入的 __DSH_DIRECTORY_PICKER__），原生選擇行爲不變。

Host 側路由：GET /dsh-remote-wsl/{status,distros,warm,list} 和 POST /dsh-remote-wsl/connect，均爲同源 JSON，拒絕跨站請求，默認只允許 loopback；connect 通過官方 workspaceRegistry.create() 註冊 workspace。目錄瀏覽直接走 \\wsl.localhost 共享，共享拒絕訪問時回退到發行版內執行 find。終端包裝官方 subprocess.spawnTerminal，僅當 cwd 落在 WSL workspace 內時替換 argv，其他終端原樣透傳。

適用場景與注意事項¶

適合 Windows 10/11 + WSL2 上開發、且項目實際在 Linux 側構建和運行的用戶，想讓它以當前 dsh 進程權限運行：插件的 Host 路由、subprocess 調用都以啓動 DSH 的賬戶權限執行，remote: true 還會把路由暴露給非 loopback 客戶端，開啓前需要確認網絡邊界。

安裝前應先檢查源碼與許可證（MIT），確認它調用的 wsl.exe 子命令和網絡路由與你的部署環境相符。插件當前在社區目錄標記爲未驗證（status: unverified），倉庫 1 顆星，屬於早期項目，接入生產流程前建議先在隔離環境試運行。

結尾¶

dsh-remote-wsl 解決的問題很具體：讓 DSH 的 workspace、終端和 agent 工具都落在 WSL 發行版一側，而不是在 Windows 和 Linux 之間手工切換。目錄頁：https://www.skillhub.cn/plugins/MFJip612/dsh-remote-wsl ；源碼與文檔：https://github.com/MFJip612/dsh-remote-wsl 。