[Mikola Lysenko (mikolalysenko)]

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

Fixes #1630

Root cause

berry_copy_ref (crates/socket-patch-core/src/formats/yarn/copy.rs) read a yarn berry lock entry as a "copy under another dependency name" only when its reference was file:, portal:, link: or started with http. An exec: generator entry, and a git entry whose remote isn't http(s) (git+ssh://, ssh://, git://, git@host:), returned None, so:

• lockfile discovery (vex/discover/yarn.rs berry_block) skipped it silently, and the wired ref was attested not_affected;
• the hosted engine's redirect_copy_unpatched warning, which is fed by discovery, never named it;
• the vendored backend's other_name_copies never named it (vendor_copy_unpatched).

Fix

exec: and non-http git references are now read as copies whose package can't be read, like a non-registry url: possibly any package at the lock's version. That contests a wiring of the same version (patched_ref_unattributable), and both scans name the copy. exec: paths share the file:/portal:/link: selector and locator= parsing.

Tests (per issue)

• Yarn berry ignores an exec: copy of the patched package under another dependency name, so hosted and vendored scans succeed and VEX attests not_affected while that copy installs unpatched #1630, parsing: formats::yarn::copy::tests::issue_1630_exec_and_git_refs_are_unread_copies
• Yarn berry ignores an exec: copy of the patched package under another dependency name, so hosted and vendored scans succeed and VEX attests not_affected while that copy installs unpatched #1630, VEX discovery: vex::discover::yarn::tests::issue_1630_exec_and_git_copies_contest_a_vendored_ref (control: the same copy at 2.0.0 doesn't contest)
• Yarn berry ignores an exec: copy of the patched package under another dependency name, so hosted and vendored scans succeed and VEX attests not_affected while that copy installs unpatched #1630, vendored scan: vendor::yarn_berry_lock::tests::issue_939_other_name_copies_are_named gained exec: and git+ssh: cases
• Yarn berry ignores an exec: copy of the patched package under another dependency name, so hosted and vendored scans succeed and VEX attests not_affected while that copy installs unpatched #1630, hosted scan: hosted_memory_engine::issue_1630_berry_exec_and_git_copies_are_named (control at 2.0.0). It fails on main's core (redirect_copy_unpatched missing) and passes with the fix.

Commands run locally on d96f49a: cargo fmt --all -- --check ✅, cargo clippy --workspace --all-features -- -D warnings ✅, cargo test -p socket-patch-core --all-features --lib 6567 passed / 4 failed, cargo test -p socket-patch-cli --all-features --lib --test hosted_memory_engine ✅, all yarn CLI test binaries (non-ignored) ✅. The 4 core failures are chmod-based permission tests (copy_tree relax loop, vlt_heal unremovable lock, poetry/requirements wire-failure rollback) that can't fail a write when run as root, as this sandbox does. They don't touch yarn. A full cargo test --workspace ran out of the sandbox's disk, so CI covers the docker/e2e suites.

Code review (/code-review high) and what was not changed

• Fixed: duplicated exec: parsing, now shared with the file:/portal:/link: cascade; stale doc comments listing the copy kinds.
• Not changed, follow-up: yarn classic git dependencies under another name. classic_block records them as pkg:npm/<dep-name>@<version> rather than as an unidentified copy, and other_name_copies filters classic git out. Yarn berry ignores an exec: copy of the patched package under another dependency name, so hosted and vendored scans succeed and VEX attests not_affected while that copy installs unpatched #1630 is berry-only, so this PR doesn't widen to classic. The docs now say the git case is berry-only.
• Not changed: making berry_copy_ref fail-closed for unknown protocols (plugin resolvers). That is a policy change beyond Yarn berry ignores an exec: copy of the patched package under another dependency name, so hosted and vendored scans succeed and VEX attests not_affected while that copy installs unpatched #1630.
• Not changed: a git/exec: entry under the patched package's own name now contests in VEX but isn't named by vendored other_name_copies (same-name filter). That already happens for same-name file:/url entries on main, and VEX failing closed is the safe side.

https://claude.ai/code/session_01BgnkbqbEMV3JkJWHCPzG6E

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

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 d96f49a. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Ready for review at d96f49a.

• CI: 86/86 settled on the head, 36 success, 50 skipped, no failures.
• Bugbot: reviewed d96f49a, no findings. No open review threads.
• Mergeable, no CHANGELOG.md change.
• Reviewers: the PR description lists three deliberate non-changes (yarn classic git copies, fail-closed for unknown protocols, same-name git/exec: entries); those are the calls worth a second opinion.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does. Yarn berry lock entries that install a package under another dependency name from an exec: script or a non-http git remote (git+ssh:, ssh:, git:, git@host:) were ignored, so VEX could attest a vendored ref not_affected while node_modules/<alias> still got unpatched bytes. These are now read as copies whose package can't be known (like a non-registry URL): they contest a same-version wiring in VEX, and both the hosted and vendored scans name them.

Risk: low. Additive parsing in one function plus two new enum variants; the change fails closed (more VEX contests, more warnings), never fewer. exec:/git copies are never read from disk (read_path is None), and git URLs go through redact_url before they're printed.

Look here

• berry_copy_ref new git/exec: arms
• VEX discovery now pushes any copy ref from the non-file/non-http branch (file:/http are handled earlier at L535, so they aren't double-counted)
• VEX test with a 2.0.0 control
• Hosted scan test

Verified

• Read the full diff (7 files, +260/-47). patch:-wrapped and workspace: refs still return None. exec: resolutions (exec:./gen.js#./gen.js::hash=…&locator=…) resolve relative to the locator= workspace.
• Ran locally on d96f49a: cargo test -p socket-patch-core --lib -- issue_1630 issue_939_other_name_copies, 3/3 passed.
• CI: 86/86 settled (36 success, 50 skipped by path filters). Cursor Bugbot: success, no findings. No open review threads. CHANGELOG.md untouched. Mergeable.

Changes I made: none.

Open questions: none blocking. The description lists three deliberate non-changes: yarn classic git copies, fail-closed for unknown protocols, and same-name git/exec: entries not being named in the vendored scan. Each is a fair follow-up, not a blocker.

Auto-merge (squash) is armed, so approving sends this straight to the merge queue.

---

Generated by Claude Code