DSH 安装 Git 插件被 allowBuilds 阻止怎么办

直接答案

DSH 安装 Git 托管插件时，如果插件依赖 prepare 脚本现场构建，pnpm 10 及以上可能默认阻止脚本并要求配置 allowBuilds。这是一道供应链安全门，不是应该全局关闭的“安装故障”。正确修复是先审阅被阻止的包和脚本，只在当前 Profile 的 pnpm-workspace.yaml 中允许 pnpm 输出的精确键，然后重新运行原命令。

本文固定审阅 DeepSeek Harness 0.1.1-rc.2 的 CLI 参考和插件转发源码。没有安装或执行任何第三方插件，也没有证明某个社区仓库安全或兼容。

为什么 DSH 会出现这个提示

DSH 的插件命令会在指定 Profile 目录中调用 pnpm：

dsh plugin --profile <name> add <package-or-git-spec>

Git 仓库常只包含源码，包管理器安装时需要运行 prepare 生成可加载产物。安装脚本能够执行包作者提供的代码，因此 pnpm 不会把它等同于普通文件复制。DSH 在 Git 依赖安装失败时，会额外打印实际 Profile 目录和应修改的 pnpm-workspace.yaml 路径。

第一步：保留完整错误和精确路径

不要只截取最后一句。保存 pnpm 输出中的：

• 被阻止的精确包键；
• 插件 spec、版本、Tag 或 commit；
• DSH 打印的 Profile 目录；
• 失败发生在 prepare、依赖构建还是其他阶段；
• 原安装命令与退出码。

web、headless 和自定义 Profile 各有独立目录。修改另一个 Profile 的配置不会修复当前安装，也可能无意授权无关包。

第二步：授权前审阅什么

把 allowBuilds 理解为“允许该包在安装期间执行构建脚本”。至少检查：

1. 仓库 owner、包名、许可证和发布者是否对应；
2. Git spec 是否固定到审核过的 Tag 或 commit；
3. package.json 的 scripts.prepare 实际调用什么；
4. 脚本是否下载二进制、运行 shell、访问网络或修改 Profile 外文件；
5. 构建产物路径是否与 Bundle manifest 和 cordis.patch.yml 对应；
6. 间接依赖为什么也要求构建，是否在插件声明范围内。

Stars、README、社区收录和“源码可见”都不能替代这一步。看不懂脚本、来源漂移或要求允许多个无关包时，应停止安装并要求作者提供预构建、可校验的发布产物。

第三步：只加入精确 allowBuilds 键

打开 DSH 错误信息明确指出的 Profile 文件：

$DSH_HOME/profiles/<name>/pnpm-workspace.yaml

保持文件原有内容，只把 pnpm 输出的精确键加入 allowBuilds。结构示意如下：

allowBuilds:
  "<pnpm 输出的精确包键>": true

占位符不能原样复制。实际键必须来自本次 pnpm 输出，并与已经审阅的包一致。不要使用通配符，不要批准所有依赖，也不要把其他 Profile 的列表整段复制过来。

如果文件已经存在 allowBuilds，在现有映射下增加精确键，避免覆盖原有条目。保存前先备份该文件并检查 YAML 缩进。

第四步：重试原安装命令

完成精确授权后，重新执行同一条固定来源安装命令：

dsh plugin --profile <name> add <同一个固定 package-or-git-spec>

不要在重试时把固定 Tag 改成移动分支，也不要顺手添加更多包。命令成功后，DSH 会根据安装状态判断包是否声明 Bundle，并更新 Profile manifest 中的 Bundle 列表。

如果仍然失败，读取新的第一条错误。构建产物缺失、Node 版本不匹配、脚本本身报错和包没有 Bundle 声明，都不是继续扩大 allowBuilds 的理由。

第五步：重启并验证

添加或更新 Bundle 后，正在运行的 Profile 不会热切换到新 Bundle 集合，必须重启。重启前可以查看依赖与组合配置：

dsh plugin --profile <name> why <package-name>
dsh --profile <name> --dump-config

验证时检查：

• 目标包确实来自审核过的版本；
• Bundle 层出现在预期位置，没有覆盖无关配置；
• DSH 能启动，低风险功能可在可丢弃工作区中验证；
• Profile、工作区和用户目录没有意外文件；
• 插件需要的网络、凭据和权限与审阅结果一致。

安装成功、配置层出现和实际功能可用是三个不同结论。本文的 source_reviewed 不代表运行实测。

哪些情况可能不需要 allowBuilds

官方 CLI 参考指出，已经构建好的 tarball 或本地 checkout 不一定需要加入 allowBuilds。但“无需现场构建”不等于安全：仍要验证下载来源、校验值、包内容、Bundle 声明和运行时权限。

不要为了绕过 prepare 随意改用陌生镜像、他人重新打包的压缩文件或无法追溯的构建产物。优先使用插件作者发布且能固定版本的来源。

回退和清理

决定不使用插件时，在同一 Profile 移除对应包：

dsh plugin --profile <name> remove <package-name>

重启并用 --dump-config 确认 Bundle 层已消失。之后检查插件说明中的数据、缓存、外部授权和凭据清理范围。仅在确认没有其他已安装版本需要该授权键时，才从 pnpm-workspace.yaml 移除对应 allowBuilds 项。

删除授权键不会撤销已经执行过的构建脚本，也不会自动删除它创建的文件。因此首次批准前的源码审阅比事后清理更重要。

本文的验证范围

本文核对了固定版本中 dsh plugin 对 pnpm 的转发、失败诊断、Bundle 整理和官方 allowBuilds 说明。没有执行 Git 插件的 prepare，没有修改真实 Profile，也没有使用第三方代码或凭据。

需要理解完整安装流程时阅读DSH 插件安装、Profile 与 Bundle 指南；寻找经过分级整理的条目时进入DeepSeek Harness 插件目录。