[Mikola Lysenko (mikolalysenko)]

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

Fixes #506

Summary

In a Cargo project, agent mode and vex no longer patch or attest a
crate's copy in the shared $CARGO_HOME/registry/src when the project's
Cargo.lock takes that crate from a git, path or [patch] source. Cargo
never builds that copy. Before this change, agent mode could patch it and
vex could emit a false not_affected for code the build doesn't
contain.

Root cause

Apply (find_all_packages_for_purls) and vex
(find_manifest_package_copies_reusing) find a Cargo crate by looking up
<name>-<version> in every registry index dir
(CargoCrawler::find_by_purls), by name and version alone. They never
asked whether the lock takes that crate from a registry. The scan crawl
was already scoped to the lock's registry-sourced entries (lock_scope,
#1662), but these two lookups were not.

What main did with each shape, from the red runs:

Shape	apply on main	vex on main
[patch.crates-io] path in Cargo.toml	skipped (user_patch_conflict)	attests not_affected
same in .cargo/config.toml	skipped (user_patch_conflict)	attests
[patch] + --allow-patch-conflicts	patches unused copy, success	attests
git dependency	patches unused copy, success	attests
path dependency	patches unused copy, success	attests
[replace] (lock keeps registry source + replace key)	skipped; patched with --allow-patch-conflicts	attests

Fix

• Core: CargoCrawler::locked_registry_crates(options) returns the
  registry-sourced (name, version)s of a local project's lock, or
  None when the crawl isn't scoped to a lock (global run, cargo vendor
  directory source, no readable lock). A registry entry carrying a
  replace key (a [replace] override) is out of scope too: the lock
  reader now reads that key (review finding, ed601ac). It shares one helper
  (registry_lock_scope) with crawl_all, so scan, apply and vex agree.
• CLI: retain_locked_cargo_copies drops Cargo copies outside that scope.
  Only the apply and vex lookups call it. Rollback and scan --prune still
  find the copy, because an earlier apply may have patched it (Agent-mode cargo scan --sync / --prune drops the manifest entry of a crate the lock no longer resolves but leaves its shared registry-cache copy patched, so rollback can't restore it (regression from #1205) #1278).
• The Cargo package_not_installed detail and human hint now also name
  the path/git/[patch] case, besides the cargo fetch remedy.
  CLI_CONTRACT.md and docs/ecosystems.md are updated to match.

Tests (red → green)

Issue / case	Test	Before fix	After
#506 apply, git and path deps	apply::cargo_lock_source::crate_overridden_away_from_the_registry_is_not_patched	FAILED (registry copy patched)	ok
#506 apply, [patch] + --allow-patch-conflicts	apply::cargo_lock_source::allowed_patch_conflict_still_leaves_the_unused_registry_copy	FAILED	ok
#506 [replace] (review)	same apply + vex tests, Replace shape; core replaced_registry_entry_is_out_of_scope	FAILED (patched / attested)	ok
#506 vex, all override shapes	e2e_vex::verify_mode_does_not_attest_cargo_crate_overridden_away_from_registry	FAILED (attested)	ok
controls: registry-sourced crate still patched and attested	registry_sourced_crate_is_patched_in_the_registry_cache, verify_mode_attests_registry_sourced_cargo_crate	ok	ok

Commands run locally:

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test --workspace --all-features --no-fail-fast: 14,911 passed, 11
  failed. All 11 are environmental and in code this PR doesn't touch. The
  container runs as root, so the chmod-based write-failure tests in
  in_process_redirect, repair and core vendor::pypi_* /
  vlt_heal / copy_tree can't fail their writes. The two
  e2e_bun_lockb failures come from a blocked network blob fetch and the
  local bun 1.4.4. CI runs these on its own runners.
• Ignored cargo e2e: e2e_safety_cargo_build -- --ignored 10/10 pass.
  e2e_redirect_cargo_build, e2e_redirect_cargo_shapes,
  e2e_vendor_cargo_build and mode_migration_cargo have no ignored tests;
  their regular tests passed in the workspace run.
• No wrapper changes are needed: npm/, pypi/ and gem/ only dispatch
  to the binary.

Review notes (/code-review high), not fixed here

• Workspace member cwd: the scope reads <cwd>/Cargo.lock only, so
  from a member directory with no lock of its own the filter doesn't apply.
  This is the same limitation crawl_all already has. Walking up to an
  ancestor lock risks scoping a nested non-member project to an unrelated
  lock, so it needs its own change. Follow-up.
• get's installed-version narrowing still uses the unscoped rollback
  lookup, so get can record a patch that apply then reports as not
  installed. Nothing gets patched or attested wrongly. Follow-up.
• Git/path dependencies fail an all-miss apply (exit 1) instead of a
  calm skip. This is deliberate: the build stays unpatched, which matches
  vendored mode refusing the same project. The detail now says why.
• .cargo/config paths = [...] overrides leave no trace in
  Cargo.lock, so this lock-based scope can't see them. Plain apply
  already skips them through the user-patch detector, but vex doesn't
  consult it. Follow-up.
• Perf: the filter re-reads the cargo config and Cargo.lock once per
  apply/vex run. That's minor, and only for runs with Cargo purls.

https://claude.ai/code/session_01HAS6MmhgCPZmdDxkfHZmMG

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

Ready for review (burn-down agent)

• Head: 4ca9004c496baf02567dbd1cff8bb7f710b0e06b
• CI: 38/38 non-skipped checks green (50 skipped by path filters), no failures. Mergeable, no conflicts.
• Bugbot: reviewed 4ca9004 and found no new issues. No open review threads.
• CHANGELOG.md untouched.
• For reviewers: the "Review notes" section of the description lists the known limitations left as follow-ups (workspace member cwd without its own Cargo.lock, get's unscoped installed-version narrowing, git/path deps failing an all-miss apply on purpose).

Slack announcement wasn't sent in this run; a later run will retry.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does: In a local Cargo project, agent-mode apply and vex now only use the registry-cache copy of a crate when Cargo.lock takes that crate from a registry. A crate the lock takes from a path, git or [patch] source is no longer patched in (or attested from) the shared $CARGO_HOME/registry/src copy that cargo never builds (#506). The package_not_installed detail and hint now mention this case.

Risk: Low. The filter reuses the lock scope scan already uses (#1662) and only runs for local projects with a readable Cargo.lock. Global runs, cargo vendor sources and lock-less dirs are unchanged. Rollback and scan --prune still see the copy, so patches applied before this change can still be undone.

Look here:

• ecosystem_dispatch.rs:645: retain_locked_cargo_copies, the new filter
• ecosystem_dispatch.rs:633 and :1104: its only two callers (apply lookup, vex/apply --check lookup)
• cargo_crawler.rs:77 and :417: locked_registry_crates / registry_lock_scope, shared with crawl_all
• tests/apply/cargo_lock_source.rs:87:`` git, path and [patch] shapes

Verified:

• Read the full diff and every caller of both changed lookups. Rollback paths don't go through the filter.
• Ran apply::cargo_lock_source (3/3), the cargo e2e_vex tests (2/2) and the core cargo crawler tests. All pass.
• With the two source files reverted to main, the two new apply tests fail. So the tests do exercise the fix.
• CHANGELOG.md is untouched.
• CI on head: 38 success, 50 skipped, 0 failed. ci-ok and clippy are green. Cursor Bugbot: success. No open review threads.

Changes I made: none.

Open questions: none blocking. One note: when --cwd is a workspace member that has no Cargo.lock of its own, nothing is filtered. That is the same behaviour scan's lock scope already has.

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

---

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

[Mikola Lysenko (mikolalysenko)]

[final reviewer] Disabled auto-merge. This PR was armed only on the strength of the final-review brief, and the head has gained non-merge commits since that brief (review fixes pushed today). I'll write a fresh brief once those pushes settle and CI and Bugbot are green on the new head, then re-arm. The Ready for review label is still on; the burn-down should confirm it against the new head.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: Ready for review at ed601ac.

• CI: 56/56 checks on ed601ac passed or skipped (37 success, 19 skipped); mergeable, no conflicts. No main-wide failures. CHANGELOG.md untouched.
• Bugbot: reviewed ed601ac, no findings; all review threads resolved.
• Re-confirmed at the new head (previous label comment was at 4ca9004). Tanmay's review thread is resolved. Auto-merge was disabled by the final reviewer pending a fresh brief.
• Slack announcement not sent this run (Slack send unavailable); the next run will retry.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does: apply (including --check) and vex now patch or attest a shared $CARGO_HOME/registry/src crate copy only when the project's Cargo.lock takes that name@version from a registry+ or sparse+ source and not through [replace] (#506). A crate the lock takes from a path, git, [patch] or [replace] source is reported user_patch_conflict or package_not_installed instead of being patched in a copy the build never uses. rollback and scan --prune are deliberately left unfiltered.

Risk: low to medium.

• When there is no Cargo.lock, the lock can't be parsed, or the run is global or a cargo vendor dir, the filter does nothing, so behaviour stays as on main.
• Visible changes:
  • --allow-patch-conflicts on a [patch]/[replace] crate now exits 1 with package_not_installed (it used to "succeed" on the unused copy).
  • vex exits non-zero for these crates.
  • scan stops listing [replace]d crates.
  • The cargo not-installed detail and hint text gained a sentence.

Look here

• ecosystem_dispatch.rs:645: retain_locked_cargo_copies, called at :633 (apply) and :1104 (vex, apply --check).
• cargo_crawler.rs:77 and :443: locked_registry_crates and the is_from_registry() && replace.is_none() filter.
• formats/cargo/mod.rs:148: parsing of the replace key.
• apply.rs:3358 and :3438: the user-facing detail and hint.

Verified

• A subagent read the full diff.
• CI's clippy command (--workspace --all-features -D warnings) and cargo fmt --check are clean.
• Tests passed:
  • core --lib cargo: 467
  • --test apply: 156 (1 ignored)
  • --test e2e_vex: 45
  • cli --lib (cargo / dispatch / vex): 90
• With retain_locked_cargo_copies turned into a no-op, the 3 new apply/vex tests fail. With the replace.is_none() check dropped, replaced_registry_entry_is_out_of_scope fails. So the tests cover the change.
• CI is green on ed601ac (ci-ok and clippy). Bugbot is clean and there are no open threads. CHANGELOG.md is untouched.

Changes I made: none.

Open questions (none blocking; follow-up material)

• The detail and hint text say "path, git or [patch] source" and leave out [replace]. They also now add the override sentence to every cargo "not fetched yet" message.
• lock_scope reads only <cwd>/Cargo.lock. Run from a workspace member directory, the filter does nothing (it fails open, so behaviour is as on main).
• LockedRegistryCrates keys on (name, version) without the source. That only matters when the same version is pulled from two registries.

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

---

Generated by Claude Code