前言¶

在 Windows 上使用 DeepSeek Harness（DSH）時，若同時啓用 @linxin666/dsh-win-bash，每個會話會常駐一個位於插件包目錄內的 bash.exe。官方插件管理器或插件市場通過 pnpm 更新、卸載插件時，需要「刪除舊目錄 → 重命名新目錄」；Windows 不允許替換正在執行的映像，於是常見 ERR_PNPM_EPERM，插件目錄只替換一半甚至損壞。事後手動殺進程或重啓 Harness 能救場，但屬於補救。下面介紹 Host 插件 dsh-bash-watchdog（維護者 daedal0us，社區分類 admin-security）：在 Harness 真正執行 pnpm 裝卸/更新之前，自動結束 win-bash 留下的常駐 bash.exe，把「等 pnpm 失敗再收拾」改成「在 rename 之前先釋放文件鎖」。

這是什麼¶

dsh-bash-watchdog 是純 Host 插件：無 UI、無網頁資源、無 npm 依賴（僅使用 node: 內置模塊），在 Windows 上加載即參與監聽與清理；在 POSIX 上直接 inert，不參與任何路徑。

清理不經過 pwsh 工具，也不依賴當前會話裏掛着哪個 shell：Host 用 execFile 啓動 Windows PowerShell 子進程，通過 Get-Process 與 Stop-Process 結束目標進程。因此即便 win-bash 默認 replacePwsh: true 把 pwsh 從工具面隱藏，插件管理器與插件市場的 pnpm 操作仍會被保護。

故障鏈在 README 中寫得很具體：win-bash 常駐 → 可執行文件在包內 → pnpm 替換目錄 → EPERM → 插件樹半殘。看門狗針對的是這一鏈，不是泛化的「殺所有 bash」。

觸發時機與活動窗口¶

覆蓋 Harness 內會真正跑 pnpm 的幾類入口，外加持久 shell 守衛：

每次觸發打開「活動窗口」：窗口內每 2 秒複查，pnpm 解包期間其它會話新起的 win-bash 也會被清掉。操作結束（如 plugin-manager/changed、市場日誌完成、tools/post-execute）時窗口提前收窄。README 給出的實測：安裝 pnpm 約 1.28 s 時，自 operation 目錄出現到 bash 被殺約 0.31 s；卸載約 0.54 s 時約 0.30 s，均早於 pnpm 完成刪除/替換。

只殺該殺的¶

不是 taskkill /IM bash.exe。看門狗按可執行文件路徑逐個檢查，默認只殺路徑中包含 dsh-win-bash 的 bash.exe（可通過 bashPathPatterns 改子串）。Git for Windows 等其它 bash 不會被誤殺。優先 Stop-Process -Force；被拒絕時退回 taskkill /T /F。

與兩條 bash 擴展線並存：官方一次性/持久 bash 的路徑通常不含 dsh-win-bash，不會被誤殺；win-bash 包內 runtime\...\bash.exe 會被清掉。若有人把官方持久 bash 的 shellPath 手動指向 win-bash 包內可執行文件，則按 win-bash 進程處理——默認配置不會出現。

replacePwsh 與 win_bash 裏的 pnpm¶

@linxin666/dsh-win-bash 默認 replacePwsh: true 時，僅 restrict({ deny: ['pwsh'] })，不影響 Host 的 execFile 與管理器/市場的觸發。插件管理器與市場路徑照常被保護。

在 win_bash 裏對 DSH profile 跑 dsh plugin ...、cd <profile> && pnpm update 等變更命令時，看門狗會 deny 並說明原因（指向管理器/市場，或建議 replacePwsh: false 後用 pwsh）。原因是：pre-execute 殺的是舊 shell，win_bash 會爲該命令新起仍在包目錄內的 bash，殺與不殺都無法安全完成 profile 上的 pnpm 替換。項目目錄內的 pnpm 不受影響。

若希望 Agent 直接用 shell 跑 profile 上的 pnpm，README 建議：將 win-bash 的 config.replacePwsh 設爲 false，重啓一次 DSH 讓 pwsh 回到工具面，再用 pwsh 執行。

安裝與啓用¶

README 給出的安裝方式是在本機工作區對插件目錄執行 install_bundle（plugin_manager 的 target 爲絕對路徑）：

{ "action": "install_bundle", "target": "C:\\Users\\daeda\\Documents\\Programming\\dsh-bash-watchdog" }

請把 target 換成你本機 checkout 或解壓目錄的實際路徑。安裝成功後打開即生效，README 寫明無需重啓。按絕對目錄安裝時 pnpm 使用 link: 指向該目錄；移動或刪除目錄會使 profile 條目失效，需重新 install_bundle。

當前 package 版本爲 0.1.2（以倉庫 package.json 爲準），要求 Node >=22，許可證 MIT。

配置要點¶

配置寫在 profile 的 cordis.patch.yml 對應插件行的 config 下，鍵均可省略。常用項包括：

- id: dsh-bash-watchdog
  name: dsh-bash-watchdog
  config:
    bashPathPatterns: ['dsh-win-bash']
    activeWindowMs: 120000
    sweepIntervalMs: 2000
    watchPluginManagerLogs: true
    watchMarketLog: true
    interceptShellTools: true
    shellToolNames: ['pwsh', 'bash', 'shell', 'terminal', 'run_command']
    persistentShellToolNames: ['win_bash']
    denyProfilePnpmInPersistentShell: true
    sweepOnStartup: false

完整鍵說明與默認值見 GitHub README。win_bash 在 persistentShellToolNames 而非 shellToolNames，與「殺進程無法保護正在 win_bash 內執行的 profile pnpm」的模型一致。

日誌與邊界¶

默認日誌路徑爲 <DSH_HOME>/logs/dsh-bash-watchdog.log，JSON Lines 記錄 activate、killed（含 pid 與路徑）等；超過 maxLogBytes（默認 1048576）會輪轉爲 .log.1。

務必瞭解的邊界（均來自 README）：

1. 只覆蓋 Harness 自己發起的 pnpm 操作（管理器、市場、dsh plugin CLI、Agent 經 pwsh 等入口）。系統終端裏裸跑 pnpm update 且無上述觸發信號時，看門狗不動作。
2. 持久 shell 內的 profile pnpm 是拒絕而非保護；項目目錄 pnpm 不受影響。
3. 只處理可執行文件在包目錄內的 bash 鎖；DSH 自身加載的 .node 原生模塊無法靠殺 bash 解決，需重啓 DSH 後再替換。
4. 活動窗口內會結束正在跑的 win-bash 命令（含構建/測試），窗口在操作結束時收窄。

適用場景與注意¶

適合：Windows 上長期使用 DSH，啓用 @linxin666/dsh-win-bash，並頻繁通過插件管理器、插件市場或 Agent 的 pnpm/dsh plugin 裝卸插件的開發者。

插件以當前 DSH 進程權限在 Host 側執行進程枚舉與結束操作；安裝前應閱讀 GitHub 倉庫 源碼與 MIT 許可證，確認行爲符合本機安全策略。社區目錄 SkillHub 插件頁 與 GitHub 無 DeepSeek / 幻方官方從屬關係，屬於「一切皆插件」生態中的第三方條目。

結尾¶

經過上面的步驟，dsh-bash-watchdog 把 win-bash 與 pnpm 目錄替換之間的鎖衝突前移到「pnpm rename 之前」處理，並區分一次性 shell 清理與持久 shell 內 profile pnpm 的拒絕策略。若你正被 ERR_PNPM_EPERM 與半殘插件目錄困擾，可先對照 README 安裝 Host 插件，再按需調整 replacePwsh 與 cordis.patch.yml。

• 社區目錄：https://www.skillhub.cn/plugins/daedal0us/dsh-bash-watchdog
• 源碼與文檔：https://github.com/daedal0us/dsh-bash-watchdog