Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109

[agent] Found by the scheduled Bundler (RubyGems) bug-hunt routine (ledger #316).

Summary

#1002 fixed #1001 only for an explicit path setting. Bundler also stops using system gems in three other ways:

• deployment true (the .bundle/config setting or env BUNDLE_DEPLOYMENT=true), which installs into vendor/bundle;
• simulate_version 5 on Bundler 4.x, which installs into .bundle/;
• default_install_uses_path true on Bundler 2.x, which also installs into .bundle/.

RubyCrawler::bundler_install_homes still treats all three as "Bundler uses system gems". So on a fresh checkout or a cold CI cache, before the project's bundle dir exists, an unpatched same-version copy in the machine's gem env home is reported as a stale install. The warning is the shared-home flavor, and its remedy tells the user to bundle config set --local path vendor/bundle, which is what deployment already does. The flagged purl is then dropped from the same run's --vex. With one patched gem, scan --mode hosted --vex exits 1 with no_applicable_patches.

Impact

• A deployment-mode project (the standard CI and production setup) can't get an embedded VEX from scan --mode hosted --vex on any machine whose shared gem home holds an old copy of the patched gem.
• The warning is false, and its remedy is wrong. The behaviour fails closed (no false attestation), but it's the same false negative 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 described.

Proof with real Bundler (Ruby 3.3.6)

The system copy is never used in any of these shapes:

export GEM_HOME=$PWD/gh GEM_PATH=$PWD/gh
gem install colorize -v 0.8.1 --no-document        # the shared-home copy
mkdir proj && cd proj
printf 'source "https://rubygems.org"\ngem "colorize", "0.8.1"\n' > Gemfile
bundle _4.0.18_ lock
bundle _4.0.18_ config set --local deployment true   # or BUNDLE_DEPLOYMENT=true, or simulate_version 5
bundle _4.0.18_ install
bundle _4.0.18_ exec ruby -e 'puts Gem.loaded_specs["colorize"].full_gem_path'

socket-patch repro (main 05fd82b)

I used a throwaway test in crates/socket-patch-cli/tests/e2e_redirect_gem_stale_install.rs. It reuses that file's mount_api, write_manifest_pair, stage_system_home_copy and hosted_vex_scan_with_gem_on_path, exactly like gem_hosted_explicit_bundle_path_ignores_system_home_copy, and only changes the .bundle/config / env setting. I ran it twice: once with the harness's fake gem, and once with the real gem and GEM_HOME pointed at the staged home. Both runs gave the same results:

Warning emitted for the deployment case:

pkg:gem/stale-probe-gem@1.0.0 was switched to its hosted patch, but a stale UNPATCHED install is materialized in the shared gem home at …/system-home/gems/stale-probe-gem-1.0.0 — bundle install reuses it without refetching … prefer switching this project to a project-local bundle path (bundle config set --local path vendor/bundle, then bundle install) …

Expected vs actual

• Expected: CLI_CONTRACT.md "Gem stale-install guard" says the gem env homes count only when Bundler uses system gems, "since with such a path bundle install fetches non-default gems into it and never reuses a system copy". Bundler's Settings#path derives the same kind of non-system path from deployment (→ vendor/bundle) and from default_install_uses_path / simulate_version 5 (→ .bundle) whenever no tier sets path / path.system / disable_shared_gems. The guard should skip the system homes in those cases, as it does for an explicit path.
• Actual: the guard models only an explicit path. Its "system gems" test is !default_root_has_stores && !bundler_sets_explicit_path(..), so it falls back to system homes until the deployment store has been installed.

OS × version

First bad version

This isn't a regression. The guard judged every gem env home before #1002 (v4.0.0 included). #1002 (f23fd82) narrowed that for an explicit path only.

Suspect code

• crates/socket-patch-core/src/crawlers/ruby_crawler.rs:655-675 (bundler_install_homes: uses_system_gems ignores deployment, default_install_uses_path and simulate_version).
• crates/socket-patch-core/src/crawlers/ruby_crawler.rs:1204-1229 (bundler_sets_explicit_path reads only path / path.system / disable_shared_gems).
• discover_bundle_stores_impl (ruby_crawler.rs:~452) already knows about the .bundle default (Gem crawler ignores Bundler's .bundle default install path (default_install_uses_path on 2.x, simulate_version 5 on 4.x), so agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched .bundle/ruby/<abi> copy #967), but only probes it once it has been installed.
• Related: Gem VEX judges an unused system gem-home copy when the project sets a Bundler path, so standalone vex never attests #1098 proposes making bundler_install_homes the single answer for standalone vex too. With this gap, that fix would inherit the same false not_applied for deployment projects.

Backlog review — 2026-10-08

Priority: P1 → P2. Unused system gem copies trigger a false stale-install warning and VEX refusal for a correctly selected Bundler path.