Hosted scan on a pnpm workspace with `sharedWorkspaceLockfile: false` ignores the per-package pnpm-lock.yaml files and reports success while redirecting nothing

[mikolalysenko]

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

Summary

With sharedWorkspaceLockfile: false (shared-workspace-lockfile=false in .npmrc on older majors), pnpm writes one pnpm-lock.yaml per workspace package (packages/a/pnpm-lock.yaml, packages/b/pnpm-lock.yaml, …). The root pnpm-lock.yaml covers only the root importer, and is often just importers: .: {}.

scan --mode hosted from the workspace root finds the vulnerable package in node_modules, then reads only the root lock (plus the Rush locks when rush.json exists). The member locks that pnpm actually installs from are never opened. The run ends with exit 0, status: success, redirect.redirected: 0, rewrittenFiles: [], and one redirect_pnpm_entry_not_found warning ("no resolution for is-number@7.0.0"). Every package in the workspace keeps installing the unpatched registry tarball.

Impact

• Hosted mode silently does nothing on this documented pnpm layout. success / exit 0 tells CI and users the project is patched when no lock was changed.
• VEX stays honest: with nothing pinned, vex finds nothing to attest. So the failure is "unpatched, but reported as a successful hosted scan", not a false attestation.
• The obvious workaround fails on pnpm 11+. Running scan --mode hosted --cwd packages/a does pin packages/a/pnpm-lock.yaml, but it also creates packages/a/pnpm-workspace.yaml (packages: ['.'] + trustLockfile: true). That turns the member into a nested workspace root, and pnpm ignores the file when installing from the real root. A fresh pnpm install --frozen-lockfile from the root on pnpm 12.8.1 then fails with ERR_PNPM_TARBALL_URL_MISMATCH.
• Vendored mode on the same layout refuses loudly (vendor_lock_entry_not_found, partialFailure, exit 1), which is acceptable fail-closed behaviour.

Repro

mkdir -p ws/packages/a ws/packages/b && cd ws
echo '{"name":"root","version":"0.0.0","private":true}' > package.json
echo '{"name":"a","version":"1.0.0","dependencies":{"is-number":"7.0.0"}}' > packages/a/package.json
echo '{"name":"b","version":"1.0.0","dependencies":{"to-regex-range":"5.0.1"}}' > packages/b/package.json   # is-number@7.0.0 transitively
printf "packages:\n  - 'packages/*'\nsharedWorkspaceLockfile: false\n" > pnpm-workspace.yaml
echo 'shared-workspace-lockfile=false' > .npmrc        # pnpm <= 10 reads this
pnpm install
ls pnpm-lock.yaml packages/*/pnpm-lock.yaml           # three locks; the root one is `importers: .: {}`
socket-patch scan --mode hosted --json --yes ...      # patch for pkg:npm/is-number@7.0.0 is available
#  status: success, exit 0, redirect.redirected: 0, rewrittenFiles: [],
#  warnings: [{code: redirect_pnpm_entry_not_found, detail: "no resolution for is-number@7.0.0"}]
grep -c 'tarball:' packages/*/pnpm-lock.yaml           # 0 everywhere
# fresh checkout + pnpm install --frozen-lockfile -> both a and b load the upstream bytes

(I ran this against a local mock of the patch API: batch / by-package / package grant / view / hosted tarball, with SOCKET_PATCH_SERVER_URL and SOCKET_NPM_REGISTRY pointed at it, the same harness as the repo's e2e_redirect_pnpm_build.rs. The oracle is a marker prepended to is-number/index.js.)

Expected vs actual

• Expected: docs/ecosystems.md (npm hosted-mode notes) says pnpm "workspaces … are handled. Every matching package instance is rewritten; an unsupported instance prevents confirming that dependency across the lockfile set." A pnpm workspace's lockfile set includes its per-package locks when sharedWorkspaceLockfile is false, so each packages/*/pnpm-lock.yaml that resolves the package should be pinned, with trustLockfile going into the root pnpm-workspace.yaml. At minimum, the run should fail closed (partialFailure / non-zero, as vendored does) instead of reporting success.
• Actual: only the root lock is read, nothing is rewritten, and the status is success, exit 0.

Matrix (Linux, main 61cfb9b)

OS	pnpm	lock	hosted from the workspace root	vendored from the root
Linux	8.15.9	6.0	fail (success, 0 redirected)	not run
Linux	9.15.9	9.0	fail (2/2)	refuses vendor_lock_entry_not_found (OK)
Linux	10.34.5	9.0	fail	refuses (OK)
Linux	11.28.3	9.0	fail	refuses (OK)
Linux	12.8.1	9.0	fail (2/2)	refuses (OK)
Linux	12.8.1	9.0	workaround --cwd packages/a: lock pinned, but the root frozen install fails with ERR_PNPM_TARBALL_URL_MISMATCH

Control: the same workspace with the default shared lock is redirected, installs patched bytes in both members, and rolls back byte for byte (passes on 9.15.9 / 10.34.5 / 11.28.3 / 12.8.1). macOS and Windows weren't probed, but the code path is OS-independent.

Not bisected. The 4.0.0 release can't be driven against the v5-shaped mock, and the candidate-file list has never included member locks.

Suspect code

• crates/socket-patch-core/src/hosted/engine.rs:404 (read_candidate_files): it reads REDIRECT_CANDIDATE_FILES (root pnpm-lock.yaml), Cargo members, Python locks and the Rush locks (:449, rush_repo), but it never expands the pnpm-workspace.yaml packages: globs into per-member pnpm-lock.yaml keys. The comment there notes that the pnpm rewriter is already basename-generalized for nested keys, so adding member locks (and pointing the trust edit at the root workspace file) looks like the shape of a fix.
• crates/socket-patch-core/src/formats/pnpm/hosted.rs:393: redirect_pnpm_entry_not_found is a warning only, so the miss doesn't affect the status.

---

Backlog review — 2026-10-08

Priority: P1 → P2. Nonshared pnpm workspace locks are missed; scan pins nothing and VEX does not falsely attest.

[mikolalysenko]

[agent] Triaged: priority:p1 (pnpm, npm family). Not a duplicate, and no open fix PR. The cause is in hosted/engine.rs read_candidate_files, which never adds per-member pnpm-lock.yaml files when sharedWorkspaceLockfile: false. The success status despite redirect_pnpm_entry_not_found is part of the same report.

---

Generated by Claude Code

[mikolalysenko]

[agent] Same bug on pnpm 7.33.7 (lock 5.4), main 61cfb9b, Linux. It reproduced 2 of 2 times, and the symptom differs slightly from 8–12.

pnpm 7 with shared-workspace-lockfile=false in .npmrc writes no root pnpm-lock.yaml at all, only packages/a/pnpm-lock.yaml. Running scan --mode hosted from the root still exits 0 with status: success and redirected: 0. The only warning is redirect_pnpm_no_lockfile ("pnpm project … but no pnpm-lock.yaml; run pnpm install to generate one"). That advice is misleading here, because pnpm install never creates a root lock in this layout. packages/a/pnpm-lock.yaml stays unpinned, and a fresh pnpm install --frozen-lockfile installs the upstream is-number@7.0.0 bytes.

mkdir -p ws/packages/a && cd ws
echo '{"name":"root","private":true}' > package.json
printf 'packages:\n  - packages/*\n' > pnpm-workspace.yaml
echo 'shared-workspace-lockfile=false' > .npmrc
echo '{"name":"a","version":"1.0.0","dependencies":{"is-number":"7.0.0"}}' > packages/a/package.json
npx pnpm@7.33.7 install            # only packages/a/pnpm-lock.yaml exists
socket-patch scan --mode hosted --json --yes   # success, redirected 0, redirect_pnpm_no_lockfile

Any fix for the member locks should also cover the case where there's no root lock.

---

Generated by Claude Code

[mikolalysenko]

[agent] Claiming this issue as part of the pnpm open-issue sweep in draft PR #1007. Branch: agent/fix-pnpm-open-issues. Claim-ID: 2026-10-07T12:44:29Z-pnpm07