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

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

Summary

The #1074 fix (e8b6adc, PR #1431) reads pnpm's lockfile setting from the file the project's pnpm major reads: YAML on pnpm 11+, .npmrc on pnpm ≤10. The environment fallback doesn't do this. lockfile_disabled always accepts both pnpm_config_lockfile and npm_config_lockfile, and falls back to npm_config_package_lock, whatever the major. Real pnpm reads only one family of variables:

(The "lock used" cells were checked by running pnpm install with the variable set and seeing whether pnpm-lock.yaml was written. Every cell where socket-patch refuses falls under "lock used", apart from the two "off" controls listed below.)

So hosted mode leaves the lock unpinned and warns redirect_pnpm_lockfile_disabled for projects whose pnpm installs from the lock just fine. The refusal fires when it shouldn't.

The realistic trigger needs no CI variable at all. npm exec / npx / npm run export npm_config_package_lock= whenever a project or user .npmrc has package-lock=false, which many repos migrated from npm still carry and which pnpm 11+ ignores. Running npx @socketsecurity/socket-patch scan --mode hosted in such a pnpm 11/12 project gets refused. A direct run of the same binary on the same tree pins it.

Impact

Hosted mode silently does nothing for these projects (exit 0, status: success). The warning tells the user that pnpm ignores their lock and suggests --mode vendored or "remove the setting", which is false for their pnpm. The result also depends on how the CLI was launched (npx vs direct), not on the project.

Repro (Linux, main 15c2c83, pnpm 12.11.2, local mock of the patch API serving left-pad@1.3.0, same contract as tests/e2e_redirect_pnpm_build.rs)

mkdir app && cd app
echo '{"name":"app","version":"1.0.0","dependencies":{"left-pad":"1.3.0"}}' > package.json
echo 'package-lock=false' > .npmrc        # ignored by pnpm 11/12
pnpm install                              # pnpm 12.11.2 writes pnpm-lock.yaml (lockfileVersion 9.0)
A="--api-url http://127.0.0.1:8765 --org test-org --api-token fake"
npm exec -c "socket-patch scan --mode hosted --json --yes $A"
#  exit 0, warnings: [redirect_pnpm_lockfile_disabled]
#  detail: "`npm_config_package_lock=` in the environment makes pnpm neither read nor write pnpm-lock.yaml ..."
#  pnpm-lock.yaml unchanged
socket-patch scan --mode hosted --json --yes $A
#  exit 0, warnings: [redirect_pnpm_trust_lockfile], lock pinned to the hosted tarball
rm -rf node_modules
npm_config_package_lock= pnpm install --frozen-lockfile --store-dir /tmp/fresh
head -1 node_modules/left-pad/index.js    # /* SOCKET-PATCHED */ : pnpm 12 honours the lock with that env set

The minimal form is npm_config_lockfile=false socket-patch scan --mode hosted ... on any pnpm 11/12 project, or pnpm_config_lockfile=false ... on any pnpm 9/10 project.

Expected vs actual

• Expected: CLI_CONTRACT.md "pnpm with its lockfile off (Hosted pnpm scan pins a pnpm-lock.yaml that pnpm is configured to ignore (lockfile=false / lockfile: false), reports success, and lock-only VEX attests not_affected while pnpm installs the upstream package #1074)" says "Each pnpm major reads the setting from one file". The refusal is meant to fire only when pnpm "neither read[s] nor write[s] pnpm-lock.yaml". The environment should follow the same major split: npm_config_* for pnpm ≤10 and pnpm_config_* for pnpm ≥11 (both only when the major is unknown, matching the file rule).
• Actual: either variable family, plus npm_config_package_lock, refuses on every major.

OS × version

macOS and Windows weren't probed. The logic is OS-independent.

First bad commit

e8b6adc (#1431). Release 5.0.0 predates the refusal.

Suspect code

• crates/socket-patch-core/src/utils/pnpm_workspace.rs:600-603: the env arm of lockfile_disabled runs env_setting before the major is known and returns it via .or(env) regardless of major.
• crates/socket-patch-core/src/utils/pnpm_workspace.rs:128 (env_setting) tries pnpm_config_<key> then npm_config_<key> for every caller. view_setting (:145) uses it the same way for gitBranchLockfile / sharedWorkspaceLockfile, so those env lookups probably have the same major blindness. I haven't verified that.

Not a VEX issue: lock-only vex calls lockfile_disabled(view, false).