--- title: "DSH 安装 Git 插件被 allowBuilds 阻止怎么办" seo_title: "DSH 插件 allowBuilds 错误：pnpm 阻止 prepare 构建的安全修复" description: "解释 DeepSeek Harness 安装 Git 插件时 pnpm allowBuilds 阻止 prepare 的原因，如何审阅精确包键、修改 Profile 配置、重试与回退。" canonical: https://52dsh.com/errors/dsh-plugin-allowbuilds-blocked/ authors: ["52DSH 编辑部"] published_at: 2026-08-25 updated_at: 2026-08-25 verified_on: 2026-08-25 maintenance_status: community verification_level: source_reviewed risk_level: high dsh_version: 0.1.1-rc.2 plugin_id: null tutorial_kind: null related_plugin_url: null --- # DSH 安装 Git 插件被 allowBuilds 阻止怎么办 解释 DeepSeek Harness 安装 Git 插件时 pnpm allowBuilds 阻止 prepare 的原因，如何审阅精确包键、修改 Profile 配置、重试与回退。 ## 直接答案 DSH 安装 Git 托管插件时，如果插件依赖 `prepare` 脚本现场构建，pnpm 10 及以上可能默认阻止脚本并要求配置 `allowBuilds`。这是一道供应链安全门，不是应该全局关闭的“安装故障”。正确修复是先审阅被阻止的包和脚本，只在当前 Profile 的 `pnpm-workspace.yaml` 中允许 pnpm 输出的精确键，然后重新运行原命令。 本文固定审阅 DeepSeek Harness `0.1.1-rc.2` 的 CLI 参考和插件转发源码。没有安装或执行任何第三方插件，也没有证明某个社区仓库安全或兼容。 ## 为什么 DSH 会出现这个提示 DSH 的插件命令会在指定 Profile 目录中调用 pnpm： ```bash dsh plugin --profile add ``` 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 文件： ```text $DSH_HOME/profiles//pnpm-workspace.yaml ``` 保持文件原有内容，只把 pnpm 输出的精确键加入 `allowBuilds`。结构示意如下： ```yaml allowBuilds: "": true ``` 占位符不能原样复制。实际键必须来自本次 pnpm 输出，并与已经审阅的包一致。不要使用通配符，不要批准所有依赖，也不要把其他 Profile 的列表整段复制过来。 如果文件已经存在 `allowBuilds`，在现有映射下增加精确键，避免覆盖原有条目。保存前先备份该文件并检查 YAML 缩进。 ## 第四步：重试原安装命令 完成精确授权后，重新执行同一条固定来源安装命令： ```bash dsh plugin --profile add <同一个固定 package-or-git-spec> ``` 不要在重试时把固定 Tag 改成移动分支，也不要顺手添加更多包。命令成功后，DSH 会根据安装状态判断包是否声明 Bundle，并更新 Profile manifest 中的 Bundle 列表。 如果仍然失败，读取新的第一条错误。构建产物缺失、Node 版本不匹配、脚本本身报错和包没有 Bundle 声明，都不是继续扩大 `allowBuilds` 的理由。 ## 第五步：重启并验证 添加或更新 Bundle 后，正在运行的 Profile 不会热切换到新 Bundle 集合，必须重启。重启前可以查看依赖与组合配置： ```bash dsh plugin --profile why dsh --profile --dump-config ``` 验证时检查： - 目标包确实来自审核过的版本； - Bundle 层出现在预期位置，没有覆盖无关配置； - DSH 能启动，低风险功能可在可丢弃工作区中验证； - Profile、工作区和用户目录没有意外文件； - 插件需要的网络、凭据和权限与审阅结果一致。 安装成功、配置层出现和实际功能可用是三个不同结论。本文的 `source_reviewed` 不代表运行实测。 ## 哪些情况可能不需要 allowBuilds 官方 CLI 参考指出，已经构建好的 tarball 或本地 checkout 不一定需要加入 `allowBuilds`。但“无需现场构建”不等于安全：仍要验证下载来源、校验值、包内容、Bundle 声明和运行时权限。 不要为了绕过 `prepare` 随意改用陌生镜像、他人重新打包的压缩文件或无法追溯的构建产物。优先使用插件作者发布且能固定版本的来源。 ## 回退和清理 决定不使用插件时，在同一 Profile 移除对应包： ```bash dsh plugin --profile remove ``` 重启并用 `--dump-config` 确认 Bundle 层已消失。之后检查插件说明中的数据、缓存、外部授权和凭据清理范围。仅在确认没有其他已安装版本需要该授权键时，才从 `pnpm-workspace.yaml` 移除对应 `allowBuilds` 项。 删除授权键不会撤销已经执行过的构建脚本，也不会自动删除它创建的文件。因此首次批准前的源码审阅比事后清理更重要。 ## 本文的验证范围 本文核对了固定版本中 `dsh plugin` 对 pnpm 的转发、失败诊断、Bundle 整理和官方 `allowBuilds` 说明。没有执行 Git 插件的 `prepare`，没有修改真实 Profile，也没有使用第三方代码或凭据。 需要理解完整安装流程时阅读[DSH 插件安装、Profile 与 Bundle 指南](/plugins/dsh-plugin-profile-guide/)；寻找经过分级整理的条目时进入[DeepSeek Harness 插件目录](/plugins/)。 ## 原始来源 - https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.1.1-rc.2 - https://github.com/deepseek-ai/deepseek-harness/blob/b150a551b8d465e31e418e1b2eaf5e79bbb7d28e/apps/cli/reference/README.zh.md - https://github.com/deepseek-ai/deepseek-harness/blob/b150a551b8d465e31e418e1b2eaf5e79bbb7d28e/apps/cli/src/plugin.ts - https://github.com/deepseek-ai/deepseek-harness/blob/b150a551b8d465e31e418e1b2eaf5e79bbb7d28e/docs/architecture.zh.md - https://pnpm.io/settings#allowbuilds