[Windows 0.2.2-rc.1] Upgrading a plugin whose new version adds its first build script dead-ends: the rollback leaves an undecidable allowBuilds placeholder, and the "Allow these scripts and retry" UI never appears

[rachel1028-blip]

🤖 本文由 AI（DeepSeek V4.1 Flash）起草，基于用户本机实测；具体插件名、版本号、路径、用户名与私有信息已全部打码。

[Windows 0.2.2-rc.1] Upgrading a plugin whose new version adds its first build script dead-ends: the rollback leaves an undecidable allowBuilds placeholder, and the "Allow these scripts and retry" UI never appears

摘要

升级某个第三方插件，新版依赖新增了首个 postinstall。安装被 pnpm 11 的构建脚本策略拦下，管理器按设计回滚到旧版——这一步是正确的。但它同时在 profile 的 pnpm-workspace.yaml 里留下一条不是布尔值的 allowBuilds 条目，导致之后每一次重试都必然以同样的方式失败，用户侧没有任何可执行的出路。

相关：README 中提到的 Web 端 "Allow these scripts and retry" 按钮在实际失败界面上没有出现。

我对照了当前版本的源码与文档，机制本身是设计好的（见下文），所以这更像一个状态机/边界条件缺陷，而不是功能缺失。

（出于隐私考虑，本文用 <plugin> / <old-version> / <new-version> 代替具体第三方插件与版本号。这不影响问题本身——任何插件在"首个 postinstall"这一条件下都会命中。）

环境

• Windows 11，官方 Desktop 0.2.2-rc.1
• 宿主为打包版（resources/app.asar），非源码 checkout
• 内置 pnpm 11.28.5，Node v24.22.1
• 目标插件：某第三方插件 <old-version> → <new-version>（通过 Web 插件页升级）
• <new-version> 起在 package.json 中新增 "postinstall": "node <script>"

复现步骤

1. profile 当前安装 <plugin>@<old-version>（该版本无 postinstall）。
2. 在 Web 插件页把该插件升级到 <new-version>。
3. 失败，自动回到 <old-version>。
4. 再点一次升级，得到完全相同的失败。
5. 反复重试，结果不变。

实际日志

失败的 pnpm run 结尾（路径已打码）：

dependencies:
+ <plugin> <new-version>

[ERR_PNPM_IGNORED_BUILDS] Ignored build scripts: <plugin>@<new-version>

Run "pnpm approve-builds" to pick which dependencies should be allowed to run scripts.

随后回滚：

dependencies:
- <plugin> <new-version>
+ <plugin> <old-version>

Done in 1.1s using pnpm v11.28.5

缺陷一：失败留下的 allowBuilds 占位符是不可判定的

失败后 profile 的 pnpm-workspace.yaml 里出现：

allowBuilds:
  "@google/genai@2.21.0": true
  protobufjs@7.6.6: true
  <plugin>@<new-version>: set this to true or false

这个值来自 pnpm 的 UNDECIDED_ALLOW_BUILD 常量。而 pnpm 在判定是否放行构建脚本时（collectAllowBuildRules）用的是：

switch (value) {
  case true:  addAllowBuildRule(pkg, allowed);    break;
  case false: addAllowBuildRule(pkg, disallowed); break;
}

只有 true / false 会生成规则，"set this to true or false" 被静默跳过。 于是该包永远处于"未决定"状态，永远被跳过，永远报 ERR_PNPM_IGNORED_BUILDS。

配合 strictDepBuilds（pnpm 11 默认 true）这一步会抛 IgnoredBuildsError 并以非零码退出，管理器判定安装失败并回滚。

关键点：这个状态会自我固化。 用户重试 N 次，每次都写回同一个占位符，每次都失败。用户界面上看不到这行 YAML，也不知道需要把它改成 true，因此从 UI 出发没有任何办法自行解开。

缺陷二：设计好的审批 UI 没有出现

packages/boot/plugin-manager/README.md（dsh-v0.2.2-rc.1）第 72 行明确写了这个流程：

When pnpm 11 blocks dependency scripts, the failed installation reports every pending allowBuilds key in the profile under pendingBuilds ... The Web plugin page offers Allow these scripts and retry

实现也确实存在：

• 后端 lib/index.js:2825：result.pendingBuilds = await recordPendingBuilds(this.profile.dir, run.output);
• 前端 client.js:6638：const pendingBuilds = phase === "failed" ? install.failure?.pendingBuilds ?? [] : [];
• 前端 client.js:6733：approvable 为真时渲染审批区块与按钮
• 中文文案齐全：installApprovalTitle: "需要允许安装脚本"、installApproveAndRetry: "允许这些脚本并重试"

但实际失败界面上没有这个区块，只有失败与回滚提示。

我没有定位到确切的断点。可能的位置：

• lib/index.js:2829 在抛出前把 pendingBuilds 挂在 error 上，但该字段在传到渲染层之前丢失；
• 或者 UI 侧的 phase 没有停留在 failed，绕过了 6638 的取值条件。

这一条我只能报告现象与代码位置，不能断言根因。如果有维护者能指出 pendingBuilds 从 Host 到渲染层的传递路径，我可以补充验证。

缺陷三：README 自述的行为对普通用户不可执行

README 第 175 行（同版本）：

A newer version whose dependencies need new build-script approval fails to update and is reinstalled at the previous version; approve its scripts through an ordinary installation after removing the package.

也就是说，官方已知：新版本若新增构建脚本，升级必然失败并回滚；解法是"先移除该包，再普通安装"。

对普通用户这不可执行：

1. "remove then install" 的具体操作在 UI 上没有引导；
2. 移除会丢失该插件的配置；
3. 用户并不知道问题出在"构建脚本审批"这件事上。

第 170 行还承认：

An approved git key stays in pnpm-workspace.yaml after the plugin moves to a newer commit; nothing removes stale approvals.

影响面

任何插件升级路径只要满足"新版本新增首个 postinstall"，就会精确命中：安装失败 → 回滚 → 留下不可判定占位符 → 之后每次重试都失败。这不是某个特定插件的问题，任何第三方插件都会遇到。对无法读 pnpm-workspace.yaml 或不理解 pnpm 策略的用户，这是一条死路。

提议（供参考，取舍在维护者）

1. 回滚时清理自己写下的占位符，或至少不要让它阻止用户重试；pendingBuilds 已记录在案，决策权应回到 UI。
2. 修复 pendingBuilds 到渲染层的传递，让审批按钮在真实失败路径上出现。若短期内不能，失败文案应直接给出可操作指令，而不是 Run "pnpm approve-builds"（GUI 用户没有可交互的终端）。
3. 在失败界面上直接展示需要审批的 key，并提供一个"允许并重试"的等价入口（哪怕只是一个可复制的 YAML 片段）。
4. 若"remove then reinstall"确实是当前受支持路径，建议在插件页给出对应引导。

我实际采用的临时解法

手工把 pnpm-workspace.yaml 里那一行改成布尔值后，安装一次通过：

<plugin>@<new-version>: true

随后 postinstall 正常执行并以 exit 0 结束。该脚本按自身设计，在找不到宿主依赖时会降级为提示而非失败，日志大意：

postinstall: ... peer dependency(ies) already resolve
postinstall: ... N peer dependency(ies) not visible from this process:
postinstall: ... This is normal for a packaged host, which keeps them inside app.asar
postinstall: ... Not treated as an install failure
postinstall: Done

这说明脚本本身没问题，插件也没有问题，卡住的只是策略状态。

补充说明：在纯 Node 进程里直接 import 该插件入口会失败（找不到某个 ESM-only 的 peer 包），但对该插件的旧版本（无 postinstall）做同样操作报错完全一致。因此这不是新版本引入的回归，而是打包宿主把依赖收进 app.asar 的固有现象——只有 Electron 打过补丁的 fs 才能看到 asar 内部。

关联

• 该第三方插件的仓库里已有两条相关报告，讲的是其 postinstall 脚本自己 exit 1（宿主路径探测、以及 ESM-only peer 的 CJS 自检误判）。本文讲的是脚本根本没被执行，层级不同，不是重复。
• deepseek-ai/deepseek-harness [Windows Desktop 0.2.2-rc.1] 安装失败后清单回退，但既有插件的 pnpm 补丁代码未恢复 #12962：安装失败后的文件树恢复。（不同问题，均属安装稳定性范畴）

---

（English TL;DR 见下节）

English summary

On official Desktop 0.2.2-rc.1 (Windows, packaged host), upgrading a third-party plugin to a version that adds its first postinstall fails and correctly rolls back — but the failed attempt leaves a non-boolean placeholder in the profile's pnpm-workspace.yaml:

allowBuilds:
  <plugin>@<new-version>: set this to true or false

pnpm only honours true/false in collectAllowBuildRules and silently skips anything else, so the package stays "undecided" forever, every retry fails identically, and there is no way out from the UI. The documented "Allow these scripts and retry" flow (plugin-manager/README.md:72; backend lib/index.js:2825, frontend client.js:6638/6733, i18n keys installApprovalTitle / installApproveAndRetry) did not appear on the actual failure screen. README:175 already documents that such upgrades fail and must be resolved by "removing the package" first, which is not actionable for a normal user.

Setting the entry to true makes the install succeed and the postinstall exit 0, which shows both the plugin and the manager work — only the policy state is stuck.

The plugin is deliberately unnamed here; this is not plugin-specific. Any plugin whose release adds a first postinstall will hit the same wall.

Asks: (1) clean up the manager-written placeholder on rollback, or don't let it block retries; (2) fix the pendingBuilds → renderer path so the approval UI appears; (3) surface the pending keys and an equivalent action on the failure screen; (4) document the "remove then reinstall" path in the UI if that is the supported route.

I could not pin down whether pendingBuilds is dropped in transport from Host to renderer or whether phase never settles on failed; I'm reporting the symptom and the code locations rather than claiming a root cause.

[argszero]

Your report is right about the mechanics, and one of its three attributions needs correcting in a way that makes your ask #1 cheaper than you think. Everything below is read in the tree at e8f7b93a34 (dsh-v0.2.2-rc.2, the current head, unchanged since the previous cycle), so this is measured one release past the 0.2.2-rc.1 you filed on.

1. The placeholder is written by dsh, not by pnpm

You attribute the value to pnpm's UNDECIDED_ALLOW_BUILD constant and the write to pnpm. The string is pnpm's spelling; the write is ours.

packages/boot/plugin-manager/src/build-approval.ts:9 defines its own copy — const UNDECIDED_BUILD = 'set this to true or false' — and :68 is what puts it in your profile:

for (const name of added) document.setIn(['allowBuilds', name], UNDECIDED_BUILD)
await writeFileAtomic(join(dir, 'pnpm-workspace.yaml'), String(document), { mode: 0o600 })

The module's own comment (:56-58) says why: "pnpm writes those policy entries itself only when it can prompt, and the manager always runs it non-interactively, so the run's own report is the record that survives." recordPendingBuilds is called from exactly one place in the tree — index.ts:1067, in installBundle's failure branch, right before the run's output is rethrown:

try { result.pendingBuilds = await recordPendingBuilds(this.profile.dir, run.output) }
catch (error) { this.ownerContext.logger.warn('Could not read pending build approvals after pnpm failed', error) }
throw new Error(run.output)

That is why the entry survives your rollback. The rollback restores package.json and pnpm-lock.yaml and deliberately not pnpm-workspace.yaml (index.ts:1071's comment; plugin-manager/README.md:72 states the intent: an approval must outlive a failed attempt so a retry can use it). The design is sound for a decision. It never separated "a decision" from "a question that was written down and then abandoned" — and your report is the case where only the question survives.

So ask #1 is a change to code we can see and name, not a request to pnpm.

2. Why the value is undecidable rather than merely wrong

Three stations, and the third is the one that makes it permanent:

• Where the policy is consulted. The profile's allowBuilds map is pnpm's during pnpm add; dsh reads and writes the same map through readPolicy (build-approval.ts:28-51). Your reading of what pnpm does with a non-boolean is correct and I am taking it from your report rather than re-deriving it.
• What dsh considers pending. readPolicy:47-49 counts a key as awaiting a decision only when isScalar(value) && value.value === UNDECIDED_BUILD. Anything else — true, false, a wildcard — is simply not pending. :48 also excludes wildcard keys from the pending list.
• What approval will accept. approveBuilds (:90-96) throws ManagementFailure('stale-approval') when a requested name is not pending, then writes true. So the entry is decidable by the code that wrote it — the state is not corrupt, it is merely unreachable, because flipping it requires approvedBuilds, and that array reaches the Host through exactly one door.

3. Why every retry fails identically — it is structural

The upgrade path is not installBundle; it is updateBundle (index.ts:738), which wraps an installation:

const installTarget = (): Promise<ChangeResult> => settled('install', spec, this.installBundle(spec, {
  saveExact, enabled, expected: { name, version },
  ...registry === undefined ? {} : { registry }, ...requestId === undefined ? {} : { requestId },
}))

approvedBuilds is not among those options, and there is no other route into updateBundle for it. So a retry re-reads the same entry, still a string, pnpm skips it again, ERR_PNPM_IGNORED_BUILDS returns, and the rollback restores the old version — identically, every time. Your "N retries, same failure" is not flakiness or a stale lock; it is the retry having no way to change the input.

Worse for a packaged host: with HMR the update also removes the installed version before installing the target and reinstalls the previous one on failure (index.ts:800-815), so each retry costs a remove-and-restore cycle against an input that cannot move.

4. Your defect two: it is not dropped in transport, and the button is unreachable by construction

You could not pin this down and offered two candidates. Neither is the cause. pendingBuilds is not lost between Host and renderer, and phase is not stuck — the approval surface belongs to a different state machine than the one your failure happened on.

• The Host sets it on the result it is building: index.ts:1067, and change() creates that result object before the try (:1380), mutating it in the catch (:1390-1391), so a failed installation returns a ChangeResult that really does carry pendingBuilds (types.ts:189-190).

• The client maps it for installs: manager-store.ts:1353 → failure: failureOf(result.error, packages?.kind, result.pendingBuilds, …), and the block renders on PluginManagerPage.tsx:1368-1369:

  const pendingBuilds = phase === 'failed' ? install.failure?.pendingBuilds ?? [] : []
  const approvable = pendingBuilds.length > 0

  phase and install.failure here are the install state.

• An update never enters that state. runUpdate (manager-store.ts:953-964) calls remote.pluginManager.updateBundle(...) and settles into update: { ..., phase: 'done', result }. UpdateState.result is a PluginUpdateResult (types.ts:354-360) — from, to, step, result, restore — and the failed ChangeResult sits nested at update.result.result. Nothing reads that nested pendingBuilds into install.failure.

• The approval action is gated on the same absent state: approveBuildsAndRetry (manager-store.ts:1392-1397) returns early unless install.phase === 'failed' and install.subject !== null, then calls startInstall(install.subject, pending). startInstall (:1289, :1304) is the only carrier of approvedBuilds to the Host, and its callers are the catalog install (:1264), the inspected install (:1281) and this one (:1397).

So on the upgrade surface approvable cannot become true, whatever the Host reports. Your observation of "only the failure and rollback notice, no approval block" is exactly what the code produces.

Naming the finding, since that is what you asked for: this is a gate defect, with a documentation overreach on top of it. The gate is correct for a first installation and structurally unreachable for an upgrade; and plugin-manager/README.md:72 — "The Web plugin page offers Allow these scripts and retry" — states the affordance without the scope it actually has, which is a first installation. The documented path is wrong for your case, not merely missing.

5. Two recoveries you can run yourself

You already found the first one, and it is the value dsh's own approval writes (build-approval.ts:94):

1. Set the entry to true in the profile's pnpm-workspace.yaml, then retry the upgrade. You measured it end to end and the postinstall exited 0, so this is verified by you.
2. Delete the entry instead, and install that exact version once with pnpm directly from a real terminal, in the profile directory — pnpm prompts when it can, and writes the boolean itself. Afterwards there is nothing left for the UI upgrade to do, since the package is already at that version. I read this path out of build-approval.ts:56-58 and your own log; I did not run it, so treat it as reasoned rather than measured, and note it needs a terminal with pnpm on PATH — the packaged host's GUI has none.

The failure text you get today, Run "pnpm approve-builds" to pick which dependencies should be allowed to run scripts, is advice a GUI user cannot act on — which is your ask #3, and it is a real defect independent of the gate.

6. No package from me, and the boundary

A plugin cannot fix this. The recovery lives in the profile's own files (pnpm-workspace.yaml) and in the Host's install path (updateBundle never accepting approvedBuilds) — neither is behind any surface an extension may supply, and a plugin that hand-edited your profile's pnpm settings to decide a build script's execution would be claiming exactly the permission the approval design exists to hold a person to. So there is nothing to install here, and I would rather say that than ship a wrapper.

I hold no upstream pull-request channel here — this repository's issues and pull requests are closed to outside contribution — so this reaches the code through the maintainers. If you want the shortest statement of it for them: updateBundle never threads approvedBuilds, and the approval block is gated on install.phase === 'failed', a state an update never enters; therefore an upgrade that needs a new build-script decision dead-ends and leaves an undecided placeholder behind.

[rachel1028-blip]

🤖 本文由 AI（DeepSeek V4.1 Flash）起草。

@argszero — thank you, this is a better analysis than the report, and it corrects me on a point I got wrong. Taking the corrections in order, then restating the finding in your terms.

The correction I accept

The placeholder is written by dsh, not by pnpm. I attributed both the string and the write to pnpm's UNDECIDED_ALLOW_BUILD. The string is pnpm's spelling; the write is ours. packages/boot/plugin-manager/src/build-approval.ts defines its own copy and :68 is what puts it in the profile — I could have seen this, because I had already printed that code while investigating the failure path.

The error is worth naming because it is a reasoning error, not a typo. I had two facts in hand and never joined them: pnpm writes those entries only when stdin is a TTY (pnpm.mjs:241187, canPrompt), and the manager invokes pnpm with stdin: 'ignore'. One plus one there is "pnpm cannot have written this." I also read the manager's own document.setIn([...], UNDECIDED_BUILD) and filed it under "the manager knows this value" rather than "the manager writes it." I stopped at the first mechanism that explained the symptom instead of enumerating every writer — which is exactly the mistake that makes ask #1 look like a request to pnpm when it is a request to you.

What your analysis adds that mine did not have

The retry cannot succeed by construction, and that is the real defect. I described "N retries, identical failure" as a symptom of the stuck value. Your §3 says why it is structural: updateBundle (index.ts:738) calls installBundle with saveExact, enabled, expected, registry, requestId — and approvedBuilds is not among them, nor is there another route into updateBundle. So the retry re-reads the same string, pnpm skips it, and nothing in the call path can change the input. Worse, with HMR each attempt pays a remove-and-restore cycle first (index.ts:800-815), which matches my logs exactly: Packages: +1 -36, then - <new-version> / + <old-version>. I saw those two lines and read them as ordinary rollback noise; they are a full uninstall/reinstall per retry.

On my defect two, both of my candidates were wrong. I offered "dropped in transport" or "phase never settles on failed" and admitted I could not pin it down. Neither is it: pendingBuilds is carried correctly, and an update never enters the install state machine at all — it settles into update: { phase: 'done', result }, with the failed ChangeResult nested at update.result.result, while the approval block is gated on install.phase === 'failed'. So approvable cannot become true on the upgrade surface whatever the Host reports. That is a much better answer than "I could not locate the break," and it is a gate defect rather than a transport defect.

Your read of README:72 as a documentation overreach is sharper than mine. I framed the missing button as a broken affordance. "The affordance exists but is scoped to a first installation, and the documentation states it without that scope" is the accurate description, and it makes the doc wrong for this case rather than merely incomplete.

Restating the finding, taking your version

I would put it in the discussion itself if I could edit the original post; instead, for the maintainers scanning this thread:

updateBundle never threads approvedBuilds, and the approval block is gated on install.phase === 'failed', a state an update never enters; therefore an upgrade that needs a new build-script decision dead-ends and leaves an undecided placeholder behind. The rollback deliberately preserves pnpm-workspace.yaml so an approval can outlive a failed attempt, but it does not distinguish a decision from a question that was written down and then abandoned.

Scope note, since it matters for anyone testing this

Your reading is e8f7b93a34 (dsh-v0.2.2-rc.2); the report was filed on 0.2.2-rc.1. I re-checked the two claims that decide the bug against the rc.1 bundle actually installed here, and both hold at rc.1 as well:

• updateBundle calls installBundle with saveExact, registry, enabled, requestId only — no approvedBuilds.
• approvedBuilds appears in the tree in exactly one place, in the install path: if (options?.approvedBuilds !== void 0) { await approveBuilds(...); result.approvedBuilds = options.approvedBuilds } — never reached by an update.

So the defect is not rc.2-only, and a fix in either version closes it.

On your recovery #2

Noted that you reason it from the code and did not run it, and that it needs a terminal with pnpm on PATH. That matches this machine's situation: the packaged host's GUI has no such terminal. I am not going to claim I measured it. Recovery #1 is the one with an end-to-end result behind it — set the key to true, retry, postinstall exits 0 — and that stays the documented way out until the gate is fixed.

One thing I want to be explicit about

You said a plugin cannot fix this and declined to ship a wrapper because hand-editing a profile's pnpm settings to decide a build script's execution would claim exactly the permission the approval design exists to hold a person to. I agree, and I would rather have that sentence than a workaround that quietly weakens the gate. The failure text — Run "pnpm approve-builds" — remains advice a GUI user cannot act on; that is ask #3 and it is independent of the gate.

[argszero]

@rachel1028-blip — thank you for re-checking against the rc.1 bundle actually installed on your machine. That measurement is yours, not mine: my reading was e8f7b93a34 (dsh-v0.2.2-rc.2), yours is the artifact on the machine that failed. Both load-bearing claims holding at rc.1 means a fix in either release closes it, so nobody has to move to rc.2 to be rid of it — worth saying plainly, because "fixed in rc.2" would have left rc.1 users waiting for something that was never coming.

Ask #3 — where Run "pnpm approve-builds" comes from.

It is pnpm's, passed through. At e8f7b93a34 that sentence appears in no source file: the only occurrences in the tree are test fixtures that reproduce pnpm's output so the parser can be exercised against it (packages/boot/plugin-manager/tests/build-approval.spec.ts:77, and the git-prepared variant at :94). The manager never composes it — it reads the run's captured output tail.

The manager composes no failure prose at all. classifyInstallFailure (packages/boot/plugin-manager/src/install-failure.ts:37-44) returns only a PluginInstallFailureKind, with build-blocked as the pattern at :22. Nothing in that package maps a kind to a sentence.

But that sentence is not what the page shows. The GUI composes its own one-line reading in failureText() (packages/client/ui-plugin-manager/src/client/PluginManagerPage.tsx:955-975), through FAILURE_KIND_KEYS (:894-904, 'build-blocked' → 'installFailureBuildBlocked'). It already carries two variants, and :963 selects the second when pendingBuilds is empty:

• installFailureBuildBlocked — "A dependency's install scripts need your permission before the install can continue" (packages/client/ui-plugin-manager/src/client/locales.ts:537)
• installFailureBuildBlockedManual — "pnpm blocked install scripts; allow them under allowBuilds in pnpm-workspace.yaml and retry" (:538)

The second one is advice a GUI user can act on: it names the file, the key, and the retry. So ask #3 as phrased — advice a GUI user cannot act on — holds for pnpm's raw line, and not for the line the page renders.

The boundary, which is what decides the shape of the fix.

This is neither an unmovable passthrough nor a plugin-manager string: the wording lives in packages/client/ui-plugin-manager/src/client/locales.ts, in five locales. So the change your ask implies is a locale-string change in a client package — small, reviewable, and independent of the gate. What it cannot do is make the actionable variant appear on the upgrade surface, because that surface never carries pendingBuilds; that half stays with the gate exactly as you restated it.

One defect found while reading them, small and independent: the Spanish installFailureBuildBlockedManual (locales.ts:1133) says enableBuilds, not allowBuilds. Chinese, Japanese and English all say allowBuilds. A Spanish reader following that sentence looks for a key that does not exist — worth its own line in whatever change touches these strings.

I have not run any of this on Windows, and I am not claiming to have measured rc.1. Every file:line above is read at e8f7b93a34; the rc.1 confirmation is your measurement.

[rachel1028-blip]

🤖 本文由 AI（DeepSeek V4.1 Flash）起草。

@argszero — you were right about the failure text, and I was wrong to describe it as "advice a GUI user cannot act on." I checked this against the rc.2 bundle now installed here, and the page does not render pnpm's line. Correcting that below, plus one addition to your locale finding.

1. My ask #3 was wrong as phrased

You traced it exactly: Run "pnpm approve-builds" is pnpm's own sentence, carried in the captured output tail, not composed anywhere in the manager. And the page renders failureText(), which selects between two strings on !failure.pendingBuilds?.length:

if (failure.kind === `build-blocked` && !failure.pendingBuilds?.length)
  return t(`installFailureBuildBlockedManual`)

installFailureBuildBlockedManual names the file, the key, and the retry — a GUI user can follow it. So the raw pnpm line is unactionable; the rendered line is not. My defect three conflated the two, because I read the pnpm log and never checked what the page replaced it with. That is the same error I made with the placeholder: attributing a string to its source rather than to whoever writes it into the surface the user sees.

2. Version note — this is now a second measurement, not a restatement

Worth being precise, because I overstated my previous reply. When I said "re-checked against the rc.1 bundle," that was true at the time: the asar on that machine was 0.2.2-rc.1 (213,202,918 bytes). The host has since been upgraded to 0.2.2-rc.2 (208,137,981 bytes), so those extracted files were stale and I re-extracted from the current archive before writing this.

Under rc.2, both load-bearing claims still hold:

• updateBundle's install call passes only saveExact, enabled, expected: { name, version }, registry, requestId — no approvedBuilds (rc.2 backend, lines 2600–2609). The restore call is the same (2662–2666).
• approvedBuilds appears in the whole tree in exactly one place, the install path: if (options?.approvedBuilds !== void 0) { await approveBuilds(...); result.approvedBuilds = options.approvedBuilds } (2919–2921).

So "fixed in rc.2" is not the case, and your §5 boundary stands unchanged at the newer release: the gate is where you said it is.

3. The locale finding — Spanish, plus two you did not name

Your Spanish catch is correct. Two more locales carry the same class of error, and the discriminator does not require reading the language: the word each string names is not a setting pnpm has.

locale	string names	occurrences of that name in pnpm
allowBuilds	correct	116
dangerouslyAllowAllBuilds	correct	3
enableBuilds (es)	incorrect	0
permitBuilds (pt)	incorrect	0

• Spanish: permítalos en enableBuilds en pnpm-workspace.yaml
• Portuguese (not in your list): permita-os em permitBuilds em pnpm-workspace.yaml
• Russian (different defect): в разделеallowBuilds в pnpm-workspace.yaml — the preposition and the key are run together, missing the space. The translation is fine; the join is not.

(Quoting the strings rather than line numbers deliberately: the shipped client bundle is minified, so a line number in the distributed artifact is not stable and does not help anyone grep it. In the source tree these are the installFailureBuildBlockedManual entries in packages/client/ui-plugin-manager/src/client/locales.ts, which is where a fix belongs.)

I checked all seven locales for this specific message and these are the three defects. I am not claiming a systematic drift in the locale set generally — I only enumerated this message, so "any language may drift" would be more than I measured.

4. What that implies for the fix you scoped

You are right that the wording lives in the client package and that changing it is independent of the gate. Adding the three locales: it is six strings across three files, not five.

The structural point I would keep, because it is cheaper than proofreading: the string interpolates nothing today — allowBuilds and pnpm-workspace.yaml are typed literally into each translation. If the key name were a parameter (t('installFailureBuildBlockedManual', { key: 'allowBuilds' })), two translations could not disagree with the code about what the setting is called. That is a change to the same five locale entries you already scoped, not an additional one.

5. Where I agree with you, plainly

• The gate is the defect; the wording is a separate, smaller one.
• A plugin cannot fix either, and a wrapper that hand-edited a profile's pnpm settings to decide build-script execution would claim the permission the approval design exists to hold a person to. I would rather the gate stay strict and the dead end be fixed properly.
• Your recovery #2 remains reasoned rather than measured on this machine — the packaged GUI has no terminal with pnpm on PATH — and recovery #1 stays the path with an end-to-end result behind it.

6. One correction to my own earlier reply

I said the manager "composes no failure prose at all." That is true of the manager package, and I should have said it that way the first time instead of generalising it to the whole product — the client renders prose, and it was the client's prose I had not read.

---

Scope of everything above: backend and client claims are read from the rc.2 asar installed here, extracted this session. Locale claims are exact string matches in that same bundle. I have not run rc.2's updater against a plugin that adds a build script — I do not have a clean way to reproduce it without leaving another undecided entry in a profile, and the rc.1 failure I reported is the measurement for the behaviour itself.