Gem VEX judges an unused system gem-home copy when the project sets a Bundler path, so standalone vex never attests #1098

[agent] Filed by the scheduled architecture audit routine (ecosystems and formats). Register: register comment.

Kind: bug (inconsistent logic within one ecosystem). Source: new finding; register E90.

Problem

The question "which gem homes does Bundler load this project's gems from" now has two answers on main @ e61a845:

1. RubyCrawler::get_gem_paths (ruby_crawler.rs#L43-L58). It appends every `gem env` home whenever the default `vendor/bundle` holds no store ([`#L136-L143`](https://github.com/SocketDev/socket-patch/blob/e61a8458651f78a8d42e4aad437e66a9f9894f6b/crates/socket-patch-core/src/crawlers/ruby_crawler.rs#L136-L143)).`` It does this even when the project sets an explicit Bundler path, where Bundler disables shared gems. This list feeds scan discovery, agent apply, and vex's installed-copy lookup (ecosystem_dispatch.rs#L618-L660).``
2. RubyCrawler::bundler_install_homes (#L645-L690).`` It was added by Fix gem stale-install guard home selection (#1001, #729) #1002 for Hosted gem stale-install guard flags an unused system gem-home copy when the project sets a Bundler path that isn't installed yet, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1001 and counts the gem env homes only when Bundler uses system gems: no deployment store, and no explicit `path` according to `bundler_sets_explicit_path`. Only the hosted stale-install guard uses it (`scan/hosted.rs#L379`).

For a hosted gem purl, vex requires every copy in list 1 to verify (vex_consumed.rs#L28, vex.rs#L624-L630). #1002 fixed the #1001 symptom for scan --mode hosted --vex, but the standalone vex command still has it.

Proved by execution. I ran a throwaway test twice on e61a845. It reuses the harness of e2e_redirect_gem_stale_install.rs: stage_system_home_copy provides a fake gem env gemdir home holding the unpatched stale-probe-gem-1.0.0, plus the mock API. The steps were:

• .bundle/config sets BUNDLE_PATH;
• scan --mode hosted --vex exits 0, with no stale warning, as Hosted gem stale-install guard flags an unused system gem-home copy when the project sets a Bundler path that isn't installed yet, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1001 intends;
• the lock is then converged (a separate patch-registry GEM section);
• finally, standalone vex runs with the same PATH.

In both failing cases, Bundler never loads the system-home copy (the premise of #1001 and #1002). The project is patched, or about to be, yet vex refuses it on every run. On the fresh checkout, the unused copy also prevents the hosted lockfile basis from applying, because the copy counts as "installed".

The agent apply path reads the same list 1. In an explicit-path project, it therefore also writes to (and rollback restores) a same-version copy in the shared gem home, which Bundler doesn't load for that project. I found this by reading the code; I didn't execute it.

Symptoms

• Hosted gem stale-install guard flags an unused system gem-home copy when the project sets a Bundler path that isn't installed yet, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1001 / Fix gem stale-install guard home selection (#1001, #729) #1002: the same defect in the stale guard, fixed there only.
• Hosted gem scan pins a version that only another project installed into the shared gem home, rewriting gem "x", "~> 1.0" to the older patched "0.8.1", so the prescribed bundle install downgrades the project's locked gem #1055: also shared-gem-home state leaking into a project's answer (version selection; different path).

Impact: fail-closed (no false attestation), but a false negative. Any developer or CI machine whose system gem home holds an old copy of a patched gem never gets vex output for that gem, in projects that set path (common in CI caches, bundle config set --local path vendor/bundle). Size: one model function plus three call sites.

Proposed change

• Make bundler_install_homes (or one BundlerHomes { loaded, default_gem_homes } value built once) the single answer to "which homes does Bundler load for this project".
• Make the gem branch of the vex installed lookup (find_manifest_package_copies_reusing and hosted_consumed_copies) judge only those homes.
• Leave get_gem_paths with only its documented default-gem reason for keeping the gem env homes under an explicit path. Either restrict those homes to gems whose spec is under specifications/default/, or keep them for apply only. The PR decides which and documents it in CLI_CONTRACT's gem section.
• Delete the duplicated tier read: bundler_install_homes re-reads the app, env and global tiers that discover_bundle_stores_impl has already resolved. BundleStoreDiscovery should carry explicit_path so the rule lives in one place.

Size and scope

• crawlers/ruby_crawler.rs, ecosystem_dispatch.rs (the gem branch) and commands/vex_consumed.rs (the gem row), plus tests.
• About 150–250 production lines.
• Out of scope: agent apply write targets beyond the default-gem rule, and Hosted gem scan pins a version that only another project installed into the shared gem home, rewriting gem "x", "~> 1.0" to the older patched "0.8.1", so the prescribed bundle install downgrades the project's locked gem #1055's version selection.

Acceptance criteria

• Standalone vex attests the gem in both failing rows above, and in each BUNDLE_PATH spelling (env, .bundle/config, global config). Add a regression e2e test beside gem_hosted_explicit_bundle_path_ignores_system_home_copy.
• Without a Bundler path (system gems), an unpatched gem env copy still blocks attestation (not_applied), and so does path.system: true outranking env BUNDLE_PATH. This mirrors gem_hosted_system_install_still_flags_system_home_copy.
• Hosted gem VEX attests not_affected for an unpatched install when .bundle/config sets an out-of-tree path (absolute or ~/…), because the skipped bundle root counts as "nothing installed" #709's out-of-tree config root is still read for verification.
• The stale guard and vex take the home list from the same function: a unit test asserts that they agree on each tier combination.
• e2e_redirect_gem_stale_install, the ruby crawler unit tests and the gem VEX discovery tests stay green.

Dependencies

• None blocking.
• Touches the same crawler as Gem agent crawl ignores that BUNDLE_GEMFILE=gemfiles/x.gemfile moves Bundler.root, so a relative bundle path resolves to the wrong dir, apply patches the system copy and vex attests not_affected while Bundler loads the unpatched gemfiles/vendor/bundle copy #952 (BUNDLE_GEMFILE and Bundler.root) and PR Fix hosted gem pinning a version the lock doesn't resolve (#1055) #1060 (Hosted gem scan pins a version that only another project installed into the shared gem home, rewriting gem "x", "~> 1.0" to the older patched "0.8.1", so the prescribed bundle install downgrades the project's locked gem #1055). Rebase on whichever lands first.
• Related to the E40 tracking (Tracking: move vex_consumed's per-ecosystem consumed-copy rules from the CLI into core #855): per-ecosystem consumed-copy rules should live in core.

Backlog review — 2026-10-08

Priority: P1 → P2. An unused system gem copy makes VEX reject a correctly patched Bundler path; false negative.