桌面版插件安装：PATH 上无 dsh 启动器、运行中安装原生模块被占用报 ERR_PNPM_EPERM、保留 profile 提示缺少出路

[diyun7e7q]

该仓库未开放 GitHub Issues（has_issues: false），故以 Discussion 形式提交，供维护者评估；也可通过应用内 /feedback 渠道反馈。

环境

• DeepSeek Harness Desktop 0.2.0-rc.2（Electron 打包版），Windows 11 10.0.26200
• 自带 Node 24.21.0、自带 pnpm 11.7.0（resources/runtime/pnpm/bin/pnpm.mjs）
• 宿主 web 服务：127.0.0.1:19387（仅回环）
• 桌面渲染进程使用自定义协议：--standard-schemes=dsh-app --secure-schemes=dsh-app --cors-schemes=dsh-app --fetch-schemes=dsh-app --streaming-schemes=dsh-app
• profile：desktop

缺陷 1：打包桌面版没有在任何 PATH 目录提供 dsh，但 CLI 确实随包发布

现象

宿主的 process.argv[1]（即应用内进程入口）是：

C:\…\resources\app.asar\dsh\node_modules\@deepseek-ai\dsh-desktop-host\lib\index.js

CLI 实际位于 asar 内：

C:\…\resources\app.asar\dsh\node_modules\@deepseek-ai\dsh\lib\bin.js      # package.json: "bin": { "dsh": "lib/bin.js" }

但 where dsh（即 PATH 查询）无任何结果。于是任何 shell out 到 dsh 的第三方工具（例如社区插件市场 dsh-plugin，其安装动作就是 spawn dsh plugin --profile <p> add <spec>）都会失败，并误报成「DeepSeek Harness 未安装 / dsh 不在 PATH」。

应用自己有正确的调用方式（@deepseek-ai/dsh-desktop-host/lib/cli.js:91-105，runDesktopCli()）：

await runCli({
  manageDesktopProfile: true,
  packageManager: {
    command: process.execPath,
    args: ["--expose-internals", join(supportDir, "pnpm", "bin", "pnpm.mjs")],
    env: {
      ELECTRON_RUN_AS_NODE: "1",
      DSH_DESKTOP_NODE_EXECUTABLE: process.execPath,
      PATH: `${join(supportDir, "bin")}${delimiter}${process.env.PATH ?? ""}`
    }
  }
})

复现

where dsh                          # 无结果
& "<install>\DeepSeek Harness.exe" "<install>\resources\app.asar\dsh\node_modules\@deepseek-ai\dsh\lib\bin.js" --version
                                   # 输出 0.2.0-rc.2 —— CLI 完全可用，只是没在 PATH 上

建议

• 安装/升级时在用户 PATH（如 %APPDATA%\npm）放一个 dsh shim，内部用 process.execPath + ELECTRON_RUN_AS_NODE=1 + asar 内 lib/bin.js，并传入自带 pnpm；或
• 在文档中明确给出「第三方工具应如何调用打包版 CLI」的等价方式（含 manageDesktopProfile 的适用范围），避免每个工具各自摸索。

本次为解封本机，我按上述方式自建了 shim（%APPDATA%\npm\dsh.cmd → 一个调用 runCli({ manageDesktopProfile: true, packageManager: <bundled pnpm> }) 的包装脚本），随后 where dsh、dsh --version、以及市场的安装动作都恢复正常。

缺陷 2：应用运行中安装插件会撞上原生模块占用（ERR_PNPM_EPERM），且提示不指向真正出路

现象

[ERR_PNPM_EPERM] [importPackage …\profiles\desktop\node_modules\lightningcss-win32-x64-msvc]
EPERM, Permission denied: …\lightningcss-win32-x64-msvc_tmp_xxxx\lightningcss.win32-x64-msvc.node

证据（同一台机器）

# 宿主进程（DeepSeek Harness.exe，web 服务那一个）持有该模块
(Get-Process -Id <host-pid>).Modules | Where-Object ModuleName -match 'lightningcss'
#   → …\profiles\desktop\node_modules\lightningcss-win32-x64-msvc\lightningcss.win32-x64-msvc.node

# 独占打开被拒：文件正被另一进程使用
[IO.File]::Open($addon,'Open','ReadWrite','None')   # → IOException：正由另一进程使用

完全退出应用后，同一条安装命令 exit code 0（并在结束时自动重启应用即可）。也就是说这是「应用占用 vs pnpm 需要替换」的必然冲突，而不是插件或市场的问题。

建议

• 安装前检测本次要写入的文件是否被宿主自身占用（至少覆盖 node_modules/**/*.node），命中时直接给出明确提示：「请完全退出 DeepSeek Harness 后重试」，而不是让用户看到裸的 EPERM；
• 或在可能的情况下让 pnpm 避免重新链接未变更的原生包（本次失败的触发点是依赖图中一处版本解析变化导致的整体重链）。

缺陷 3：保留 profile 的拒绝信息缺少「怎么办」

dsh plugin --profile desktop add <pkg>
→ error: profile "desktop" is managed exclusively by the Electron application

（@deepseek-ai/dsh/lib/bin.js:36 的 rejectElectronProfile()，以及在 :119 处由 manageDesktopProfile 开关决定是否放行。）

这条信息是正确的——desktop 是应用保留 profile，必须由应用内进程以 manageDesktopProfile: true 管理。但它没有告诉用户出路。建议补一句指向应用内官方「插件」设置页（该页存在：dsh-client-ui-settings-plugins + @deepseek-ai/dsh-plugin-manager），并说明「完全退出应用后由命令行安装」也可行。

附：这不是 bug、但值得注意的一条

@nanmicoder/dsh-agent-teams@0.1.21 的 peerDependencies 只声明到 dsh 0.1.7-rc.2，与 0.2.0-rc.2 不匹配，因此每次安装都会打印一段很长的 Plugin … is incompatible with dsh 0.2.0-rc.2 警告，并在启动时拒绝加载该插件（需 dsh plugin allow-version … --accept-risk 显式豁免）。判定本身是合理的，但该警告在每一次插件安装时重复输出，容易盖过真正的错误信息；若能在非交互安装时压缩为一行摘要会更好读。

敏感信息说明

本报告不含 token、账号、机器名或用户目录路径；C:\… 均为省略写法。

[f-infinite-z]

补充两个我们实测碰到的点：

1. 缺陷 2（运行中安装撞 EPERM）：Windows 上我们复现过同类占用（node_modules 下被宿主加载过的文件在替换时被锁），完全退出应用后同一条命令成功——和你的观察一致。补充一点：不只是 .node，宿主加载过的任何文件在替换时都可能被锁，所以"安装前提示完全退出应用"目前确实是最有效的做法；我们做隔离测试时也把"应用运行中不做包操作"当硬规则。
2. 缺陷 3（保留 profile 的出路）：我们也撞过。后来走通的路是：对需要豁免的插件（即你附注里 peer 只到 0.1.7 那类），第三方工具可以只写 profile 的 compatibility.json 豁免条目（官方安装时读该文件），然后在应用内 Plugins 页重试安装即可通过——安装/卸载动作仍留在应用内完成。我们把这个链路做进了自己维护的 dsh-plugin-ops（0.14 起有 desktop 分支），供参考。

附注里 dsh-agent-teams 那种"peer 不匹配 + 每次安装重复长警告"，核心就是缺一个"豁免 + 验证"入口；官方将来若在应用内提供 allow-version 会省掉很多手工步骤。

[f-infinite-z]

补一条跟进：我们核对官方 0.2.0 源码后确认——桌面端已自带 CLI：应用菜单里的「Manage dsh Command」可以把官方 launcher 注册进用户 PATH（Windows 注册一个只含公共 launcher 的专用目录），注册后 dsh plugin --profile desktop ... 在应用完全退出时可用，并自动带上 bundled pnpm；npm 安装的 dsh 仍然不能管理 desktop profile。也就是说前面缺陷 1/3（PATH 无 dsh、保留 profile 无出路）官方在 0.2.0 已有对应解法，这块可以不用等第三方方案了。