dsh plugin 报 pnpm failed in profile directory 怎么修？

dsh: pnpm failed in profile directory ... 这句报错是被截断的：它只是 DSH plugin 把 pnpm 的失败包起来后给的一层外壳，真实原因在省略号后面。 排到最后的无非三种——pnpm 不在 PATH、pnpm 大版本与 profile 对不上、profile 的 node_modules 链到了已删除的 pnpm store。先看完整的第二行，再对号入座，不用重装 DSH。

DSH plugin 这条报错怎么读：dsh plugin 是一层壳，原因在省略号后

dsh plugin --profile <名字> <参数> 并不自己装包，它把 --profile 之后的参数原样转发给 profile 目录里的 pnpm，所以 pnpm 的失败会被包成这一句再抛给你。 这就是为什么报错里会出现 in profile directory——它说的是「我在哪个目录里跑 pnpm 时失败的」，而不是「插件本身有毛病」（来源）。

读这条报错只要记住三点：

1. in profile directory 是定位信息，不是原因：它指向 $DSH_HOME/profiles/<名字>（Windows 上 DSH_HOME 常为 %USERPROFILE%\.dsh）。要动文件、要重跑 pnpm，都先 cd 到这个目录。
2. 真实原因跟在省略号后面：DSH插件 与 DeepSeek插件 装不上的原因几乎都写在那里，例如 'pnpm' is not recognized as an internal or external command、different major version of pnpm、ERR_PNPM_UNEXPECTED_STORE。
3. 没有底层原因就是被截断了：把命令重跑一次，用 2>&1 | tee install.log 之类把完整输出留下，别只看终端最后一行。

一句话：这句话回答的是「在哪失败」，不是「为什么失败」。

DSH plugin 装插件报错的三种成因与各自修法

三种成因对应三条互不相同的修法，先确认是哪一条再动手。 判断依据就是省略号后面的那段文字：

1. pnpm 不在 PATH——报错里伴随 'pnpm' is not recognized as an internal or external command。 dsh plugin 不做降级：找不到 pnpm 就直接失败，不会改用 npm 或 yarn（来源）。修法是装上 pnpm 并让它可执行：

npm install -g pnpm        # 全局安装
pnpm --version             # 必须能打印版本号

装完重开一个终端再重跑 dsh plugin add——PATH 变更不会作用到已打开的窗口。Windows 上更推荐 npm install -g pnpm：corepack enable pnpm 需要写 C:\Program Files\nodejs\，权限不足时会报 EPERM（来源）。

2. pnpm 大版本与 profile 不一致——报错里伴随 different major version of pnpm。 修法是进 profile 目录让 pnpm 按当前版本重建依赖，再重跑安装：

cd "$DSH_HOME/profiles/web"                              # Windows: cd %USERPROFILE%\.dsh\profiles\web
pnpm install --config.confirm-modules-purge=false        # 预先同意重建 node_modules

confirm-modules-purge=false 的作用是省掉交互确认，否则重建可能停在提示上（来源）。同一类问题还有一个变体：报 pnpm v11.12.0 is a broken release，那是 profile 的 packageManager 字段钉死了一个坏版本，把 $DSH_HOME/profiles/web/package.json 里的 pin 改成更新的可用版本再重跑同一条命令，与插件包无关（来源）。

3. profile 的 node_modules 链到了已不存在的 pnpm store——报错里伴随 ERR_PNPM_UNEXPECTED_STORE。 常见触发是插件管理器的预览目录被清理过，node_modules 里的链接成了悬空引用（来源）。修法是从当前 store 重新链接：

CI=true dsh plugin --profile web install     # CI=true 让 pnpm 无需交互就重建 node_modules
dsh plugin --profile web add <插件包名>       # 重建后再装一次

用插件市场修这类环境问题时更省事：在「设置 → 插件市场」即 DSH Plugin Hub 里卸载再重装同一插件，等价于重跑一遍 add，还会顺带把 profile 清单同步好。

还有一种容易混进来的报错：ERR_PNPM_IGNORED_BUILDS 属于构建脚本未放行，修法完全不同，见 DSH plugin add 遇到 allowBuilds 的排查。

DSH plugin 修完怎么确认插件真的装上了

命令不报错只说明 pnpm 跑完了，插件有没有生效要另查——「包在不在」和「配置层挂没挂上」是两个口径。 按顺序验三步：

1. 查包：确认依赖真的写进了 profile。

dsh plugin --profile web list                # 默认 depth 0，只列直接依赖
dsh plugin --profile web list --json         # 给脚本用时拿 JSON，别解析树状文本

list 的完整用法见 dsh plugin list 怎么用。

2. 查配置层：这一步才是「真生效」的判据。

dsh --profile web --dump-config | grep "# ==" -A 2

输出里出现 # == <插件包名> 那一层，说明插件的配置层已经加载；只有 list 里有、dump-config 里没有，说明装的是没声明 dsh.bundle 的普通包，不会激活任何配置层。

3. 重启后看界面：重启 DSH 再进 Web UI 确认插件对应的入口（设置页表单、工具列表、状态栏项）出现了。预期：入口可见且能打开，而不是只多了一行依赖。

DSH plugin 排查注意事项

先分辨「环境问题」还是「插件问题」，再决定是修环境还是换插件。

1. 先看省略号后面：那才是原因，in profile directory 只说明在哪个目录失败。
2. 不要在没确认原因前重装 DSH：三种成因都在 pnpm 层或 PATH 层，重装本体解决不了。
3. 改环境后要重开终端：PATH 与 pnpm 安装结果都不会作用到已打开的窗口。
4. 手动跑 pnpm 前先 cd 到 profile 目录：在别的目录执行，node_modules 会建错地方。
5. 脚本里别依赖交互：用 CI=true 或 --config.confirm-modules-purge=false 预先给出决定，见 在脚本和 CI 里跑 dsh plugin 命令。
6. 区分报错码再动手：ERR_PNPM_IGNORED_BUILDS 是构建策略问题，与本文三种成因无关。
7. profile 路径按平台确认：$DSH_HOME 各平台默认位置见 DSH 配置文件在哪。
8. 改不好就回退到插件市场重装：在 DSH Plugin Hub 里卸载再装同一插件，比手改 profile 清单安全。

来源：DeepSeek Harness CLI README、pnpm 错误码文档、dsh-vision-bridge README、dsh-desktop README、dsh-agentmemory README、dsh_token_usage README。