[Bug] Desktop profile 上插件市场更新任何插件都失败：install_bundle 因 HMR 可用而拒绝已安装包（already-installed）

[ACGNnsj]

环境

• DSH Desktop 0.2.1-rc.1（Windows；DeepSeek Harness.exe FileVersion 0.2.1-rc.1，安装/更新时间 2026-10-17 12:49）
• profile：desktop（官方 Electron profile）
• 相关插件：dshmarket 1.66.30（市场提示可升到 1.66.32）、dsh-context 0.72.0 → 0.73.0、dsh-mnemon 0.5.29 → 0.5.30

现象

更新 DSH 客户端之后，插件市场里更新任何插件都失败，而且失败后的回滚也失败，界面提示：

dshmarket 更新失败，且更新前的构建未能验证恢复（{"code":"already-installed"}）；请先检查该 profile，再重新启动。

三个插件表现完全一致。

复现与日志

1. 设置 → 插件市场 → 对任一可更新插件点「更新」（三个插件各试一次）。
2. ~/.dsh/profiles/desktop/.dsh-market/log.ndjson 中出现：
   • {"level":"error","event":"update","detail":"dshmarket -> dshmarket@1.66.32 exit=1 err={\"code\":\"already-installed\"}"}
   • {"level":"error","event":"update-rollback","detail":"dshmarket: failed update command and restoration of the previous build could not be verified — {\"code\":\"already-installed\"}"}
   • dsh-context、dsh-mnemon 同形。
3. 关键点：~/.dsh/profiles/desktop/.plugin-manager/logs/ 下没有对应时间点的 pnpm 日志（最新那条早于客户端更新），说明这次根本没跑到 pnpm，就在管理器里被拒了。

定位

• 市场在官方 Desktop 上不自己跑 pnpm，而是调用进程内插件管理器：dshmarket/lib/official-desktop.js:93-95 只把 add 映射到 manager.installBundle(spec, …)、remove 映射到 manager.removeBundle(target)，update 不在这张表里（该文件第 70 行附近的注释也这么写）。

• @deepseek-ai/dsh-plugin-manager 的 lib/index.js:1970 installBundle()，在跑 pnpm 之前有一道拦截（第 1991 行）：

  if (this.ownerContext.get("hmr") !== void 0 && known !== void 0 && Object.hasOwn(before, known)) throw new ManagementFailure("already-installed");

  其中 before 是 profile package.json 的 dependencies。也就是说：HMR 服务存在时，只要该包已写在 profile 依赖里，安装请求就直接被拒。

• 同包 lib/types/tools.js:12 的说明也是这个顺序：已安装该包；要装另一个版本，先 remove_bundle，再 install_bundle。

• HMR 从哪来：新版客户端把 dsh-hmr、dsh-client-hmr 打进了 app.asar，而该 profile 的 cordis.patch.yml、package.json、pnpm-workspace.yaml 里没有任何 hmr 配置 —— 所以 HMR 是客户端默认提供的，用户无法从配置里关掉。客户端更新之前的日志显示市场能通过同一个管理器完成安装，因此这道拦截是更新之后才生效的。

影响

• Desktop profile 上，市场对所有已安装包的更新都无法完成；回滚走同一个 installBundle，同样被拒，于是市场自己的「恢复更新前构建」校验也失败，用户看到的是双重报错而非一条明确提示。
• 次要问题：这条路在当前镜像下也拿不到最新版。.plugin-manager/logs/operation-*/pnpm.log 里出现 ERR_PNPM_NO_MATCHING_VERSION No matching version found for dshmarket@1.66.32 while fetching it from https://mirrors.cloud.tencent.com/npm/，该镜像最新只到 1.66.29。

期望行为

1. 市场在 Desktop 通道把「更新」实现成 removeBundle(target) → installBundle(spec)（官方要求的顺序）；或
2. installBundle 允许覆盖已安装包（至少对「同包换版本」放行），并给调用方一个可区分的错误码，便于自行走 remove → install。
3. 建议：already-installed 属可预期的拒绝，不该让市场侧报出「构建恢复未验证」。

[wubie052]

我今天遇到了相同的问题

[Cozieur]

补充一个跨平台、跨版本的独立复现，以及一条实测可用的临时绕法。

环境：macOS 27.0.1 (26A434) arm64，Desktop 0.2.1-rc.2（nightly feed，构建 2026-10-17T02:59:53Z），内置 @deepseek-ai/dsh-plugin-manager 0.2.1-rc.2。

同一现象，四个包全数失败（~/.dsh/profiles/desktop/.dsh-market/log.ndjson，2026-10-17T11:15–11:18Z）：

dshmarket                      -> 1.66.35      exit=1  already-installed
dsh-connect-workbuddy          -> 4.7.0        exit=1  already-installed
@deepseek-ai/dsh-computer-use  -> 0.2.1-rc.2   exit=1  already-installed
@deepseek-ai/dsh-browser-use   -> 0.2.1-rc.2   exit=1  already-installed

主帖的三例都是第三方插件；这里补两点：官方 @deepseek-ai/* 实验包同样中招，而且 macOS + rc.2 上表现一致——不是平台问题，也不是 rc.1 特有。

影响面比"更新按钮坏掉"更严重，可以量化：

这批官方实验包的 peerDependencies 是逐字精确锁宿主版本（例如 @deepseek-ai/dsh-brand: "0.2.1-rc.2"）。App 升到 0.2.1-rc.2 之后，它们仍停在 0.2.0-rc.2，于是被兼容门禁静默 disabling profile plugin row。实测工具面从 133 掉到 38，少 96 个（cua-driver 58 / playwright 24 / scholar 9 / context7 2 / MCP 资源 3）。因为这些包只能通过市场更新，而市场更新全线失败，用户升完客户端就静默失去能力——这是这条 bug 值得优先修的原因。

临时绕法（已在本机验证生效，仅作恢复手段，不建议长期使用）：

1. npm pack <pkg>@<ver> 逐个下载 → 解压覆盖 profiles/desktop/node_modules/@deepseek-ai/<pkg>（连带依赖 dsh-util-values / dsh-experimental-browser-use-runtime / dsh-mcp-client 要一起升到同版本）；
2. 同步 package.json 里的版本声明；
3. 清掉两处"禁用"残留——.dsh-market/state.json 的 disabled 数组，和 cordis.patch.yml 里对应的 - id: <entry> + disabled: true 块（点过"先关插件再更新"会同时写下这两处；漏掉第二处，包版本对了但依然不加载）；
4. 重启后的判据要看去 MCP 子进程（cua-driver mcp / @playwright/mcp/cli.js / scholar_search_mcp 是否起来），端口 401 与进程存活都证明不了插件真的加载。

对主帖源码定位的独立印证：macOS 0.2.1-rc.2 的 app.asar 内 @deepseek-ai/dsh-plugin-manager/lib/index.js，installBundle 的守卫与 specPackageName（registry 形态直接 return parsed.name，丢弃版本号）与主帖一致；另外在该文件内检索 updateBundle / upgrade*() / updatePlugin*() / case "update" 均为 0 处，可佐证「更新」确实复用了安装入口，而非存在独立的升级路径。

[lindowx]

太可怕了，不知道1.0版什么时候能定版