[Mikola Lysenko (mikolalysenko)]

Stacked on #2010 (fix/npm-discovery-false-attestation).

Owner decision: by default, a dependency the user patched themselves is not patched in any mode, for any package manager. Only an explicit user override patches it.

What was already there (and what wasn't)

The CLI's consent gate (patch::user_patches::UserPatchIndex, #1646) already detects pnpm patchedDependencies, yarn berry patch: and patch-package for every npm-family project. Unless --allow-patch-conflicts is passed, it keeps scan (all modes), get, vendor, apply and the hosted/vendored writers from wiring those packages. Two consumers did not use that evidence:

1. vex discovery attested a pnpm, yarn, vlt (or npm/Bun) pin of a self-patched package. That covers a pin written before the patch was declared, and a pin that an --allow-patch-conflicts run wrote.
2. The in-memory hosted engine (Node addon / hosted-bundle) has no consent gate in front of it, so it rewired those packages.

One detector, three consumers

UserPatchIndex has a single walk over a ProjectView (disk, snapshot or memory). The CLI consent gate (discover()) runs it on disk and reads every ecosystem. Discovery and the hosted engine (npm_family_in()) run it on any view and read only the npm-family declarations.

Manager	What is detected	Where
pnpm	patchedDependencies keys (name, name@version, name@range)	package.json pnpm.patchedDependencies, pnpm-workspace.yaml patchedDependencies, each pnpm lock's top-level patchedDependencies map and (patch_hash=…) key suffixes (root, Rush, members, and a ref's own lock)
yarn berry	user patch: descriptors (Yarn's builtin<compat/…> patches are excluded), every layer peeled, aliases resolved	package.json dependency maps and resolutions; patch: locators that yarn.lock resolves, including one that wraps the hosted tarball (#962)
yarn classic	no patch protocol of its own; patch-package	patches/<name>+<version>.patch, or a --patch-dir that a package.json script names
vlt	no patch mechanism (see below); patch-package	same as yarn classic

The walk reads the project, its declared workspace members, and (on disk) the ancestor workspace settings up to the git repository root.

Repository bound, workspace runs only. In a workspace run the walk never reads outside the git repository root; in memory, the project is its own root. A workspace member or literal --patch-dir beyond that root is not read. Instead it protects every npm package with an "outside the git repository" diagnostic, in the gate too.

• In a global run (--global / -g / --global-prefix) the walk has no repository bound. It reads members and patch directories wherever they are, and they protect only the packages they patch.
• The scope is ReadScope { Workspace, Global }, chosen once from the CLI flags via GlobalArgs::read_scope() and passed through UserPatchIndex::discover_scoped. It has the same shape as Never read or rewrite project files outside the git repository root #2025's utils::repo_root::ReadScope (same variants, of_global) and is meant to be replaced by that type when the two branches meet.
• A global run still inspects no project: since fix(cli)!: require consent before patching user-patched packages #1646, a local checkout does not govern the global tree. So today the Global scope is only reachable through the core API.
• vex discovery and the in-memory engine only run on workspaces and keep the bound.

The npm-family scope leaves out npm's and Bun's own top-level patchedDependencies and npm's lock-entry patched records. No other package manager reads them, and #711, #367 and #2010 already judge them per resolution.

vlt evidence: vlt@1.6.2 (latest, published 2026-11-03) contains no patchedDependencies, no patch_hash and no patch command. Its vlt.json modifiers rewrite dependency specs, not package contents. A vlt project can therefore only patch through a postinstall tool such as patch-package, and that is what gets read.

Behavior per mode

• Discovery: a new vex::discover::user_patched pass marks every npm ref the index protects as UnattestedKind::UserPatchedDependency. Like Stop attesting npm-family pins pnpm or a user patch overrides #2010's npm and Bun marks, each mark is an UnwiredCopy with CopyTarget::Ref. It therefore lands only on a ref that survives the lock contests, and a ref already marked keeps its first reason. The ref stays, so rollback, remove and list still find it.
  • How "is it Socket's bytes?" is decided: while a user patch is declared for that name@version, the package manager or its postinstall applies it on top of whatever tarball the lock names. The install therefore never runs the Socket patch alone, and the ref is never attested, with or without consent.
• Bun and npm keys naming the pinned tarball (a patch made on top of the Socket pin, On Bun 1.4, a bun patch made on a hosted or vendored package is silently dropped by the next superseding re-run, takeover, rollback or revert (the #367 guard only matches name@version keys) #1019) are now marked too.
  • The npm and Bun extractors share one helper, Stop attesting npm-family pins pnpm or a user patch overrides #2010's npm::mark_user_patched (via user_patch_source). It now reads keys against no target, so any key for that name@version counts, and that case gets its own detail.
  • The Stop attesting npm-family pins pnpm or a user patch overrides #2010 test that asserted the old attested behavior now asserts the mark.
  • The hosted rewriter is unchanged. If the key names the URL this run would pin (an in-sync re-run), it keeps the pin and confirms it. If the key names an older URL, it refuses with redirect_bun_patched_dependency_skipped. Either way vex's plan omits the pin through the mark.
• Hosted: engine::withhold_user_patched removes such candidates from every rewriter and records each as a skipped row with reason user_patch_conflict (the consent gate's code). In memory it also adds a warning.
  • The in-memory engine always applies this.
  • The CLI disk flow applies it unless --allow-patch-conflicts is passed. There it mostly duplicates the consent gate, but it also reads the Rush lock, which the gate does not.
• Vendored: no change. Every vendored entry point already runs the consent gate:
  • vendor and the vendored writers refuse with user_patch_conflict.
  • scan --mode vendored and apply skip the package.

The override

The override is the existing invocation-only --allow-patch-conflicts. It has no env or policy binding, and no new surface is added.

• It already let pnpm, yarn and patch-package packages through the consent gate. It now also lifts the engine gate.
• With it, hosted and vendored mode wire the package, under the user's patch. vex still never attests the package while the patch is declared.
• npm and Bun native patches stay refused even with consent, as before (CLI_CONTRACT: "Backend safety refusals still apply").

CLI_CONTRACT.md (Existing project patches, Unattested references, the vex_npm_patched_dependency row) and docs/usage.md are updated.

Tests

Verified to fail before:

• vex::discover::user_patched::tests:
  • pnpm: workspace, package.json pnpm field, lock map, patch_hash key, range and bare keys.
  • yarn berry: package.json patch: wrapping the hosted URL; a yarn.lock patch locator.
  • patch-package: yarn classic, vlt hosted, vlt vendored and npm pins, including --patch-dir.
  • Workspace members, on disk and in memory, agree with the gate; a member beyond the repository root is not read.
  • A contested ref leaves no mark.
• bun_user_patched_dependency_pin_is_not_attested (key for the pin's own tarball).
• hosted_memory_engine::user_patched_npm_packages_are_never_pinned.
• in_process_redirect_pnpm::hosted_pins_a_pnpm_patched_dependency_only_with_explicit_consent:
  • default: skipped;
  • --allow-patch-conflicts: pinned;
  • discovery: the pin stays a ref and is marked unattested.
• patch::user_patches::tests::npm_family_view_index_agrees_with_the_consent_gate.

Runs:

• cargo test -p socket-patch-core --lib -- vex::discover:: patch::redirect:: vendor::pnpm vendor::yarn vendor::vlt vendor::npm vendor::bun hosted:: formats::pnpm formats::yarn patch::user_patches: 2523 passed. This includes the new the_repository_bound_holds_for_workspace_runs_only test: in a workspace run, an out-of-repo member or patch dir protects everything; in a global run, it is read and protects only the packages it patches. This includes committed_fixture_corpus_matches_golden, with no golden changes.
• Core integration targets: hosted_inventory 21, pnpm_hosted 6, vlt_locks 10, upstream_restore_golden 53.
• CLI: in_process_redirect_pnpm 42, in_process_redirect 152, hosted_memory_engine 50, hosted_memory_parity 43, user_patches 27, vex 48, e2e_vex_redirect 53, and lib vex_sources / user_patches / scan::hosted 63. All pass.
• cargo clippy --locked --workspace --all-features -- -D warnings and cargo fmt --all -- --check are clean.

Review findings (/code-review high)

All ten findings were confirmed. Each is fixed in 93709da82.

1. pnpm member manifest selected presence-only: confirmed and fixed. Under named roots (projectRoots: [""]), a pnpm member with its own lock is not a root of its own. Its package.json was therefore selected presence-only, read as unknown metadata, and every npm candidate was withheld. With detected roots the member is a root and gets content, which is why the existing parity test missed it.
   • The rule now: selection asks for content for every file the walk can read.
   • A file the walk reads that the host supplied without content (oversize, LFS) still protects every npm package. A missing file must never silently disable protection.
   • The one safe not-applicable case is a --patch-dir that has no listing in memory. Selection supplies every *.patch, so such a directory holds none.
2. --patch-dir contents never selected: confirmed and fixed. Selection now requests every *.patch file by name (presence-only is enough, since only the file names are read).
3. patch-package files and npm/yarn member manifests never fetched: confirmed and fixed. This was failing before: an npm workspace member's patches/left-pad+1.3.0.patch → memory pinned left-pad. Selection now fetches every package.json, pnpm-workspace.yaml, pnpm-lock.yaml and yarn.lock, and every *.patch by name, outside node_modules, .git, .socket, target and .venv. That list is a constant (WALK_SKIP) shared with the walk.
   • Test: hosted_memory_parity::user_patches_are_selected_and_agree_with_the_disk_flow drives select_paths → memory project → engine for 8 cases (pnpm member manifest, npm member patches/, npm member patch: descriptor, root patches/, root --patch-dir, and three no-patch controls). Each case runs with both detected and named roots and is compared with the disk flow.
4. Out-of-repo go.work member recorded under npm: confirmed and fixed. Every pending directory now carries the ecosystem whose declaration named it. An out-of-repo go.work use member protects Go modules (fail closed for Go), not npm packages. Test: an_out_of_repo_go_member_protects_go_not_npm.
5. Ancestor markers checked on the lexical parent, read via ..: confirmed and fixed. Ancestors now come from utils::repo_root::search_dirs and are checked and read at the same canonical absolute path. Test: a_symlinked_root_reads_its_real_ancestors.
6. Every absolute path counted as outside the repo: confirmed and fixed. An absolute path is now normalized lexically and accepted when it lies under the repository root. Test: an_absolute_patch_dir_inside_the_repository_is_read.
7. The disk hosted flow re-walked the project: confirmed and fixed. The CLI now withholds by the Rush lock alone (UserPatchIndex::from_locks + engine::withhold_user_patched_by). The consent gate has already walked the project.
8. Root locks parsed twice: confirmed and fixed. npm_family_in skips a passed pnpm-lock.yaml or yarn.lock whose directory the walk already read.
9. vlt preflight downloaded before the withhold: confirmed and fixed. The CLI withhold now runs before vlt::artifact_preflight. The in-memory preflight is offline and downloads nothing.
10. Hand-rolled git-root search and lexical_join: confirmed and fixed. They are replaced by find_git_repo / search_dirs (which honor GIT_CEILING_DIRECTORIES and the home rule) and normalize_lexically_keeping_escapes. The minimal ReadScope stays, to be replaced by Never read or rewrite project files outside the git repository root #2025's.

Two caveats on the tests:

• Findings 1–3 were confirmed by running the new test against the previous commit. Findings 4–6 are confirmed by reading the previous code; each new test asserts behavior that code could not produce.
• Selecting every nested package.json and lock adds fetches for large monorepos. That is the cost of reading members' declarations at all. The host's max_files limit still applies and fails the run closed.

Not done

• No core-level vendored gate for pnpm or yarn. The CLI consent gate covers every vendored entry point. A core gate would need the override plumbed into the vendor backends.
• Hosted still pins a package whose key names the pin's own tarball (see above). Only vex omits it.
• The in-memory engine sees a member root's files only. It cannot read the workspace settings of an enclosing root that the host splits off.

Brought current with #2010, plus round-2 review findings (cloud routine)

Merged the updated #2010 in. It merged cleanly, and the targeted core tests pass (764).

Review findings, round 2 (/code-review high on 93709da)

1. The disk flow no longer withheld packages a root shrinkwrap.yaml records as patched: fixed. The consent gate's walk never reads that file, while the in-memory engine does. The disk gate now reads it as well as the Rush lock. Since pnpm ≤2 had no patches, the practical impact is small, but the two flows agree again.
2. The ancestor walk went past home: fixed. repo_root::search_dirs stops only exactly at $HOME. A project outside home with no checkout therefore read /package.json and similar files. The old stop at home or any directory above it is restored, per owner decision 6: without a checkout, upward lookups behave as before.
3. The snapshot fingerprint lost the root's .git: fixed. It's covered again, since it decides the read bound.

None of the three has a new test yet. Finding 2 needs a HOME override, which isn't safe in parallel lib tests. Findings 1 and 3 need a disk-flow CLI fixture. The existing user_patches CLI suite (27) and the core suites pass.

Declined or deferred:

• The seen dedup by path drops the npm tag of a dir also queued as a go.work member. This is a corner case. Defer to the Never read or rewrite project files outside the git repository root #2025 ReadScope swap, which rewrites this bound.
• Memory-mode selection misses WALK_SKIP-segment and root-level patch dirs (--patch-dir target/patches, --patch-dir .). This is real but narrow. The disk flow (the default) withholds correctly. Follow-up.
• The symlink-spelled --patch-dir vs the canonical repo root. Never read or rewrite project files outside the git repository root #2025's ReadBoundary replaces this lexical check.
• The CLI hard-codes which locks the walk misses, and memory selects every lock. Altitude and efficiency only.

Tests (cloud run): cargo test -p socket-patch-core --lib -- user_patch vex::discover:: hosted:: utils::repo_root gives 687 passed. CLI --test user_patches gives 27 passed. clippy and fmt are clean.

---

Note

Medium Risk
Changes hosted-scan candidate filtering, vex attestation, and user-patch discovery across npm-family locks and monorepo boundaries; incorrect reads could skip or over-block pins, but behavior is intentionally fail-closed.

Overview
Self-patched npm-family dependencies (pnpm patchedDependencies, Yarn patch: descriptors, patch-package) now follow the same rules as npm/Bun patchedDependencies: by default hosted scan skips them as user_patch_conflict, vendored/get still refuse without consent, and vex never attests them while the user patch is declared—even after an --allow-patch-conflicts run wires the pin.

UserPatchIndex is refactored into one shared walk (discover_scoped / npm_family_in) with ReadScope::Workspace vs Global and a git-repository read bound (out-of-repo workspace members or patch dirs fail closed instead of being read). The in-memory hosted engine always applies withhold_user_patched (no consent knob); disk scan supplements the consent gate with Rush/subspace and root shrinkwrap.yaml locks. Path selection now fetches nested manifests, locks, and *.patch files the walk needs so memory and disk stay aligned.

Documentation and user-facing notes broaden vex_npm_patched_dependency to the full npm family; Bun/npm patches layered on the Socket tarball are omitted from attestation with updated discovery detail.

^{Reviewed by Cursor Bugbot for commit 092feb1. Configure here.}

/code-review high findings not fixed in this PR

Fixed at e0cc402: out-of-root ancestor/member reads refused by the view bound (two failing unit tests), Global scope not reaching out-of-repo members, discovery dropping unreadable-lock errors, the engine treating an in-memory symlinked lock as unknown, and doubled periods in CLI_CONTRACT.md. Left for follow-ups, with reasons:

• Rush / root shrinkwrap.yaml evidence lives only in the hosted disk-scan supplement, not the shared UserPatchIndex::discover gate used by vendor/get/apply. That gap predates this PR (the gate never read Rush locks); moving it into the walk's Gate scope is a separate change. (The supplement is now re-read under the apply lock, 3ab7c1993.)
• user_patch_need in hosted memory selection streams every nested package.json/yarn.lock/pnpm file regardless of root ecosystem, which can push large monorepos toward the selection limits. Owner decision (2026-11-09): keep the over-fetch and fail closed (Option A).
• Root locks are read twice (explicit list plus the walk) and the disk supplement reads Rush locks even with no npm candidate: performance only, no correctness impact.
• npm discovery's warning detail can name the pin's own patchedDependencies key when Bun has keys for two tarballs of one version: wording of a warning only.

Review round 3 (3ab7c1993)

These come from Tanmay's thread, Wenxin's review, the owner decisions and /code-review high on the delta. The details are in the follow-up comment.

• patch-package: evidence protects every version of the package, since patch-package applies a patch to whatever version is installed. Patch directories are walked recursively, so @scope/name+1.0.0.patch counts. The walk follows linked subdirectories and skips node_modules/.git/etc.
• In-memory linked package.json: fails closed. The exception is the root manifest beside a yarn berry lock, which the engine refuses as a link.
• Rush / shrinkwrap.yaml supplement: re-read under the apply lock. Its reader moved into core (engine::withhold_user_patched_by_supplement) and reads a lock that links out of the repo through the link.
• CLI_CONTRACT: a symlinked project file is read through its link (owner decision). The *.patch selection wording and the every-version rule are updated.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: merged base fix/npm-discovery-false-attestation (which carries main c2be854) into this branch to fix the merge conflict. New head 85e98175. The only conflict was the vex_npm_patched_dependency row in CLI_CONTRACT.md: kept this branch's broader wording (pnpm, Yarn and patch-package patches) and added the base's new vex_sbt_resolution_unverified / vex_sbt_vendored_tree_missing rows. cargo check --all-targets (core + cli) and cargo test -p socket-patch-core --lib vex (793 passed) are clean locally. Draft stays stacked on #2010.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

Final review (head 891cf58 → pushed c173014)

I reviewed the full diff and found three should-fix problems. All three are fixed in c173014:

1. Fail-open on a symlinked file outside the repository (user_patches.rs, read_view). The view refuses a file whose real path leaves the repository, and that refusal carries the NotFound kind. read_view therefore treated a symlinked pnpm-workspace.yaml, package.json or lock that points outside the repo as absent, so its patchedDependencies were missed. main read through the link. The check now looks for is_refused_read first and records unknown metadata, which protects every npm package. New test: a_symlinked_file_outside_the_repository_fails_closed. It fails without the fix.
2. The in-memory selector fetched user-patch files even when npm was not selected (hosted/memory/select.rs). It fetched every nested package.json, pnpm/yarn lock and *.patch with ecosystems: ["pypi"], which counts against max_files. A repo with debian/patches or many fixture manifests could fail a run that used to pass. These files are now selected only when npm is selected. New test: user_patch_files_are_not_selected_without_npm.
3. Disk supplement warnings were dropped (scan/hosted.rs). The return value of withhold_user_patched_by was discarded with let _. A package withheld only by Rush or shrinkwrap.yaml evidence got a skip row but no user_patch_conflict warning, which goes against CLI_CONTRACT.md. Those warnings are now merged into the run's warnings.

Checks I ran: cargo clippy --locked --workspace --all-features -D warnings is clean. socket-patch-core lib: 7282 passed. The 4 failures are permission tests that also fail without this change when run as root. hosted_memory_engine, hosted_memory_parity and in_process_redirect_pnpm all pass.

Not fixed (follow-ups, not blocking):

• No end-to-end disk test covers the Rush/shrinkwrap supplement. Deleting the if !common.allow_patch_conflicts block, or inverting it, would not fail any test.
• Explicit get --mode hosted silently skips a package patched only in a Rush lock, where it should refuse with user_patch_conflict. The re-check under the lock uses the consent gate's index, which does not read Rush locks.
• patch-package --cwd/--prefix before patch-package in a script is not treated like cd, and patch directories are not listed recursively (the recursive listing was already missing on main).

I removed Ready for review. The burn-down re-labels it once CI is green, and then I'll post the review brief.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

Burn-down: pushed 092feb1 to fix the 3 real coverage (1)/coverage (2) failures on c173014 (hosted_refuses_symlinked_package_lock_before_ledger_write, refused_commit_keeps_an_artifact_the_ledger_already_names, in_sync_vendor_over_a_symlinked_lock_neither_warns_nor_refuses).

Cause: c173014 recorded unknown metadata for a file the view refuses (a symlink escaping the repo), so a symlinked package-lock.json with no patched entry withheld every npm package with user_patch_conflict (exit 0) ahead of the redirect_symlinked_file_unsupported refusal.

Fix: read_view now reads such a file through the link straight from disk (as main did, and as the walk already does for admitted ancestor files). Declared patches still protect their packages, so this does not fail open. A file that can't be read through the link either still fails closed. The unit test is now a_symlinked_file_outside_the_repository_is_read_through_the_link, and an_unreadable_symlinked_file_outside_the_repository_fails_closed is new.

Local: user_patches unit tests 32/32, --test scan 224/224, --test vendor 133/133.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 092feb1. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Ready for review at 092feb1d74a660552b7bbe23517fd4470a4ae496.

• CI: 31/31 checks pass (19 skipped). No main-wide failures.
• Bugbot: reviewed 092feb1 with no new issues. All review threads are resolved.
• What changed since c173014: 092feb1 fixes the 3 symlinked-lock contract tests that failed in coverage (1) and coverage (2). A project file that symlinks outside the repo is now read through the link, not treated as unknown metadata, so a symlinked package-lock.json gets the expected redirect_symlinked_file_unsupported refusal again. Declared patches in such a file still protect their packages.
• Worth a look: the read-through in read_view (user_patches.rs). It follows main's pre-PR behavior for symlinked files, not the final reviewer's "protect every npm package" rule. A file that can't be read through the link still fails closed.
• Slack: not announced, because Slack posting is not available in this run. The next run should retry.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review at 092feb1: needs a human decision before this can go to the merge queue.

Detection fails closed in every path I traced, and cargo test -p socket-patch-core --lib user_patch passes (49/49). Two points need an owner's call, not a mechanical fix:

1. Hosted in-memory path selection may push large repos over max_files. With the default SelectOptions.ecosystems = None, select.rs:474-477 turns user_patches on for every repo, including repos with no npm root. user_patch_need then selects:

   • every nested package.json, pnpm-lock.yaml and yarn.lock with content, member or not;
   • every *.patch file by name, before the WALK_SKIP check, so files under node_modules, .venv and target too.

   Each selected file counts toward the hard max_files limit (2000; limits.rs:212-219). Going over it fails the whole session.

   • Scenario: a monorepo with a few hundred examples/*/package.json + yarn.lock, or a Python/Go repo with debian/patches, that selected ~1.8k files before. It now errors.
   • Option A: keep the over-fetch, since failing closed is worth it.
   • Option B: select only when an admitted root is an npm root, keep .patch files out of WALK_SKIP dirs unless a --patch-dir could name them, and fetch non-member manifests only when a workspace glob could reach them.

   Which do you want?

2. 092feb1 reads through symlinks that leave the repository. user_patches.rs:424-430 now reads a symlinked project file whose target is outside the repo straight from disk, as main did. That fixed the symlinked-lock contract tests. But CLI_CONTRACT.md:208 still says "Nothing outside the git repository root … is read". list_patch_directory (user_patches.rs:486) already lists a symlinked --patch-dir outside the repo without a bound.

   • Security impact is low: only declaration names reach output, and the writers refuse symlinked targets.
   • Do you want a carve-out in the contract for symlinks inside the repo, or should these fail closed, with the symlinked-lock tests expecting user_patch_conflict instead?

Smaller follow-ups, not blocking:

• CLI_CONTRACT.md:226 says *.patch files are selected outside node_modules/.venv/…, but the code (and the .venv/patches test) selects them everywhere.
• UserPatchIndex::unreadable_lock (user_patches.rs:131-139) treats a bound-refused read (NotFound kind) as a missing lock. The Rush writer's symlink refusal covers it today. Checking is_refused_read first would be cleaner.
• list_patch_directory uses view.list_dir, not list_dir_strict, so non-UTF-8 names and mid-listing errors are skipped. Main recorded unknown there.
• The Rush/shrinkwrap supplement isn't re-checked under the write lock (scan/hosted.rs:961-977). The race is narrow.

Labelled agent:needs-human. Once the two questions are answered, the burn-down or I can make the change.

---

Generated by Claude Code

[Wenxin Jiang (Wenxin-Jiang)]

[agent] Review findings (Claude Opus + codex, independent passes):

1. patch-package evidence is exact-version only (crates/socket-patch-core/src/patch/user_patches.rs:954, Opus; same as the open thread at :950). patch-package applies patches/<name>+<ver>.patch to whatever version is installed (it only warns on mismatch). Input: patches/left-pad+1.3.0.patch, lock bumped to left-pad@1.3.1, Socket patch for 1.3.1 → conflicts() is empty, the in-memory hosted engine pins the tarball and the new vex::discover::user_patched pass leaves the ref attestable; at install the user's diff stacks on Socket bytes or fails. Suggested fix: record patch-package evidence with version: None.
2. Symlinked manifest hides --patch-dir (user_patches.rs:447, codex). A package.json symlinked to a manifest running patch-package --patch-dir fixes plus fixes/left-pad+1.3.0.patch still permits pinning left-pad@1.3.0 without consent.
3. Rush evidence read outside the apply lock (crates/socket-patch-cli/src/commands/scan/hosted.rs:888, codex). Rush patchedDependencies is read before acquiring the lock and not rechecked, so a patch added while scan --mode hosted --lock-timeout 30 waits gets pinned without consent.

Minor: list_patch_directory ignores scoped patches/@scope/name+1.0.0.patch subdirectories; the new test in hosted/engine.rs:4827 sits under the #713 HEAL-ON-RERUN doc comment.

[Wenxin Jiang (Wenxin-Jiang)]

[agent] Approving per maintainer decision; see the findings in the review above.

[Mikola Lysenko (mikolalysenko)]

Review follow-up: pushed 3ab7c1993. It addresses the review threads, Wenxin's review and the two owner decisions from the 11:59Z comment.

Owner decisions

1. max_files over-fetch: Option A. Keep the over-fetch and fail closed. The CLI_CONTRACT wording now matches the code: manifests and locks are selected outside the skip list, and every *.patch file is selected wherever it is.
2. Symlinks: contract carve-out. A project file inside the repository that is a symbolic link is read through its link. If it can't be read that way, it protects every npm package.

Wenxin's review

1. patch-package exact version: fixed. Evidence now protects every version, and patch directories are walked recursively (@scope/name+1.0.0.patch). See the resolved thread.
2. Symlinked manifest hides --patch-dir: fixed. On disk the link was already read through; a test now pins that. In memory, a linked package.json has no content and the engine doesn't refuse it, so it now fails closed. The one exception is a root manifest beside a yarn berry lock: the engine refuses that one as a rewrite target, so its refusal stands. Test: an_in_memory_linked_manifest_fails_closed.
3. Rush evidence read outside the apply lock: fixed. The Rush / root shrinkwrap.yaml supplement is re-read under the apply lock, so a patch recorded while the run waited still withholds its package. The supplement's lock reads moved into core (engine::withhold_user_patched_by_supplement) and share one reader with the in-memory engine. That reader reads a lock that links out of the repository through the link. New disk-flow test: scan_redirect_withholds_a_package_a_rush_lock_records_as_patched. I checked that it fails when the supplement is disabled.
4. Minor:
   • Scoped subdirectories: fixed, as in item 1.
   • The Hosted scan on a Rush repo with pnpm 11/12 reports success, but rush install then fails with ERR_PNPM_TARBALL_URL_MISMATCH, or (pnpm 11.0.0) silently installs the upstream package #713 doc comment is back on its own test.

Smaller follow-ups from the 11:59Z comment

• unreadable_lock now checks is_refused_read first.
• A --patch-dir named by a script is listed with list_dir_strict. The default patches/ keeps the lenient listing.

/code-review high on the delta: 8 findings. Six are fixed in the same commit:

• a linked berry manifest;
• two lock read-through cases;
• linked patch subdirectories;
• --patch-dir . listing node_modules;
• strict listing of the default patches/;
• the duplicated supplement reader.

Two were declined:

• The late Rush re-read runs after the rollout may_write decision. The effect is that a run whose only writable candidate gets withheld under the lock still holds the lock while writing nothing. Rollout admission still reads the remaining candidates, so nothing is mis-admitted.
• Recursion into a huge patch tree hits the 10k-entry cap and fails closed. That is intended.

Tests:

• core lib (user_patches, vex::discover, hosted, patch::redirect, repo_root): 1610 passed.
• CLI user_patches 7, hosted_memory_engine 50, hosted_memory_parity 43, in_process_redirect_pnpm 42, in_process_redirect 136, vex 28, e2e_vex_lockfile 322, scan 224, vendor 133, lib 867.
• clippy -D warnings and fmt are clean.

---

Generated by Claude Code