Problem
When scan --mode hosted rewrites a pnpm-lock.yaml, it repoints tarball URLs at patch.socket.dev. pnpm >=11 added a lockfile supply-chain policy that compares each resolution's tarball URL against the registry's published metadata and REJECTS the lockfile:
[ERR_PNPM_TARBALL_URL_MISMATCH] <pkg> has a tarball URL
(https://patch.socket.dev/...) that does not match the registry's
published metadata (https://registry.npmjs.org/...)
The documented opt-out is pnpm install --trust-lockfile (which installs the patched artifact cleanly), but scan --mode hosted emitted NO warning naming it — unlike the redirect warnings it already produces for other post-rewrite install caveats (Rush redirect_rush_repo_state_stale, the bun-migration warnings, record_fetch_failed). The production e2e sweep already documents this as a known compat gap (crates/socket-patch-cli/tests/e2e_hosted_production.rs:995-1023).
Fix
crates/socket-patch-cli/src/commands/scan/hosted.rs:346-370 — after the rewrite, when any rewritten file's basename is pnpm-lock.yaml (the plain root lock OR a Rush nested/subspace lock), push a redirect_pnpm_trust_lockfile warning into the same warnings channel the neighboring redirect_* warnings use. It is surfaced in both the JSON warnings[] array (hosted.rs:513) and human-mode stderr (hosted.rs:576-578), consistent with the rush/migration/record warnings.
The warning names ERR_PNPM_TARBALL_URL_MISMATCH and instructs the user to run pnpm install --trust-lockfile.
Test
crates/socket-patch-cli/tests/in_process_redirect.rs — pnpm_lock_redirect_warns_to_trust_lockfile (hermetic, wiremock, subprocess so --json warnings[] can be read back). Two legs mirroring the rush gating test: a pnpm root-lock project asserts redirected == 1, the redirect_pnpm_trust_lockfile code is present, and its detail names --trust-lockfile; the npm-only twin (package-lock.json) rewrites identically but emits no such warning. Confirmed RED before the fix (got warnings ["redirect_npm_no_lockfile"]), GREEN after.
cargo build -p socket-patch-cli succeeds; in_process_redirect (23) + in_process_redirect_pnpm (3) all pass.
Scope
Single warning addition in scan::hosted + one regression test. No behavior change to the rewrite itself. Kills sweep finding pnpm11-hosted-policy-reject-no-warning (K2, P2). No cross-dependencies with the other parallel fixes.
🤖 Generated with Claude Code
Note
Low Risk
Warning-only change in scan hosted mode; no change to lockfile rewrite logic or install behavior.
Overview
Hosted scan --redirect now emits redirect_pnpm_trust_lockfile when a rewrite actually changes any pnpm-lock.yaml (root or Rush nested/subspace locks). The message explains that pnpm ≥11 can fail with ERR_PNPM_TARBALL_URL_MISMATCH after tarball URLs are repointed to patch.socket.dev, and tells users to run pnpm install --trust-lockfile.
The warning is merged into the same JSON warnings[] channel and human stderr as the existing Rush and migration redirect caveats. npm-only projects that only touch package-lock.json do not get it.
A hermetic subprocess test asserts the warning code, --trust-lockfile in the detail, and that npm-only redirects stay silent.
Reviewed by Cursor Bugbot for commit 3f74174. Configure here.