Hosted pnpm 11/12 scan ignores a pnpm_config_trust_lockfile=false env override and says "installs need no extra flags", but the next frozen install fails with ERR_PNPM_TARBALL_URL_MISMATCH #1514

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

Summary

On pnpm 11 and 12, an environment setting pnpm_config_trust_lockfile=false (or PNPM_CONFIG_TRUST_LOCKFILE=false) takes precedence over the trustLockfile: true that hosted mode writes into pnpm-workspace.yaml. scan --mode hosted never reads that variable, even when it is set in the scan's own environment. It writes the key, reports success, and its redirect_pnpm_trust_lockfile warning says "commit it alongside the lock; installs need no extra flags". Every install with that environment then fails with ERR_PNPM_TARBALL_URL_MISMATCH.

npm has the same kind of setting, and socket-patch already handles it there: patch/redirect/npmrc.rs respects an explicit npm_config_allow_remote env var ("beats every file"). #1460 / #1074 taught the pnpm side to read npm_config_* / pnpm_config_* for lockfile, but not for trustLockfile.

Impact

A CI that deliberately pins trustLockfile off (for example, to keep pnpm's lockfile re-verification) gets a red install after a "successful" hosted scan. Nothing in the scan output points at the variable. pnpm's own error then tells the user to rebuild the lockfile, which silently drops the hosted patches; the warning does tell them not to do that. The failure is loud, so nothing unpatched gets attested, but the remedy the scan gives is wrong for this environment.

Repro

# Mock patch API on :18080 serving pkg:npm/left-pad@1.3.0 (batch, by-package, view, package grant,
# hosted tarball, /registry mirror), same contract as tests/e2e_redirect_pnpm_build.rs.
export SOCKET_PATCH_SERVER_URL=http://127.0.0.1:18080 SOCKET_NPM_REGISTRY=http://127.0.0.1:18080/registry
export pnpm_config_trust_lockfile=false          # set in CI and in the shell that runs the scan
mkdir proj && cd proj
echo '{"name":"root","version":"1.0.0","dependencies":{"left-pad":"1.3.0"}}' > package.json
pnpm install                                     # pnpm 12.11.2
socket-patch scan --mode hosted --json --yes --api-url http://127.0.0.1:18080 --org org --api-token x
#  status success; writes pnpm-workspace.yaml {packages: ['.'], trustLockfile: true}
#  redirect_pnpm_trust_lockfile: "... `trustLockfile: true` was written to a new pnpm-workspace.yaml —
#  commit it alongside the lock; installs need no extra flags."
mkdir ../fresh && cp package.json pnpm-lock.yaml pnpm-workspace.yaml ../fresh && cd ../fresh
pnpm install --frozen-lockfile --store-dir "$(mktemp -d)"
#  ERR_PNPM_TARBALL_URL_MISMATCH, exit 1
pnpm_config_trust_lockfile=true pnpm install --frozen-lockfile --store-dir "$(mktemp -d)"   # control: exit 0, patched

Expected vs actual

• Expected: CLI_CONTRACT ("For a 9.0 root lock") says the trust write "preserves explicit user settings" and that the warning "explains manual configuration when required". An explicit trustLockfile: false in the YAML is respected and warned about with the remedy (TrustPlan::UserSet). An env override that the installed pnpm honours is an explicit user setting too. It should be detected the way Hosted pnpm scan refuses with redirect_pnpm_lockfile_disabled over env lockfile settings the project's pnpm major ignores (e.g. any pnpm 11/12 project run through npm exec with package-lock=false) #1460 detects lockfile in env (npm_config_* / pnpm_config_*, per the project's pnpm major) and the way the npm arm detects npm_config_allow_remote. The warning should then name the variable and give the fix: unset it, set it to true for installs, or use --mode vendored.
• Actual: the variable is never read. The scan claims installs need no extra flags, and the frozen install fails.

OS × version

Linux, Node 22, main 887a5f7, real pnpm, fresh copy of the committed files and an empty store for each install:

macOS and Windows weren't probed. Reading env and settings isn't OS-specific.

First bad version: none bisected. Auto-trust has never consulted the environment.

Suspect code

• crates/socket-patch-core/src/hosted/engine.rs:2504: the trust-detail branch chooses between AlreadyTrue / UserSet / write based only on the workspace file's text (plan_workspace_trust). Nothing checks the process env.
• The Hosted pnpm scan refuses with redirect_pnpm_lockfile_disabled over env lockfile settings the project's pnpm major ignores (e.g. any pnpm 11/12 project run through npm exec with package-lock=false) #1460 env reader for lockfile (crates/socket-patch-core/src/utils/pnpm_workspace.rs), which is major-aware, and patch/redirect/npmrc.rs (npm_config_allow_remote) are the models for the fix.