[Mikola Lysenko (mikolalysenko)]

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

Fixes #1601

Summary

In a vlt project, a hosted scan that skipped a package from a named or scoped registry told users to "use --mode vendored or agent mode". Vendored mode refuses those same nodes with vendor_lock_entry_unsupported, so a user (or a CI script) following the hint got a failed run and the package stayed unpatched. When those were the package's only nodes, the scan also warned redirect_vlt_entry_not_found ("run vlt install first"). That can never work: reinstalling can't move a scoped or aliased package onto the default registry.

Root cause

rewrite_dep in patch/redirect/vlt.rs produced the skip warning text, and the defaults.is_empty() branch then produced entry_not_found. Neither one considered that vendored mode (vendor/vlt_lock.rs) refuses every non-default-registry instance, or that a skip warning had already been emitted.

Fix

• Hosted: redirect_vlt_custom_registry_skipped now says "use agent mode", and it names the plain name@version beside vlt's encoded node ids.
• Only skipped nodes: when every node for the package is a skipped one (a foreign registry, or git, a remote tarball or a local directory), no entry_not_found follows the skip warning. A vendored node still gets redirect_vlt_entry_vendored, which keeps its own remedy.
• Vendored: the refusal ends with "so use agent mode".
• Confirmation: unchanged. The dep was already unconfirmed by vlt in this case, and only the warning list changes.
• Docs: CLI_CONTRACT.md rows and the vlt coverage map are updated. The golden fixture redirect/npm/vlt/custom-registry-skipped drops the old duplicate entry_not_found.
• Wrappers: the npm, PyPI and gem wrappers only dispatch the binary, so nothing changes there.

Tests (red → green)

Issue shape	Test	Before	After
named alias only (~acme~left-pad@1.3.0)	patch::redirect::vlt::tests::a_foreign_only_package_points_to_agent_mode_alone	FAILED (custom_registry_skipped + entry_not_found)	ok
scoped registry only (~http_c++…+~@sc+sp@1.3.0, from the follow-up comment)	same test	FAILED	ok
git or remote tarball only; vendored + foreign; foreign beside default	same test	—	ok
CLI hosted scan, foreign-only lock: one agent-mode warning, nothing written, no VEX	in_process_redirect vlt::scan_redirect_vlt_foreign_only_instance_points_to_agent_mode	FAILED (same pair of codes)	ok
vendored refusal names agent mode	vendor::vlt_lock::tests::target_analysis_refusals	FAILED	ok

Local runs:

• cargo fmt --all -- --check and cargo clippy --workspace --all-features -- -D warnings: clean.

• cargo test -p socket-patch-cli --all-features --lib: 930 ok.

• Core lib: 6680 ok and 4 failed. All core integration binaries pass, including redirect_golden.

• in_process_redirect: 147 ok and 3 failed. mode_migration_vlt: 27 ok.

• python3 -m unittest scripts/tests/test_vlt_coverage.py: ok.

• Every failure (4 core, 3 in_process_redirect) is a permission-injection test that also fails on main in this sandbox, because it runs as root:

  • core: copy_tree relax_loop, vlt_heal unremovable lock, and the poetry/requirements wire-write tests
  • in_process_redirect: the two write-failure tests and vlt_heal invalidation

  None of them touches this change.

• I didn't run the real-vlt e2e (e2e_redirect_vlt_build) locally. Its foreign-registry legs only assert that the warning code is present, which hasn't changed. It passed in CI.

CI on 16ba65b: every check passed or was skipped, including ci-ok, coverage and the vlt e2e. Bugbot reviewed 16ba65b and found no issues.

/code-review high

Fixed in 16ba65b:

• git, remote-tarball and local-directory-only locks still got the vlt install hint
• a foreign node beside a vendored node lost entry_vendored
• the contract wording overstated "nothing is redirected" while a sibling lock can still confirm the dep
• the entry_not_found row didn't mention the exception
• the skip warning named only encoded DepIDs

Not changed:

• A foreign-only dep whose grant has no sha512 still also gets redirect_vlt_missing_sha512 ("retry later"). Moving the skip ahead of that check would change which deps are marked refused (and so never confirmed by a sibling lock). That's a bigger semantic change than this fix needs, and a grant without a sha512 is rare.

---

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

[Mikola Lysenko (mikolalysenko)]

Ready for review at 16ba65b. CI: 86/86 checks on this head passed or were skipped by path filters; no main-wide failures. Branch merges cleanly with main. Bugbot reviewed 16ba65b and found no issues; no open review threads.

Reviewer focus: the reworded skip hints for vlt packages from a non-default registry (crates/socket-patch-core/src/patch/redirect/vlt.rs) and the matching CLI_CONTRACT.md / fixture updates. The hints no longer point users at vendored mode or vlt install, since neither can patch such a package.

Slack announcement could not be sent in this run (no Slack send tool available); the next run should retry.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Ready for review at 16ba65b. CI: 86/86 settled green (36 passed, 50 skipped by path filters); no main-wide failures. Merges cleanly with main. Bugbot reviewed 16ba65b: no findings, no open review threads. No CHANGELOG.md change.

Reviewer focus: the reworded hosted-vlt skip hints for packages from a non-default registry, which no longer point to vendored mode or vlt install (neither can patch such a package).

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does. In a vlt project, a hosted scan that skips a package from a named or scoped registry (or from git or a tarball) used to say "use --mode vendored or agent mode". If those were the package's only nodes, it also said "run vlt install first". Neither remedy works: vendored mode refuses the same nodes, and reinstalling can't move them onto the default registry. Now the skip warning names name@version and points only to agent mode, and the misleading redirect_vlt_entry_not_found is no longer emitted when the skip warning already covers the dep's only nodes. Fixes #1601.

Risk: low. Only warning text and which warnings are emitted change. Edits, the refused set and the foreign set are unchanged, and nothing else keys on the redirect_vlt_entry_not_found code (I grepped the non-test sources). So confirmation and VEX attestation behave as before.

Look here

• vlt.rs:366-372:`` new skip-warning text.
• vlt.rs:415-419:``` the early return that drops entry_not_found for foreign- or outside-only deps. The vendored branch runs first, so `entry_vendored` still fires.
• vlt.rs:815-890:```` unit test covering the named alias, the scoped registry, remote-tarball only, vendored plus foreign, and foreign beside default.
• in_process_redirect/vlt.rs:1462:````` end-to-end CLI scan checks one warning, no writes and no VEX.
• vlt_lock.rs:449: the vendored refusal now ends with "so use agent mode".

Verified

• I read the full diff against main and the surrounding rewrite_dep. The new branch only returns early before a warning-only path, so the edit, refusal and confirmation sets are untouched.
• CLI_CONTRACT.md, the golden fixture and vlt-coverage.json match the code.
• CHANGELOG.md is untouched.
• CI on 16ba65b: 86 check runs, 36 passed and 50 skipped by path filters, none failed. That includes ci-ok, clippy and the vlt e2e.
• Bugbot reviewed this head with no findings. There are no review threads.

Changes I made. None.

Open questions. None blocking. The PR description notes a known leftover: a foreign-only dep whose grant has no sha512 also gets redirect_vlt_missing_sha512. That's rare and fine as a follow-up.

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

---

Generated by Claude Code