vendor --check fails a vendored package whose lock is contested by a sibling package-lock.json with "no lockfile or config references .socket/vendor/… any more", which is false, and its remedy ("re-run socket-patch vendor") is a no-op, so the check stays red forever

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

Summary

Take a project with package-lock.json and another npm-family lock (yarn.lock, bun.lock) that both resolve left-pad@1.3.0 from the registry. scan --mode vendored wires the lock its backend selects (yarn.lock here) and warns vendor_multiple_lockfiles ("package-lock.json is not wired … installs driven by package-lock.json will still install the UNPATCHED registry bytes"), as documented. Since #730 (#725), vendor --check runs the lock-wiring probe, and it then exits 1 with:

pkg:npm/left-pad@1.3.0: wiring missing: no lockfile or config references .socket/vendor/npm/<uuid> any more, so a fresh install gets the unpatched package; re-run `socket-patch vendor` to rewire it

yarn.lock does reference .socket/vendor/npm/<uuid>. The real reason is that package-lock.json contests it. Following the remedy changes nothing:

socket-patch vendor prints "No manifest to vendor from; 1 vendored entry is tracked in the ledger — socket-patch repair verifies it."
socket-patch scan --mode vendored prints "1 package is already vendored; nothing to do."
socket-patch repair is a no-op.

vendor --check stays exit 1 for good. vex diagnoses the same tree correctly ("yarn.lock: … wired …, but package-lock.json resolves the same version from elsewhere … rewire both locks … or delete the stale one", patched_ref_unattributable). But it then also prints the same false vendor_unwired line ("no lockfile or config wires it to this package any more").

Failing closed is right, because npm ci from package-lock.json installs unpatched bytes. The defect is the diagnostic: it names the wrong cause, and its only remedy is a command that can't fix it. The fix is to delete or rewire package-lock.json.

Impact

CI gating on vendor --check goes red after a successful vendored scan. The message and remedy send the user around a loop (vendor → repair → scan → still red), and nothing names package-lock.json.

Repro (Linux, main `9c43dfc`, npm 10.9.4 + yarn 1.22.22)

A local mock patch API serves a free patch for pkg:npm/left-pad@1.3.0.

mkdir app && cd app
echo '{"name":"app","version":"1.0.0","dependencies":{"left-pad":"1.3.0"}}' > package.json
npm install && yarn install          # package-lock.json + yarn.lock
git init -q && echo node_modules > .gitignore && git add -A && git commit -qm init
socket-patch scan --mode vendored --json --yes --api-url $MOCK --org o --api-token x
#   exit 0, success; events: applied, vendor_multiple_lockfiles; yarn.lock rewired
socket-patch vendor --check           # exit 1, "wiring missing: no lockfile or config references … any more"
socket-patch vendor --yes             # "No manifest to vendor from; …"
socket-patch scan --mode vendored --yes   # "1 package is already vendored; nothing to do."
socket-patch repair --yes             # no change
socket-patch vendor --check           # still exit 1, same message

2/2 runs. The Bun routine saw the same thing with bun.lock + package-lock.json (Bun 1.4.2) and yarn 1.22.22 + npm 10 (handover on ledger #302).

Expected vs actual

Expected: vendor --check (CLI_CONTRACT's verification gate, and the same liveness rule as vex) should report the contest the way vex does: name package-lock.json as resolving the package from the registry, and suggest rewiring or deleting it. It shouldn't claim no lockfile references the artifact, or suggest a command that reports "nothing to do".
Actual: a false "no lockfile or config references" message, with a no-op remedy.

OS × version

OS	locks	`vendor --check`	remedy loop
Linux	package-lock v3 (npm 10.9.4) + yarn.lock (yarn 1.22.22)	exit 1, false message (×2)	`vendor` / `scan` / `repair` no-op
Linux	package-lock (npm 10) + bun.lock (Bun 1.4.2), from the Bun routine	same	same
macOS / Windows	not probed; no OS-specific code path

Not a regression in the usual sense: vendor --check didn't probe wiring before #730.

Suspect code

crates/socket-patch-cli/src/commands/vendor.rs:1036-1046: discovery.vendor_entry_live(root, entry) returns false both when no lock references the entry and when the reference is rejected as contested (patched_ref_unattributable). The message always assumes the first case.
The same conflation produces vex's trailing vendor_unwired line after its correct patched_ref_unattributable warning.

Related: #725 / #730 (added the probe), #798 / #799 (cross-lock contest), #656 (another remedy loop).

[agent] npm bug-hunt (ledger #302): there's a second trigger for the same false message and no-op remedy, handed over by the Bun routine and confirmed on npm. On main 9c43dfc (Linux), vendor two packages and then run a plain npm uninstall on one of them. vendor --check exits 1 for the removed package with:

wiring missing: no lockfile or config references .socket/vendor/npm/<uuid> any more, so a fresh install gets the unpatched package; re-run `socket-patch vendor` to rewire it

The first half is true here, since the lock no longer mentions the uuid. The rest is wrong:

"a fresh install gets the unpatched package": a fresh install doesn't get the package at all.
The remedy socket-patch vendor exits 0 with noManifest and changes nothing, so the check stays red.

The remedy that does work is scan --mode vendored --prune. Since #689 it reverts the entry (gc.revertedVendoredEntries: ["pkg:npm/is-number@7.0.0"]), and vendor --check then passes. A plain scan --mode vendored already prints the right hint (vendor_ledger_entry_unwired: … the dependency was upgraded or removed … run socket-patch scan --prune). So vendor --check is the only command that points users at a no-op.

echo '{"name":"p","version":"1.0.0","private":true,"dependencies":{"is-number":"7.0.0","left-pad":"1.3.0"}}' > package.json
npm i
socket-patch scan --mode vendored --yes --json <mock api flags>   # both vendored
npm uninstall is-number                                           # lock no longer mentions the is-number uuid
socket-patch vendor --check --json; echo $?                       # 1, message above (x2)
socket-patch vendor --yes --json                                  # noManifest, exit 0
socket-patch vendor --check --json; echo $?                       # still 1
socket-patch scan --mode vendored --prune --yes --json <flags>    # reverts is-number
socket-patch vendor --check --json; echo $?                       # 0

npm (Linux)	lockfileVersion	`vendor --check` after uninstall (x2)	`vendor` remedy	`scan --prune`	`vex`	fresh `npm ci`
8.19.4 (Node 22)	2	exit 1, same message	no-op	—	—	left-pad patched
10.9.4 (Node 22)	3	exit 1, same message	no-op	fixes it	exit 0, honest	left-pad patched
12.2.0 (Node 24)	3	exit 1, same message	no-op	fixes it	exit 0, honest	left-pad patched

On npm 8 (v2), the uninstall re-save also drops resolved from the legacy mirror, so the still-wired left-pad fails with the same "no lockfile or config references" line although packages["node_modules/left-pad"].resolved points at its artifact. That one is the #879 shape and only shows here as the same misleading text.

A fix for the contested case alone (naming package-lock.json) won't cover this trigger. The vendor.rs:1036-1046 branch also needs to tell "no lock references this package any more" apart from "the package is still in the lock but resolves elsewhere", and point the first case at scan --prune / remove <purl>.

Generated by Claude Code

npm: run 26 ledger (#969, #900 comment)

[agent] Claiming this issue. Root cause: Discovery::vendor_entry_live returns a bare bool. It is false both when another lock contests the ref and when no lock resolves the package any more, so vendor --check (and vex) always print the "no lockfile references …; re-run socket-patch vendor" text. The fix covers both triggers: the cross-lock contest and the npm uninstall follow-up. Branch: agent/fix-vendor-check-unwired-cause. Claim-ID: 2026-10-07T00:20:40Z-abfc00

Generated by Claude Code

[agent] Draft PR: #970

Generated by Claude Code

Name the real cause when vendor --check fails

Navigation Menu

Repository navigation

vendor --check fails a vendored package whose lock is contested by a sibling package-lock.json with "no lockfile or config references .socket/vendor/… any more", which is false, and its remedy ("re-run socket-patch vendor") is a no-op, so the check stays red forever #900

Summary

Impact

Repro (Linux, main `9c43dfc`, npm 10.9.4 + yarn 1.22.22)

Expected vs actual

OS × version

Suspect code

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

vendor --check fails a vendored package whose lock is contested by a sibling package-lock.json with "no lockfile or config references .socket/vendor/… any more", which is false, and its remedy ("re-run socket-patch vendor") is a no-op, so the check stays red forever #900

Description

Summary

Impact

Repro (Linux, main 9c43dfc, npm 10.9.4 + yarn 1.22.22)

Expected vs actual

OS × version

Suspect code

Activity

mikolalysenko commented on Oct 7, 2026

mikolalysenko commented on Oct 7, 2026

mikolalysenko commented on Oct 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Repro (Linux, main `9c43dfc`, npm 10.9.4 + yarn 1.22.22)