GeezerVison

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

Fixes #332
Fixes #361

Summary

In agent mode, apply and rollback no longer write through a package directory that links into a store shared by other projects on the machine. Two package managers install that way: PDM's symlink install cache and pnpm's global virtual store. A package that resolves into one of those stores is now refused, and the error names the store and how to get a private copy.

Root cause

Agent-mode apply and rollback commit each file with a stage + rename(2) in the file's parent directory. That isolates a hardlinked or symlinked file, but not a package directory that is itself a symlink into a store shared by every project on the machine:

• PDM 2.0–2.12 with install.cache = true and cache_method = symlink: site-packages/<pkg> points to <cache>/packages/<wheel-stem>/lib/<pkg> (Agent mode writes the patch into PDM's shared install cache when PDM 2.0–2.12 installs packages as directory symlinks (install.cache + symlink) #332, in both project and -g mode).
• pnpm global virtual store (enableGlobalVirtualStore): node_modules/<dep> points to <store>/v10|v11/links/…/node_modules/<dep> (Agent-mode apply and rollback on a pnpm project with enableGlobalVirtualStore patch (and unpatch) every other project that shares the store #361).

The rename lands inside the shared directory, so another project gets patched, and a rollback in one project unpatches the others.

Fix

• A new patch::shared_store module classifies a package path by its real (canonical) location. Detection is positive and marker-based:

  • PDM cache entry: packages/<stem>/ with a referrers file, and the path under its lib/. Checked against the PDM 2.0.3 and 2.12.4 sources (CachedPackage, install_wheel_with_cache).
  • pnpm global virtual store: v<N>/links with the store's files/ beside it. Checked against a real pnpm 10.28 GVS install.

  Ordinary pnpm node_modules/.pnpm links, workspace links and relocated per-project virtual stores carry neither marker, so they are patched as before.

• The check covers every directory the patch writes into (shared_store_of_patch_dirs): the package root plus the parent of each file key. That matters for PyPI, where the root is site-packages and the PDM link is site-packages/<pkg> below it (Bugbot finding on b3a739f, fixed in 0f84373).

• apply_package_patch_at refuses such a package in every state, dry run and already-patched included, so this project never records the shared copy as its own patch. The pnpm/vlt peer copies run through the same engine and get the same check.

• rollback_package_patch_at refuses whenever it would write, dry run included. A shared copy that is already original needs no write and passes.

• The refusal comes out as failed / apply_failed with the message: "Refusing to patch : it is in pnpm's global virtual store (enableGlobalVirtualStore), which is shared by other projects on this machine … set enableGlobalVirtualStore to false and reinstall, or use scan --mode hosted / --mode vendored". The PDM message suggests pdm config install.cache_method hardlink instead.

• CHANGELOG (Unreleased › Fixed) and docs/ecosystems.md are updated.

Test evidence

Red run on this branch before the guard: 3 failed; 5 passed. With the first, root-only guard, the PyPI-shaped legs still fail (pkg:pypi/[email protected] dry_run=true: must refuse). With 0f84373, everything passes.

Real pnpm 10.28 end-to-end (enableGlobalVirtualStore: true, projects a/b/c sharing one store, hand-staged .socket/ for pkg:npm/[email protected]):

• apply in b: failed / apply_failed ("Refusing to patch …/store/v10/links/@/is-odd/3.0.1/…/node_modules/is-odd …"), exit 1. c's index.js is untouched.
• With the shared copy already patched, rollback in a is refused (exit 1) and the shared bytes stay patched, so b and c aren't silently unpatched.
• Control: a plain pnpm project (node_modules/is-odd -> .pnpm/…) still applies and rolls back normally.

Checks

• CI on 0f84373: all 355 check runs finished (349 success, 6 skipped). Cursor Bugbot: "no new issues". Its one finding on b3a739f is fixed and the thread is resolved.
• Local cargo clippy --workspace --all-features -- -D warnings: clean.
• Local cargo test --workspace --all-features --no-fail-fast: everything passes except 13 tests in 4 targets. All 13 are permission tests that make a directory read-only and expect a write to fail, and that can't happen when the sandbox runs as root (e.g. copy_tree::relax_loop_must_not_traverse_symlinked_root, the *_state_write_failure_* / *unremovable* tests). All of them are green in CI.
• cargo fmt --all -- --check: main itself isn't rustfmt-clean under the pinned 1.93.1 rustfmt (it reformats 120+ unrelated files), so I ran rustfmt only on the files this PR changes, and they are clean.

Follow-ups

• PDM's pth cache method already fails closed (File not found), and symlink_individual / hardlink are isolated by the file-level rename. Neither needs a change.

🤖 Generated with Claude Code

Generated by Claude Code