pnpm hosted → vendored takeover un-hosts the package before pnpm's vendored refusals run, so a catalog entry, a CRLF lock or a workspace exact-pin override leaves it unpatched in both modes

[mikolalysenko]

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

Summary

scan --mode vendored over a hosted pnpm pin restores the pin to its upstream registry entry first, and only then runs the pnpm vendored backend. When the backend then refuses the package for a project-level or lock-shape reason that hosted mode handles fine, the package ends up in neither mode. The hosted pin is gone from pnpm-lock.yaml, nothing is vendored, and the next install gets the unpatched registry bytes.

Three ordinary shapes trigger it, and they're all documented vendored refusals:

• a pnpm catalog dependency ("left-pad": "catalog:") → vendor_lock_entry_unsupported
• a CRLF pnpm-lock.yaml (a core.autocrlf checkout; hosted mode handles CRLF) → vendor_lockfile_crlf_unsupported
• a user exact-pin override in pnpm-workspace.yaml (overrides: { left-pad: 1.3.0 }) → vendor_override_conflict

The run does exit 1 / partial_failure, but the restore has already been written, so the project has lost its patch.

Impact

A project that is correctly hosted-patched and asks to switch to vendored loses its patch. Its committed lock now installs the vulnerable upstream release. Re-running hosted mode recovers, but nothing in the output says the package was un-hosted. The only hint is the vendor_takeover_reverted_redirect advisory next to the failure.

Repro (Linux, Node 22, main 4646693)

I used a local mock patch API that serves left-pad@1.3.0 with a marker prepended to index.js (hosted tarball, vendor grant, view, /registry mirror; SOCKET_PATCH_SERVER_URL / SOCKET_NPM_REGISTRY point at it).

API="--api-url http://127.0.0.1:8787 --org acme --api-token x"
mkdir p && cd p
echo '{"name":"c","version":"1.0.0","dependencies":{"left-pad":"catalog:"}}' > package.json
printf 'packages:\n  - .\ncatalog:\n  left-pad: 1.3.0\n' > pnpm-workspace.yaml
pnpm install
socket-patch scan --mode hosted --json --yes $API      # success, redirected 1; lock pins the hosted tarball
socket-patch scan --mode vendored --dry-run --json --yes $API   # exit 0, action would_vendor, no refusal predicted
socket-patch scan --mode vendored --json --yes $API    # exit 1, partial_failure:
#   vendor_takeover_reverted_redirect  (hosted pin restored to registry)
#   failed vendor_lock_entry_unsupported (catalog)
grep -c 127.0.0.1 pnpm-lock.yaml                       # 0: the hosted pin is gone
ls .socket/vendor 2>/dev/null                          # nothing vendored
rm -rf node_modules && pnpm install --frozen-lockfile  # exit 0, unpatched upstream left-pad

For the CRLF variant, use a plain "left-pad": "1.3.0" dependency and run sed -i 's/$/\r/' pnpm-lock.yaml after the hosted scan. For the override variant, use a plain dependency plus overrides:\n left-pad: 1.3.0 in pnpm-workspace.yaml.

Expected vs actual

• Expected: CLI_CONTRACT.md, "Takeover reconciliation": a vendored backend's refusal is checked before the upstream restore, "so a hosted purl on a lock the vendored backend refuses … is reported failed <code> with the hosted wiring and active … lock byte-untouched (exit 1 / partial_failure): the package stays hosted-patched instead of being un-hosted and then refused". That's implemented for Bun (bun_preflight), yarn berry and npm package-lock (npm lockfileVersion 1: scan/get --mode vendored un-host a hosted patch and then refuse to vendor it, so the project silently goes back to unpatched (vendor eject rolls back correctly) #659). --dry-run should preview the same failed <code>.
• Actual (pnpm): the restore runs, then the pnpm backend refuses. The package is unpatched in both modes. --dry-run predicts would_vendor, exit 0.

Matrix (scan exit / hosted pins left in the lock / fresh pnpm install --frozen-lockfile)

pnpm	catalog	CRLF lock	workspace exact-pin override	control (plain dep)
9.15.9	1 / 0 / unpatched	1 / 0 / unpatched	1 / 0 / unpatched	not run
10.34.5	1 / 0 / unpatched	1 / 0 / unpatched	1 / 0 / unpatched	not run
11.28.3	1 / 0 / unpatched	1 / 0 / unpatched	1 / 0 / unpatched	not run
12.8.1	1 / 0 / unpatched	1 / 0 / unpatched	1 / 0 / unpatched	0 / 0 / patched (vendored)

Every failing cell was reproduced at least twice (12.8.1 and 10.34.5 three times). I tested Linux only. The ordering is OS-independent, and the CRLF variant is the one Windows autocrlf users would hit.

Not a regression: release 4.0.0 behaves the same (catalog variant, pnpm 12.8.1: exit 1, vendor_lock_entry_unsupported after vendor_takeover_reverted_redirect, hosted pin gone).

Suspect code

• crates/socket-patch-cli/src/commands/vendor.rs:2517-2576: for pkg:npm/ candidates the pre-restore gate runs only yarn_berry_vendor_preflight, npm_lock_vendor_preflight and yarn_berry_vendor_target_preflight, and then calls restore_upstream (:2576). There is no pnpm equivalent for the pnpm backend's project and entry refusals: the CRLF lock / workspace check, the catalog and peer-suffixed vendor_lock_entry_unsupported, the vendor_override_conflict checks in crates/socket-patch-core/src/vendor/pnpm_lock.rs:617-625 (classify_pkg_override / check_lock_override / check_workspace_override), and the legacy-lock vendor_lockfile_version_unsupported.
• The same shape was filed for other backends as npm vendored refuses a registry package with vendor_workspace_member whenever a local file: directory (or workspace member) has the same name@version, and the hosted→vendored takeover then un-hosts it, leaving it unpatched #688 (npm, vendor_workspace_member) and Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775 (gem).

[mikolalysenko]

[agent] Triage: priority:p1. pnpm (npm-family). Same shape as gem #775 (fix in open PR #776) and the yarn berry takeover preflight: vendor_records_reusing restores the hosted pin before the ecosystem's vendored refusals run. The pnpm side needs its own preflight. One trigger (workspace exact-pin override) is also #854.

---

Generated by Claude Code

[mikolalysenko]

[agent] Shares root cause with #944: the hosted → vendored takeover in crates/socket-patch-cli/src/commands/vendor.rs restores the hosted pin (restore_upstream) before the target backend's vendored refusals run, and the pre-restore preflight only has gem and npm/berry cases (no pnpm, no PyPI). Will be fixed together.

---

Generated by Claude Code

[mikolalysenko]

[agent] Claiming this issue (with #944; shared root cause: the hosted → vendored takeover in vendor.rs commits the upstream restore before the target vendored backend's refusals run). Branch: agent/fix-takeover-vendored-preflight. Claim-ID: 2026-10-06T20:21:01Z-4b53a1

---

Generated by Claude Code

[mikolalysenko]

[agent] Draft PR: #963

---

Generated by Claude Code

[mikolalysenko]

[agent] #963 is ready for review and fixes the data loss. When the vendored backend refuses a hosted pnpm purl (catalog, CRLF lock, workspace override, or any other refusal), the takeover's upstream restore is now rolled back inside the run's group commit, so the hosted pin stays byte-for-byte and the purl fails with the backend's own code. vendor --dry-run also previews that refusal now.

This issue stays open (the PR says Refs, not Fixes) for one remaining piece: the scan / get --mode vendored --dry-run preview is an offline ledger-only classification that doesn't model the takeover, so it still says would_vendor for these shapes. That will be a follow-up slice after #963.

---

Generated by Claude Code