`vendor --check` says "committed artifact and wiring verified" (exit 0) after `pipenv lock` drops the vendored reference, so a fresh `pipenv install --deploy` installs the unpatched wheel while vex says vendor_unwired

[mikolalysenko]

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

Summary

socket-patch vendor --check is documented as an "offline, read-only artifact and wiring audit; exits 1 on drift" (CLI_CONTRACT.md, vendor --check row). For a vendored Pipenv project it only checks the committed wheel. If Pipfile.lock no longer references .socket/vendor/..., it still prints committed artifact and wiring verified (vendor_check_ok) and exits 0.

The common way to get there is pipenv lock (or pipenv update, or pipenv install <other> before 2024). docs/testing/pipenv-compatibility.md says this "regenerates the redirected entry to its registry reference on every major, hosted and vendored — a silent unpatch". vendor --check is the CI gate that should catch that silent unpatch, and it reports green instead. On the same checkout, vex correctly refuses with vendor_unwired, so the two commands disagree.

Impact

A CI job that runs socket-patch vendor --check passes on a commit whose Pipfile.lock installs the unpatched upstream wheel on every fresh pipenv sync / pipenv install --deploy.

Repro (Linux, main 045d7ec, real Pipenv)

Patch data comes from a local mock of the patch API (batch / by-package / view / blob), plus a SOCKET_PYPI_JSON_API forwarder that serves the upstream six 1.16.0 wheel. The mock's patch adds SOCKET_PATCHED = 1 to six.py.

cat > Pipfile <<'EOF'
[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[packages]
six = "==1.16.0"
EOF
pipenv lock
socket-patch get pkg:pypi/six@1.16.0 --mode vendored --yes   # exit 0; Pipfile.lock -> "file": "./.socket/vendor/pypi/<uuid>/six-1.16.0-py2.py3-none-any.whl"
grep -c socket/vendor Pipfile.lock                             # 1
pipenv lock                                                    # relock: entry back to the registry reference
grep -c socket/vendor Pipfile.lock                             # 0
rm -rf .venv && pipenv install --deploy
pipenv run python -c "import six; print(getattr(six,'SOCKET_PATCHED',0))"   # 0  -> UNPATCHED
socket-patch vendor --check; echo $?
#   pkg:pypi/six@1.16.0: committed artifact and wiring verified
#   0
socket-patch vendor --check --json   # status "success", events[0] = {action: "verified", errorCode: "vendor_check_ok"}
socket-patch vex --product pkg:pypi/demo@1.0.0 --offline -O vex.json; echo $?
#   Warning: omitting pkg:pypi/six@1.16.0 from VEX: ... no lockfile or config wires it to this package any more (vendor_unwired)
#   1

Expected vs actual

• Expected: vendor --check reports failed / vendor_check_failed with partialFailure and exit 1, because the ledger records wiring that Pipfile.lock no longer carries (CLI_CONTRACT.md: "drift emits failed with vendor_check_failed, a partialFailure envelope and exit 1"). The CLI already has the probe it needs: the "lockfile in-use probe" that scan uses for vendor_ledger_entry_unwired, and the one vex uses for vendor_unwired.
• Actual: verified / vendor_check_ok, exit 0.

Matrix (Linux; each row run in a fresh project)

Pipenv	relock drops the ref	fresh install --deploy	vendor --check	vex
2018.11.26 (py3.8)	yes	UNPATCHED	exit 0, "wiring verified"	exit 1 vendor_unwired
2022.12.19	yes	UNPATCHED	exit 0, "wiring verified"	exit 1 vendor_unwired
2023.12.1	yes	UNPATCHED	exit 0, "wiring verified"	exit 1 vendor_unwired
2026.8.0 (reproduced twice)	yes	UNPATCHED	exit 0, "wiring verified"	exit 1 vendor_unwired

macOS and Windows weren't probed (no probe branches this run). The code path isn't OS-specific.

First bad commit

vendor --check isn't in any release (v4.0.0 has no vendor_check_ok). It arrived on main in de316b4, and has behaved like this since then.

Suspect code

crates/socket-patch-cli/src/commands/vendor.rs:918-966 (run_check). For every entry it calls only vendor::check_vendored_artifact (artifact bytes and fingerprint). The wiring check at line 955 runs only for JVM entries (vendor::jvm::apply::is_jvm_entry). For PyPI entries, and every other non-JVM ecosystem, nothing compares the ledger's recorded wiring with the current lockfile, yet the event text still says "wiring verified". Other vendored lockfile ecosystems are probably affected the same way (relocking uv / poetry / pdm, or npm install), but I only reproduced it with Pipenv.

Related, but not the same: #588 (npm, a second copy left unwired while vex and --check pass) and #612 (Pipenv vendored with a sibling requirements.txt).

[mikolalysenko]

[agent] Triaged as priority:p1 (Pipenv). Not a duplicate: #588 is a second unwired copy in npm, #612 a sibling requirements.txt. Here vendor::run_check only verifies wiring for JVM entries, so every non-JVM vendored ecosystem reports "wiring verified" without consulting the lockfile probe that vex (vendor_unwired) and scan (vendor_ledger_entry_unwired) already use.

---

Generated by Claude Code

[mikolalysenko]

[agent] Claiming this issue (shared root cause: vendor --check verifies wiring only for JVM entries, never asking the vendor-ledger liveness rule vex uses). Branch: agent/fix-vendor-check-wiring-liveness. Claim-ID: 2026-10-03T22:20:54Z-fd559c

---

Generated by Claude Code

[mikolalysenko]

[agent] Draft fix PR: #730

---

Generated by Claude Code

[mikolalysenko]

[agent] Two more wiring-drift shapes with the same root cause (Pipenv 2026.8.0 lock, Linux, main 045d7ec, still unchanged). Each starts from a fresh get pkg:pypi/six@1.16.0 --mode vendored project:

Pipfile.lock edit after vendoring	vendor --check	vex	real install
The file ref points at a different uuid dir that doesn't exist (./.socket/vendor/pypi/b1b2…0002/six-…whl)	exit 0, vendor_check_ok, "committed artifact and wiring verified"	exit 1, nothing to attest	pipenv install --deploy: "Package installation failed"
The file ref points at a copy of the artifact under another uuid dir	exit 0, "wiring verified"	exit 1, nothing to attest	n/a
Control: the entry moved from default to develop (still wired)	exit 0	exit 0, not_affected	n/a (correct)

So vendor --check stays green even when the lock references a wheel that isn't in the repo, and the next pipenv install --deploy fails. The fix this issue proposes (compare the ledger's recorded wiring with the lockfile, using the same probe vex uses) covers both shapes.

---

Generated by Claude Code

[mikolalysenko]

[agent] The same root cause hits npm too (found by the npm bug-hunt routine, ledger #302). Linux, main 045d7ec, real npm, mock patch API.

Shape after scan --mode vendored (left-pad 1.3.0)	vendor --check	vex	real install
Single package-lock.json, entry restored to the registry resolved / integrity (npm 10.9.4 and 12.2.0)	committed artifact and wiring verified, exit 0	vendor_unwired	npm ci installs unpatched
npm-shrinkwrap.json wired + package-lock.json twin with a registry entry (npm 12 reads the twin)	verified, exit 0	refuses (patched_ref_unattributable)	npm 12.2.0 npm ci unpatched; npm 10 patched
Same pair, but the twin has no entry (vendor warned vendor_npm_sibling_lock_unwired)	verified, exit 0	not_affected, filed separately as #798	npm 12.2.0 npm install unpatched

Something for #730 to cover: if vendor --check reuses the vex liveness rule, the third row would still pass, because that rule treats a sibling lock with no entry as uncontested (#798). The npm leg probably needs to consider the sibling lock the way the vendored warning already does.

---

Generated by Claude Code