DeepSeek Harness 插件安装报 ERR_PNPM_ADDING_TO_ROOT 的版本分叉

「我什么都没配错，全新 profile，一条 dsh plugin --profile wprobe add <tgz> 就报 ERR_PNPM_ADDING_TO_ROOT」——这条报错看起来像插件坏了，其实是 pnpm 大版本在你的机器上决定的结果。 dsh 初始化 profile 时会自己生成 pnpm-workspace.yaml，而它转发的 pnpm add 没有带 --workspace-root；pnpm 9 会拦，pnpm 11 不会（#10629）。先判版本，再选路径。

DeepSeek Harness 第一步：判 pnpm 大版本

这是版本分叉问题，先看 PATH 上的 pnpm 是 9 还是 11，比看任何日志都快。

1. 执行 pnpm --version，记下大版本。
2. 9.x：命中这条的概率很高。
3. 11.x：社区对照里不带 -w 也能成功，说明你遇到的可能是别的问题。
4. 如果机器上有多个 pnpm（corepack、nvm、全局安装），用 where pnpm 或 which pnpm 确认实际被调用的那个。
5. 版本不确定时，先跑一次最小复现，别直接怀疑插件包。

DSH插件 第二步：看 profile 里到底有什么

dsh 生成的 profile 自带 workspace 声明，这一段决定了 pnpm 的行为。

1. 打开 ~/.dsh/profiles/<name>/（Windows 下是 C:\Users\<user>\.dsh\profiles\<name>）。
2. 看 pnpm-workspace.yaml，内容里有 packages: - .、nodeLinker: hoisted、autoInstallPeers: false。
3. 看 package.json，名字形如 dsh-profile-<name>，private: true，依赖为空。
4. 于是 profile 目录被 pnpm 视为 workspace 根。
5. 而日志里的实际命令是 pnpm add "<spec>"，没有 -w。
6. 结论：dsh 先造了一个根，再用一条 pnpm 不欢迎在根上跑的命令去装东西。

DeepSeek Harness 第三步：三条修法，按影响面从小到大

先试命令层绕过，再考虑配置层，最后才是上游改代码。

1. 命令层：自己补 -w，即 dsh plugin --profile <name> add -w <spec>，社区实测 exit 0。
2. 配置层：在 pnpm-workspace.yaml 旁边写一个 .npmrc，加上 ignore-workspace-root-check=true。
3. 上游层：让 dsh 在转发 add/remove 时自动补 --workspace-root；per 托管 profile 而言，profile 就是根，这个参数总是正确。
4. 另一种上游改法：对单包 profile 干脆不生成 pnpm-workspace.yaml。
5. 无论选哪条，都要验证一次：新建一个干净 profile 再装，避免旧缓存干扰。

DeepSeek插件 对照实验：同一份布局只改版本

社区做过最干净的单变量对照，结论一目了然。

最小复现也很直接：先用一个无依赖的 tarball（排除依赖解析因素），再用全新 profile 名让 dsh 自己创建目录，然后执行 dsh plugin --profile wprobe add D:\probe\dsh-probe-pkg-1.0.0.tgz。

DeepSeek Harness 现场长什么样：终端与日志对照

终端只有一句泛化失败，日志里才有完整命令，两步对照就能确认。

# 终端
dsh: initialized profile wprobe at C:\Users\<user>\.dsh\profiles\wprobe
ERR_PNPM_ADDING_TO_ROOT  Running this command will add the dependency to the workspace root ... 
dsh: plugin command failed; diagnostics: ...\.plugin-manager\logs\operation-iVz9LN\pnpm.log
[exit code: 1]

# pnpm.log
Command failed with exit code 1: pnpm add "D:\probe\dsh-probe-pkg-1.0.0.tgz"

看到 pnpm add 后面没有 -w，再对一下 pnpm --version，基本就结案了。

DSH插件 为什么这条错误特别难查

报错里没有任何关于 pnpm 大版本的提示，用户分不清是版本支持问题还是插件问题。

1. 终端只显示 dsh: plugin command failed 和日志路径。
2. 真正的命令与报错在 .plugin-manager/logs/operation-*/pnpm.log 里。
3. 日志里的 ERR_PNPM_ADDING_TO_ROOT 是 pnpm 的措辞，不涉及 dsh。
4. 结果就是：自动化工具调用这条命令时，只能把泛化失败抛给用户。
5. 社区提到下游项目就踩过同一个坑，症状逐字节一致。

该不该把 pnpm 9 当支持范围

这一点社区没有定论，但对你有实际影响：如果 9 不在支持范围，dsh 应该明确报版本，而不是抛一个 pnpm 内部错误。

1. 问自己：其他依赖 pnpm 的工作流是否已经要求 10+。
2. 若团队统一升级到 pnpm 11，这条问题自然消失。
3. 若必须留在 pnpm 9，按上面的命令层或配置层绕过。
4. 无论哪种，都建议把 pnpm --version 写进故障报告。
5. 上游若采纳，最小改动是转发时补 --workspace-root，并补一条 pnpm 9 的回归测试。

注意事项

1. 别先怀疑插件包。无依赖 tarball 同样会失败。
2. 别只看终端输出。真正的命令在 pnpm.log 里。
3. 别手工删 pnpm-workspace.yaml。它由 dsh 维护，删了可能被重新生成。
4. 别在错误的 profile 上试。用全新 profile 名复现，最能排除历史干扰。
5. 记录 pnpm 大版本。这是区分「兼容性缺陷」与「不支持环境」的唯一依据。

如果你的 pnpm.log 里命令已经带了 -w 却仍失败，那不是这条问题，去查网络源或包签名。相关排查见 dsh plugin 报 pnpm failed in profile directory 怎么修？。