GeezerVison

LLM Description written by Claude Code:claude-opus-5-5

Fixes #529
Fixes #501

Summary

Agent-mode PyPI apply now patches every installed copy of a release, not just the first one the crawler lists. Before this, when the same name@version sat in two site-packages dirs, only one copy was patched. The copy Python actually imported could stay vulnerable while vex attested not_affected.

Root cause

The Python crawler can resolve one release in several candidate site-packages dirs, because it can't tell which one the project's tool uses or which one sys.path shadows:

• Agent mode patches only the WORKON_HOME venv when a Pipenv project also has an auto-detected ./.venv, so Pipenv 2018–2026.1 keep running the unpatched .venv and VEX attests not_affected (regression from #388) #529: a Pipenv project with a WORKON_HOME venv and an auto-detected ./.venv. Pipenv ≤ 2026.1 uses ./.venv and 2026.2+ uses WORKON_HOME. pipenv_project_site_packages deliberately returns both, WORKON_HOME first, so that "whichever one the installed Pipenv uses gets patched".
• With the same release in user site-packages and a system site-packages dir, agent mode patches the shadowed system copy, leaves the copy Python imports unpatched, and VEX attests it (worse since #452: now hits apt-installed packages) #501: global scope with the release in the user site and in a system dist-packages. site.getsitepackages() lists the system dirs first, while the interpreter imports the user site first.

find_all_packages_for_purls already carries every copy (merge_variant_copies), and rollback already restores every copy. The apply variant loop in crates/socket-patch-cli/src/commands/apply.rs, however, kept PyPI on a "one representative" contract and patched only pkg_paths.first(). The first copy was the WORKON_HOME one in #529 and the shadowed system one in #501.

Fix

• apply.rs variant loop: release-variant apply fans out to every copy for PyPI, as it already does for gem (npm fans out in its own branch). Each copy gets its own result and event, so the JSON summary shows that a second copy exists, and a failure on any copy fails the run. Paths that resolve to the same directory (a lib64 -> lib symlink, a symlinked venv) are collapsed by canonical path (distinct_install_dirs), so one install is never patched twice or reported already_patched. Maven keeps its one-representative contract.
• apply.rs blob prefetch (mismatch_blob_gaps, from review): the installed-variant gate now runs per copy for gem and PyPI, matching the apply loop, instead of against pkg_paths.first(). Two envs can hold different wheels of one release, and the variant installed only in the second copy now gets its mismatch fallback blobs prefetched. A variant is no longer probed on a copy it doesn't match, which also removes a spurious fetch.
• CLI_CONTRACT.md documents the PyPI multi-copy rule next to the gem one. CHANGELOG.md has an entry.

#501 also notes that the global site-packages order (user site last) is the reverse of import precedence. With every copy patched, the order no longer decides correctness, so I've left get_global_python_site_packages unchanged. Open PR #522 is reworking that function, and changing it here would conflict.

VEX: with every copy patched, vex's current first-copy check on main attests correctly after apply. Open PR #517 (vex verifies every copy) complements this one: with it, vex also catches a copy a later install reintroduces.

Test evidence

New suite crates/socket-patch-cli/tests/e2e_pypi_multi_copy.rs. It is not #[ignore]d, so it runs in the standard test job; it uses hand-built site-packages, a staged manifest and blobs, and --offline. Each test runs apply (every copy patched, one applied event per copy), a re-run of apply (exit 0), vex (one not_affected statement), and rollback (every copy restored).

Commands run locally (Linux, toolchain 1.93.1):

• The two e2e tests are red on main's apply.rs and green with the fix (19 passed). The prefetch unit test is red under first-copy gating and green with per-copy gating.
• cargo clippy --workspace --all-features -- -D warnings: clean. All 830 socket-patch-cli lib tests pass. These suites pass too: in_process_pypi_apply, in_process_pypi_multi_release, in_process_python_envs, covgap_commands_rollback, e2e_gem, cli_apply_silent.
• cargo test --workspace --all-features --no-fail-fast (on 99881ad): 209 test binaries green. 15 tests failed, and all of them are permission and write-failure tests that can't fail as intended in this sandbox, because it runs as root (uid 0), which ignores chmod 0555. None of them touch the apply path. CI runs as non-root.
• cargo fmt: the new and changed lines are rustfmt-clean. main itself isn't fmt-clean under 1.93.1 rustfmt, and CI has no fmt step, so I didn't reformat unrelated files.
• No wrapper (npm/, pypi/, gem/) changes are needed: this is Rust apply logic only.

Per-issue checklist

• Agent mode patches only the WORKON_HOME venv when a Pipenv project also has an auto-detected ./.venv, so Pipenv 2018–2026.1 keep running the unpatched .venv and VEX attests not_affected (regression from #388) #529 → pipenv_workon_home_and_dot_venv_copies_are_all_patched
• With the same release in user site-packages and a system site-packages dir, agent mode patches the shadowed system copy, leaves the copy Python imports unpatched, and VEX attests it (worse since #452: now hits apt-installed packages) #501 → global_system_and_user_site_copies_are_all_patched

🤖 Generated with Claude Code