Patch every PyPI copy in agent apply

The Python crawler can find one release in several site-packages
dirs, but apply patched only the first. The copy the interpreter
actually imports could stay vulnerable while vex attested it.
Apply now patches every distinct copy, like gem and npm; paths
that alias one directory through a symlink count once.

Fixes #529, #501

Assisted-by: Claude Code:claude-opus-5-5

Author: claude

CHANGELOG.md

@@ -102,6 +102,11 @@ limits, and required install commands.
 
 ### Fixed
 
+- Agent-mode PyPI `apply` patches every installed copy of a release, not just
+  the first one found. A Pipenv project with both a WORKON_HOME venv and a
+  `./.venv`, or a global install with the same release in the user site and a
+  system dir, no longer keeps the copy Python imports unpatched while `vex`
+  attests it (#529, #501).
 - Gem hosted and vendored modes wire only the manifest Bundler loads. A `gems.rb`
   twin or a `BUNDLE_GEMFILE` setting (environment or `.bundle/config`) no longer
   leads to an edit of an ignored `Gemfile` that reports success and attests an

crates/socket-patch-cli/CLI_CONTRACT.md

@@ -502,7 +502,11 @@ the model is **not uniform** today:
   **coexisting physical copies of one `gem@version`** (bundler-2's scoped store beside bundler-1's
   flat store), `apply`/`rollback` patch/restore **every copy** — one summary event per copy,
   mirroring npm's multi-copy fan-out — while single-representative consumers (`get`, `vendor`,
-  `vex`) use the highest-precedence copy.
+  `vex`) use the highest-precedence copy. PyPI follows the same rule: when the crawler resolves
+  one release in several site-packages dirs (a Pipenv WORKON_HOME venv beside an auto-detected
+  `./.venv`, or the user site beside a system dir in global scope), agent `apply` patches **every**
+  copy, one summary event per copy, because any of them may be the one the interpreter imports.
+  Paths that resolve to the same directory (a symlinked site-packages) count as one copy.
 
   *Copy classes (additive to the multi-copy vocabulary):* a copy under a **bundle-path store**
   (config/env/default root) is PRIMARY — a variant mismatch or write failure there fails the run,

crates/socket-patch-cli/src/commands/apply.rs

@@ -627,6 +627,25 @@ pub(crate) fn variant_matches_installed(first_file_status: Option<&VerifyStatus>
     }
 }
 
+/// `paths` in order with every path that resolves to an already-listed
+/// directory dropped: two discovered site-packages paths can name ONE
+/// directory (a `lib64 -> lib` symlink, a symlinked venv), and patching it
+/// twice would report the second pass `already_patched`. A path that can't
+/// be canonicalized is kept as-is.
+async fn distinct_install_dirs(paths: &[PathBuf]) -> Vec<PathBuf> {
+    let mut seen: HashSet<PathBuf> = HashSet::new();
+    let mut out = Vec::with_capacity(paths.len());
+    for path in paths {
+        let key = tokio::fs::canonicalize(path)
+            .await
+            .unwrap_or_else(|_| path.clone());
+        if seen.insert(key) {
+            out.push(path.clone());
+        }
+    }
+    out
+}
+
 /// The file whose verify status decides whether a release variant
 /// describes the installed distribution (fed to
 /// [`variant_matches_installed`]).
@@ -1881,22 +1900,31 @@ async fn apply_patches_inner(
                 continue;
             }
 
-            // Patch EVERY coexisting gem store copy (the npm multi-copy
-            // precedent): leaving the other store pristine is a silent
-            // false "applied" for whichever bundler loads it, and the
-            // per-copy results below make the JSON summary count each
-            // patched copy — the signal a second copy exists. PyPI/Maven
-            // keep the one-representative contract: their crawlers resolve
-            // one install dir per version, and a second path can only
-            // alias the same logical install (re-patching it would produce
-            // the spurious `already_patched` double-patch the nuget
-            // first-wins restoration fixed).
-            let copy_paths: &[PathBuf] =
-                if matches!(Ecosystem::from_purl(purl), Some(Ecosystem::Gem)) {
-                    pkg_paths.as_slice()
-                } else {
-                    std::slice::from_ref(pkg_path)
-                };
+            // Patch EVERY coexisting gem store copy and every PyPI
+            // site-packages copy (the npm multi-copy precedent): leaving
+            // the other copy pristine is a silent false "applied" for
+            // whichever bundler / interpreter loads it, and the per-copy
+            // results below make the JSON summary count each patched copy
+            // — the signal a second copy exists. The Python crawler
+            // resolves one release in several candidate envs when it
+            // can't tell which one the project's tool runs (a Pipenv
+            // WORKON_HOME venv beside `./.venv`, #529) or which one
+            // `sys.path` shadows (the user site beside a system dir in
+            // global scope, #501), and rollback already restores every
+            // copy. A PyPI path that only ALIASES another (a symlinked
+            // site-packages) is collapsed by canonical path, so one
+            // install is never patched twice. Maven keeps the
+            // one-representative contract: its crawler resolves one
+            // install dir per version.
+            let pypi_copies: Vec<PathBuf>;
+            let copy_paths: &[PathBuf] = match Ecosystem::from_purl(purl) {
+                Some(Ecosystem::Gem) => pkg_paths.as_slice(),
+                Some(Ecosystem::Pypi) => {
+                    pypi_copies = distinct_install_dirs(pkg_paths).await;
+                    pypi_copies.as_slice()
+                }
+                _ => std::slice::from_ref(pkg_path),
+            };
 
             // Copy CLASS decides FAILURE semantics (never write scope —
             // patching a shared home's vulnerable copy is fine when it