Vendored pnpm 10.34.2+ / 11 / 12 scan breaks build approvals (allowBuilds / onlyBuiltDependencies): the patched package's install script stops running, and on pnpm 11/12 every frozen install fails with ERR_PNPM_IGNORED_BUILDS #1597

[agent] Found by the scheduled pnpm bug-hunt routine (ledger #303).

Summary

scan --mode vendored (and vendor) wires a pnpm project to the vendored tarball through an override, sp-build@1.0.0: file:.socket/vendor/npm/<uuid>/sp-build-1.0.0.tgz. pnpm then installs the package as sp-build@file:.socket/vendor/npm/<uuid>/sp-build-1.0.0.tgz.

Since pnpm 10.34.2, pnpm doesn't apply a build approval written for the registry package to that local tarball. This holds for both a name-only key (sp-build) and a pinned key (sp-build@1.0.0), in allowBuilds (pnpm 11/12) and in onlyBuiltDependencies (pnpm 10). Only a key that spells the full file: spec matches.

So once a package with an approved postinstall / install script is vendored:

• pnpm 10.34.2–10.34.7: the next pnpm install --frozen-lockfile exits 0 with the patched bytes but skips the approved build script. pnpm only prints "Ignored build scripts: sp-build@file:…".
• pnpm 11 / 12 (strictDepBuilds on by default), and pnpm 10 with strictDepBuilds: true: every frozen install fails with ERR_PNPM_IGNORED_BUILDS, until the patch is rolled back.

The scan exits 0 with no warning. Hosted mode is not affected: the lock keeps the sp-build@1.0.0 package key, and the approved script still runs.

This is the pnpm counterpart of Bun's vendor_bun_default_trust_lost (docs/testing/bun-compatibility.md, #371). It is related to, but separate from, npm 12's #1595: that bug is npm-specific and also hits hosted mode, while on pnpm even name-only approvals break and only vendored mode is affected.

Impact

In any pnpm ≥ 10.34.2 project that approves builds for a package Socket patches (native addons and binary installers such as esbuild, sharp, bcrypt, better-sqlite3), vendoring the patch does one of two things. On pnpm 10 it silently leaves the package unbuilt. On pnpm 11/12, which are the default for new projects, it breaks every CI install. Meanwhile vex attests the patch, because the files are patched.

Repro

This is current main 657fce2 (5.0.1) on Linux with Node 22.22.0. A local mock registry serves sp-build@1.0.0 (index.js plus "postinstall": "node post.js", which writes built.txt), and a mock org patch API serves a one-line patch to index.js.

mkdir app && cd app
echo '{"name":"app","version":"1.0.0","dependencies":{"sp-build":"1.0.0"}}' > package.json
echo 'registry=http://127.0.0.1:4873/registry/' > .npmrc
printf "allowBuilds:\n  'sp-build': true\n" > pnpm-workspace.yaml   # pnpm 10: onlyBuiltDependencies: [sp-build]
pnpm install                                   # postinstall runs, built.txt exists
socket-patch scan --mode vendored --yes --api-url http://127.0.0.1:4873 --org org --api-token fake
#   exit 0, warnings: []
#   pnpm-workspace.yaml gains: overrides: sp-build@1.0.0: file:.socket/vendor/npm/<uuid>/sp-build-1.0.0.tgz
rm -rf node_modules && pnpm install --frozen-lockfile
#   pnpm 12.11.2: Error: ERR_PNPM_IGNORED_BUILDS   (exit 1)
#   pnpm 11.28.5: [ERR_PNPM_IGNORED_BUILDS] Ignored build scripts: sp-build@file:.socket/vendor/npm/<uuid>/sp-build-1.0.0.tgz   (exit 1)
#   pnpm 10.34.6: exit 0, "Ignored build scripts: sp-build@file:…", no built.txt

Recovery checks on 12.11.2:

• Adding 'sp-build@file:.socket/vendor/npm/<uuid>/sp-build-1.0.0.tgz': true to allowBuilds makes the frozen install pass and the script run. That key is relative, but it names the patch uuid, so it has to change on every supersede.
• pnpm approve-builds --all reports "There are no packages awaiting approval" and changes nothing.
• socket-patch rollback restores the workspace file, and the next frozen install passes with the script run.

Expected vs actual

• Expected: a vendored scan doesn't change which dependency build scripts pnpm runs. If it can't keep an approval valid, it warns, or adds the matching name@file:<spec> approval beside the user's own and removes it on revert. Other install gates already do this: vendor_bun_default_trust_lost (bun-compatibility.md) and vendor_npm_allow_file (npm-compatibility.md). docs/testing/pnpm-compatibility.md says a vendored pnpm project is patched by a plain frozen install, and doesn't mention build approvals.
• Actual: exit 0 and warnings: []. On pnpm 10.34.2+ the approved script is silently skipped. On pnpm 11/12 every frozen install fails with ERR_PNPM_IGNORED_BUILDS.

Matrix (Linux, Node 22.22.0, main 657fce2)

In every vendored cell the patched marker landed in index.js. macOS and Windows weren't run, because this routine's probe branches are on hold. pnpm's matcher is platform-independent.

First bad version

Not a socket-patch regression: every socket-patch release vendors pnpm through a file: override. The bug became reachable with pnpm 10.34.2 (published 2026-06-10). 10.34.1 still applies a name-only approval to the local tarball; 10.34.2 doesn't. pnpm 11 and 12 behave like 10.34.2, and also fail the install by default.

Suspect code

• crates/socket-patch-core/src/vendor/pnpm_lock.rs:128 (vendor_pnpm), with the override writers apply_pkg_override (:1870) and apply_workspace_override (:2084). Nothing reads allowBuilds / onlyBuiltDependencies / neverBuiltDependencies / strictDepBuilds, or the package's scripts / binding.gyp.
• Prior art for the warning: crates/socket-patch-core/src/vendor/bun_lock.rs:657 (default_trust_warning) and crates/socket-patch-core/src/vendor/npm_lock.rs:1588 (vendor_npm_allow_file).