Bug hunt ledger: Bundler (RubyGems)

[Mikola Lysenko (mikolalysenko)]

[agent] Progress ledger for the scheduled Bundler (RubyGems) bug-hunt routine (label pm:bundler).

Last updated: 2026-10-01 (run 6), main 61cfb9b, latest release tag v4.0.0.

Coverage matrix

Cells are "pass", "fail #N" or "untested". Hosted and vendored cells use a local mock of the patch API (the sandbox blocks the real one) around real gem build fixtures, followed by a real bundle install on a fresh checkout. The repo's own e2e suites (e2e_redirect_gem_build.rs, e2e_vendor_gem_build.rs, e2e_redirect_gem_stale_install.rs) already cover the plain single-line Gemfile cells across 1.17 → 4.x. This ledger tracks what they don't. setup and the Bundler plugin were removed in v5 (#277), so those columns are retired (the last results were 2.2–2.4 fail #389 → closed, and 2.5 / 4.x pass).

Project modes

OS	Ruby	Bundler	Hosted: single-line decl	Hosted: multi-line decl / if modifier	Hosted: decl in group block	Hosted: platform gem, no CHECKSUMS	Hosted: CHECKSUMS lock	Hosted: stale-install guard	Hosted: BUNDLE_GEMFILE in .bundle/config	Vendored: Gemfile only	Vendored: gems.rb + Gemfile twin	Vendored: BUNDLE_GEMFILE	Vendored: gems.rb only	Agent: multi-home vex
Linux	3.3.6	1.17.x	untested	untested	untested	untested	n/a	untested	untested	untested	untested	untested	untested	untested
Linux	3.3.6	2.2–2.4	untested	fail #340 (2.4)	untested	untested	n/a	untested	fixed #390 (#431)	untested	fixed #341 (#431)	untested	untested	untested
Linux	3.3.6	2.6.9	pass	untested	untested	untested	pass	untested	untested	untested	untested	untested	untested	untested
Linux	3.3.6	4.0.17	pass	fail #340	pass	pass (switches to patched ruby gem)	pass	pass	fixed #390 (#431)	pass	fixed #341 (#431)	fixed #390 (#431)	refused (documented)	fail #420
Linux (CI)	2.7 / 3.3 / 3.4	2.4 / 2.5 / 2.6	untested	untested (OS-independent)	untested	untested	untested	untested	untested (OS-independent)	untested	untested (OS-independent)	untested	untested	fail #420
macOS (CI)	2.7 / 3.3 / 3.4	2.4 / 2.5 / 2.6	untested	untested (OS-independent)	untested	untested	untested	untested	untested (OS-independent)	untested	untested (OS-independent)	untested	untested	fail #420
Windows (CI)	2.7 / 3.3 / 3.4	2.4 / 4.0	untested	untested (OS-independent)	untested	untested	untested	untested	untested (OS-independent)	untested	untested (OS-independent)	untested	untested	blocked by #421

Hosted unwind (rollback / remove, v5 upstream restore; real rubygems.org upstream)

OS	Ruby	Bundler	Direct dep (~>)	Transitive dep	Transitive, Gemfile ends in a blank line	group block + options	CRLF Gemfile	Non-rubygems.org upstream refused	Mixed (no-CHECKSUMS) lock
Linux	3.3.6	4.0.17	pass (exact pin, documented)	fixed #457 (#460)	pass	pass	pass	pass	n/a
Linux	3.3.6	2.6.9	untested	fixed #457 (#460)	untested	untested	untested	untested	documented (Gemfile-only pin is out of reach)
macOS / Windows	any	any	untested	untested (OS-independent)	untested	untested	untested	untested	untested

Other hosted shapes (run 4)

OS	Ruby / Bundler	Multi-platform lock + CHECKSUMS	Multi-platform lock, no CHECKSUMS	gemspec project (PATH)	GIT + PATH sections
Linux	3.3.6 / 4.0.17	pass (refused, documented)	pass (documented caveat)	pass	pass

Declaration and cache shapes (run 5, hosted, Linux, Ruby 3.3.6)

Bundler	eval_gemfile declaration	loop-generated gem g	Transitive, no trailing newline	Transitive, CRLF	Committed vendor/cache guard	Committed cache at configured cache_path	Vendored eval_gemfile
4.0.17	fail #482	fail #482	pass	pass	pass	fail #483	blocked (service artifact)
2.6.9	fail #482	untested	untested	untested	pass	fail #483	untested
2.4.22	fail #482	untested	untested	untested	pass (warns; install stays unpatched per the remedy)	fail #483 (silent unpatched install)	untested

BUNDLE_GEMFILE env vs .bundle/config (run 6, Linux, Ruby 3.3.6)

Bundler	Hosted: config Gemfile.next + env Gemfile	Vendored: same	Env only Gemfile.next	Config only Gemfile.next
4.0.17	fail #507	untested	untested	pass (e2e suite)
2.6.9	fail #507	untested	untested	untested
2.4.22	fail #507	untested	untested	untested

Global mode (-g)

OS	Ruby / Bundler	scan -g report	-g vs project scoping	scan -g --mode hosted refused	get -g / apply -g	rollback -g byte-exact	vex -g	--global-prefix <gems dir> / SOCKET_GLOBAL=1	Non-writable gem dir
Linux (sandbox, rbenv)	3.3.6 / 4.0.17	pass	pass	pass	pass (both homes)	pass	fail #420 (multi-home); pass (single home)	pass	pass (loud Permission denied)
ubuntu-latest	2.7 / 3.3 / 3.4	pass	untested	pass	pass	pass	fail #420	pass	untested
macos-latest (setup-ruby)	2.7 / 3.3 / 3.4	pass	untested	pass	pass	pass	fail #420	pass	untested
windows-latest (RubyInstaller)	3.3 / 3.4	fail #421 (finds nothing)	untested	pass	fail #421	n/a	fail #421	--global-prefix pass; SOCKET_GLOBAL=1 fail #421	untested
windows-latest (RubyInstaller)	2.7	fail #421 (user dir only)	untested	pass	fail #421 (system copy missed)	pass	fail #421	--global-prefix pass	untested
macOS system / Homebrew Ruby, rvm, chruby, asdf	any	untested	untested	untested	untested	untested	untested	untested	untested

Backlog

1. Maintainer request (still open): global (-g) mode on every major version and OS. Remaining: macOS system Ruby and Homebrew Ruby; rbenv / rvm / chruby / asdf layouts; unicode or space-containing --global-prefix; a non-writable dir on macOS and Windows (Program Files); -g from inside a project on macOS and Windows. Re-check On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421 once Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 merges.
2. The vendored arm of Gem manifest resolution lets the BUNDLE_GEMFILE env var override .bundle/config, but Bundler does the reverse, so hosted mode wires Gemfile while bundler installs Gemfile.next unpatched and VEX attests it #507 (vendor/gem.rs:149), driven through a copy of e2e_vendor_gem_build.rs.
3. Vendored eval_gemfile / loop declaration (the sibling of Hosted gem redirect appends a second declaration when the gem is declared through eval_gemfile or a loop, so every bundle install fails with "You cannot specify the same gem twice" #482 at vendor/gem.rs).
4. BUNDLE_CACHE_PATH from the environment (Gem hosted stale-install guard only checks vendor/cache, so a committed cache at a configured cache_path gets no warning, the in-run VEX attests it, and Bundler 2.4 installs the unpatched gem #483's variant); vendor/cache + rollback.
5. Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 on Bundler 2.2–2.5 (Linux); re-run Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 / Hosted gem redirect appends a second declaration when the gem is declared through eval_gemfile or a loop, so every bundle install fails with "You cannot specify the same gem twice" #482 once the Gemfile rewriter changes.
6. Windows local mode for a Bundler project on system gems (no BUNDLE_PATH): does On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421 hide the project's gems too?
7. Windows hosted cells: CRLF Gemfile / lock, a BUNDLE_PATH with a drive letter or spaces, x64-mingw-ucrt platform gems, and vendor/bundle deployment mode.
8. Ruby 3.4 + Bundler 2.2 can't boot. Check the floor messaging, and run scan from a subdirectory of a Bundler project.

Known non-bugs

• patches-api.socket.dev / api.socket.dev are blocked from the sandbox. Use a local mock API (--api-url, --api-token fake --org org). A ~60-line Python mock serving /v0/orgs/org/patches/{batch,view/<uuid>,by-package/…} with blobContent is enough for agent and -g flows; for hosted, use a hold-open copy of e2e_redirect_gem_build.rs.
• v5 vendoring downloads service artifacts only (--vendor-source build is gone). To drive vendored cells, copy e2e_vendor_gem_build.rs (its prebuilt_common fixture serves the artifact) rather than calling the CLI by hand: vendor --offline without a prestaged artifact fails with vendor_service_offline_conflict, which is expected.
• --global-prefix takes the package-leaf dir (<gem home>/gems), like node_modules / site-packages for the other ecosystems. Pointing it at the gem home itself scans 0 packages; that's the convention, not a bug.
• -g agent runs keep their manifest at <cwd>/.socket/manifest.json, and rollback -g removes the entry. vex -g then needs a fresh get -g plus --product (no project to auto-detect from).
• A git-sourced gem (bundler/gems/<name>-<sha>) isn't crawled in agent mode. Patches target registry bytes, so this is plausibly intended (unconfirmed with the docs).
• A gems.rb-only project can't vendor. It's documented, and the refusal is no Gemfile at …/Gemfile.
• A CHECKSUMS-less lock gets redirect_gem_no_checksums_section + redirect_gem_frozen_install and needs one unfrozen bundle install. Documented.
• A platform-resolved gem (-x86_64-linux) on a CHECKSUMS-less lock is redirected, and the next install switches to the patched ruby-platform gem. It's intended. With CHECKSUMS it fails closed (redirect_gem_platform_unsupported).
• bundle install --deployment exits 15 on Bundler 4 (the flag was removed). Use BUNDLE_DEPLOYMENT=true / --frozen.
• Moving a gem into a hosted source block inside a group … do block dedents it. Cosmetic.
• Bundler 1.17 on Ruby 3.3 can't resolve against the mock compact index (a harness limit).
• Hosted rollback / remove refuse a gem whose upstream GEM remote isn't rubygems.org (its CHECKSUMS can't be re-derived). To test the restore, use a real rubygems.org upstream with the patch registry mocked on loopback, and pass --patch-server-url <mock>: discovery only trusts patch.socket.dev or that origin.
• After rollback, a direct dep's original constraint (~> 1.1) comes back as the exact pin "1.1.0". That's documented in "Hosted unwind coverage".
• On a mixed-state (no-CHECKSUMS) lock, rollback reports Manifest not found. The pin is Gemfile-only, which is documented as out of the restore's reach.
• Bundler 2.6 writes no CHECKSUMS by default. Run bundle lock --add-checksums to get the converged shape.
• An in-place hosted rewrite swallows the blank lines before the declaration (the ^\s*gem match). That's cosmetic, and rollback re-derives the layout.
• Probe branches can't be deleted from the cloud sandbox (git push --delete gets 403 from the git proxy). bughunt/bundler/20261001-global-mode is left behind; its workflow is push-triggered only.
• scan --vex takes --vex-product, not --product (that's vex's flag). Without either, a gem project fails with product_undetected.
• A committed vendor/cache with a stale archive still installs unpatched on Bundler 2.4 after the hosted scan. That's documented: the redirect_gem_stale_install remedy says to delete it.
• Bundler's runtime require "bundler/setup" (without bundle exec) reads only the BUNDLE_GEMFILE env var, not .bundle/config; the CLI commands (install, lock, exec) let .bundle/config win. Gem manifest resolution lets the BUNDLE_GEMFILE env var override .bundle/config, but Bundler does the reverse, so hosted mode wires Gemfile while bundler installs Gemfile.next unpatched and VEX attests it #507 is about the CLI order, which decides what gets installed.

[github-actions[bot]]

[agent] 2026-09-30: Bundler (RubyGems) bug-hunt run

This is the first run, so the ledger started empty and there were no pm:bundler issues to re-triage.

Tested: main f6b7fb9 (CLI reports 4.0.0; latest release 4.0.0). Ruby 3.3.6 with Bundler 4.0.9 and 2.4.22 (also installed: 2.5.22, 2.6.9). Linux only.

Setup: the sandbox can't reach the Socket patch API. I used a temporary, uncommitted copy of crates/socket-patch-cli/tests/e2e_redirect_gem_build.rs. It keeps its wiremock (upstream compact index, patch registry, patches API) alive and takes the fixture Gemfile from an env var. For vendored runs I added a small stub patches/view/<uuid> returning blobContent. Every cell ended with a real bundle install on a fresh checkout and a byte/require check of the installed gem.

Cells

• Hosted, multi-line gem "x", ↵ require: false: fail → Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340. The Gemfile no longer parses (bundler exit 4), while the scan reports exit 0 / redirected: 1 and the in-run VEX says not_affected. Failed on 4.0.9 with a CHECKSUMS lock, 4.0.9 without CHECKSUMS, and 2.4.22.
• Hosted, gem "x" if … modifier: fail → Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340. The condition is silently dropped (bundler 4.0.9).
• Hosted, decl inside group :development, :test do with a version constraint + require: false: pass. Patched bytes installed; the block is dedented, which is cosmetic.
• Hosted, stale-install guard (redirect_gem_stale_install) with BUNDLE_PATH in the local .bundle/config, as an env var only, or in the global ~/.bundle/config (absolute): pass.
• Hosted rollback: restored the Gemfile byte-exact (single-line decl): pass.
• Vendored (get --mode vendored --vendor-source build), twin gems.rb + Gemfile: fail → Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341. Only Gemfile/Gemfile.lock are wired. Bundler reads gems.rb and installs upstream bytes, yet vex attests not_affected (vendored). Failed on 4.0.9 unfrozen and 2.4.22 --frozen.
• Vendored, gems.rb only: no write, exit 1 (package_not_installed / vendor_fetch_unverifiable). This is the documented "cannot vendor yet", but the refusal reason is odd, so it's on the backlog.
• macOS / Windows: untested. Both defects are OS-independent text/file-selection logic, so I spent no probe branches this run.

Issues

• Filed Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340: Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340
• Filed Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341: Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341

False positives ruled out

• vendor_fetch_failed / no_local_source on the first vendored attempt came from my mock (no artifact route), not a product bug. Use --vendor-source build plus a view stub with blobContent.
• bundle install --deployment exit 15 on Bundler 4 is the removed flag, not socket-patch.

Next

1. Native/platform gems on a CHECKSUMS-less lock (Bundler 2.2–2.5): the redirect_gem_platform_unsupported guard only reads CHECKSUMS lines, so a name (ver-x86_64-linux) GEM spec without CHECKSUMS may be redirected to the ruby-platform gem. Needs platform .gem fixtures.
2. Why vendored on a gems.rb-only project reports package_not_installed while the same install is found when a Gemfile twin exists (crawler / lock-inventory spelling handling).
3. setup (bundler plugin) on Bundler 2.2 / 2.3 / 4.x, the 1.x refusal and setup --check, with gems.rb, with git/path sources, and setup --remove.
4. A macOS/Windows probe branch running the hosted CRLF Gemfile/lock cells and a Windows BUNDLE_PATH with a drive letter or spaces.
5. Hosted with git- or path-sourced siblings in the lock, BUNDLE_GEMFILE=Gemfile.next dual-boot layouts, and scan from a subdirectory of a bundler project.

[github-actions[bot]]

[agent] 2026-09-30: Bundler (RubyGems) bug-hunt run

Tested: main f6b7fb9 (v4.0.0, the latest release). Ruby 3.3.6 on Linux, with Bundler 4.0.17, 2.5.22, 2.4.22, 2.3.27, 2.2.33 and 1.17.3 (the last only for the BUNDLED WITH refusal). Main hasn't moved since run 1, so re-triage of #340 / #341 was a no-op: nothing landed that could fix them.

Setup: a temporary, uncommitted copy of e2e_redirect_gem_build.rs kept its wiremock (upstream compact index, patch registry, patches API with a blobContent view) alive in hold-open mode, and I drove the real CLI and bundler by hand. Every cell ended with a real bundle install / bundle exec ruby -e 'require …'.

Cells

• Hosted, platform-resolved gem (vuln-gem (1.0.0-x86_64-linux)) on a CHECKSUMS-less lock (backlog 1), Bundler 4.0.17: pass (no bug). The redirect writes the Gemfile source block. The next unfrozen install drops the locked platform spec ("possibly been yanked… ignoring") and installs the patched ruby-platform gem: PATCHED loads. The platform switch is deliberate. With a CHECKSUMS lock, redirect_gem_platform_unsupported fails closed.
• Agent + setup plugin, Gemfile: setup → get → install → bundle pristine → fresh clone → setup --remove:
  • 2.5.22 / 4.0.17: all pass (the remove is byte-exact).
  • 2.2.33 / 2.3.27 / 2.4.22: fail → Bundler plugin from setup does not re-apply gem patches after bundle pristine on Bundler 2.2–2.4, so the patch stays reverted until the next bundle install #389. bundle pristine reverts the patch and no hook fires. The patch comes back at the next bundle install, and setup --check flags not applied on disk. The root cause is on Bundler's side: before 2.5, pristine uses GemInstaller#install_from_spec, which never calls Plugin.hook.
• Agent + setup plugin, gems.rb, 4.0.17: pass (install, pristine, fresh clone).
• setup 1.x refusal: pass. A lock with BUNDLED WITH 1.17.3 makes setup exit 1 with the floor message, setup --check exit 1 on a hand-wired 1.x project, and the refusal still fires on a CRLF lock. With no lock, the machine bundler (4.0.17) is probed, as intended.
• Vendored, gems.rb only (backlog 2): pass (documented refusal). With a plain ruby-platform install the error is the clear no Gemfile at …/Gemfile. Run 1's odd package_not_installed reason came from its platform/mock setup, not the product.
• BUNDLE_GEMFILE: "Gemfile.next" in .bundle/config (dual boot), hosted + in-run VEX, and setup, 4.0.17: fail → Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390. Both wire Gemfile. The scan reports success with no warnings and attests not_affected, setup --check exits 0, and bundler loads Gemfile.next and runs VULNERABLE code. The post-install vex correctly refuses (not_applied).
• macOS / Windows: untested. Both new defects are OS-independent (Bundler's own code path in Bundler plugin from setup does not re-apply gem patches after bundle pristine on Bundler 2.2–2.4, so the patch stays reverted until the next bundle install #389, manifest selection in Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390), so I spent no probe branches.

Issues

• Filed Bundler plugin from setup does not re-apply gem patches after bundle pristine on Bundler 2.2–2.4, so the patch stays reverted until the next bundle install #389: Bundler plugin from setup does not re-apply gem patches after bundle pristine on Bundler 2.2–2.4, so the patch stays reverted until the next bundle install #389
• Filed Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390: Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390
• Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 and Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341 are still open. main is unchanged, so there was nothing to re-check.

False positives ruled out

• setup --json reports "packageManager": "npm" on a Bundler-only project. CLI_CONTRACT documents this ("defaults to npm, only meaningful when npm files were found").
• Bundler 1.17.3 on Ruby 3.3 can't resolve against the mock compact index. That's a harness limit, so I tested the 1.x refusal through BUNDLED WITH.

Next

1. Vendored mode with BUNDLE_GEMFILE in .bundle/config: confirm it shares the Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390 gap, and add one comment to Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390.
2. Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390 on Bundler 2.2–2.6, and the BUNDLE_GEMFILE env-only form with setup in CI.
3. Git- and path-sourced gems: hosted and agent patch targets (bundler/gems/<name>-<sha>), and whether the plugin's patch_target_files misses them.
4. A macOS/Windows probe branch: a CRLF Gemfile/lock hosted cell, a Windows BUNDLE_PATH with a drive letter or spaces, and the plugin's Dir.glob on x64-mingw-ucrt platform gems.
5. Ruby 2.7 and 3.4 runtimes (Bundler 2.2 doesn't boot on 3.4; check that setup still probes correctly).

[github-actions[bot]]

[agent] 2026-10-01: maintainer note: test global (-g) mode for hosted patches

This is a maintainer request, not a run report. Add it to the top of the backlog and keep it there until the cells below are covered.

Ask: make sure we correctly scan global installs when -g / --global is passed, on every major Bundler (RubyGems) version and on Linux, macOS and Windows.

Where Bundler (RubyGems) puts global installs: gem install (gem env gemdir, GEM_HOME, GEM_PATH), gem install --user-install, rbenv / rvm / chruby / asdf, Homebrew Ruby, system Ruby on macOS, and RubyInstaller on Windows.

What to check (prove each with a real global install, not by reading source):

1. socket-patch scan -g (no --mode) is report-only. It must find every globally installed Bundler (RubyGems) package that has a hosted patch: none missing, no project packages leaking in, correct versions. Also check --json.
2. scan -g run from inside a Bundler (RubyGems) project versus outside one: -g must scan only the global location, and a scan without -g must never touch it.
3. scan -g --mode hosted and scan --global-prefix <dir> --mode hosted must refuse loudly, as designed ("global installs have no project lockfile to redirect"). They must exit non-zero and write nothing.
4. get -g defaults to agent mode. Check scan -g --apply, apply -g, rollback -g and vex -g: the globally installed copy is actually patched (run the installed tool or import it), rollback restores it byte for byte, and vex only attests what's applied.
5. --global-prefix <dir> and SOCKET_GLOBAL=1 behave the same as -g. That covers custom prefixes, version managers, paths with spaces or unicode, and a non-root user's prefix.
6. A global directory you can't write to (root-owned prefix, Windows Program Files) must fail loudly with a clear error, never exit 0 unpatched.

Add OS × Bundler (RubyGems) version cells for -g (scan report / apply / rollback) to the coverage matrix, and use probe branches for macOS and Windows.

[github-actions[bot]]

[agent] 2026-10-01: Bundler (RubyGems) bug-hunt run

Tested: main 2463257 (the v5 consolidation, #277; latest release tag v4.0.0). Ruby 3.3.6 with Bundler 4.0.17 and 2.6.9 on Linux. macOS and Windows ran on the GitHub runners with Ruby 2.7.8, 3.3.10 and 3.4.9 (Bundler 2.4.22, 2.5.22, 2.6.9 and 4.0.22). This run focused on the maintainer's global (-g) request.

Setup: for agent and -g I used a small Python mock of the patch API (/v0/orgs/org/patches/{batch,view,by-package}) serving a real patch for colorize@0.8.1, installed globally from rubygems.org. For the hosted and vendored re-checks I used temporary, uncommitted copies of e2e_redirect_gem_build.rs / e2e_vendor_gem_build.rs with the Gemfile line / twin manifests swapped in. Every result was checked against a real gem / bundle install and a require probe.

Re-triage

• Bundler plugin from setup does not re-apply gem patches after bundle pristine on Bundler 2.2–2.4, so the patch stays reverted until the next bundle install #389 was closed by the maintainer: v5 prerelease: scan → vex → vendor workflow, hosted by default #277 removed setup and the Bundler plugin.
• Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 still reproduces on 2463257 (multi-line decl breaks the Gemfile; if modifier dropped). I commented: Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 (comment)
• Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341 still reproduces: vendored wires Gemfile only, and bundle exec loads upstream rack from gems.rb. Comment: Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341 (comment)
• Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390: the hosted half still reproduces; the setup half is moot now. Backlog item 2 confirmed that vendored mode has the same gap. Comment: Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390 (comment)

Cells (global mode, maintainer checklist)

Probe run: https://github.com/SocketDev/socket-patch/actions/runs/36816092864 (ubuntu, macos and windows × Ruby 2.7 / 3.3 / 3.4).

1. scan -g report: pass on Linux and macOS (finds the global colorize, exit 0; SOCKET_GLOBAL=1 behaves the same). Fail on Windows → On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421: scannedPackages: 0 on 3.3 / 3.4, and only the ~/.gem user copy on 2.7.
2. -g from inside a Bundler project with vendor/bundle: pass. Project gems don't leak into -g, and a scan without -g stays on the project stores.
3. scan -g --mode hosted and --global-prefix … --mode hosted: pass (exit 2, loud message, nothing written), on all 9 CI cells too.
4. get -g / apply -g / rollback -g: pass on Linux and macOS (both the gemdir and user-install copies are patched; rollback is byte-exact; re-apply is idempotent). Fail on Windows → On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421: not found on 3.3 / 3.4; on 2.7 the system copy is missed. vex -g refuses correctly when the only copy is reverted, but fails with multiple homes → Gem vex checks the gem env gemdir copy instead of the Gem.path copy Ruby loads, so it attests not_affected while an unpatched --user-install / GEM_PATH copy runs #420: it attests not_affected while Ruby loads an unpatched --user-install / GEM_PATH copy. That reproduced on all six Linux/macOS cells, and also with plain vex in a Bundler project on system gems.
5. --global-prefix: pass when given the …/gems leaf dir (all OSes). Given the gem home itself (gem env gemdir), it scans 0 packages with no hint. That's consistent with the "packages root" convention (node_modules, site-packages), so I didn't file it; see Known non-bugs.
6. Non-writable global gem dir (non-root user, root-owned rbenv gem dir, Linux): pass. get -g exits 1 with Permission denied.

Other cells

• Hosted capstones on Bundler 2.6.9 (CHECKSUMS arm, gems.rb spelling, rotated grant, get-uuid): pass (6/6).
• Git-sourced gem (bundler/gems/colorize-<sha>), agent scan: the git checkout isn't crawled. Only registry copies in the gem homes are reported. That's plausibly intended (a patch targets registry bytes), so I didn't file it; noted in the backlog.

Issues

• Filed Gem vex checks the gem env gemdir copy instead of the Gem.path copy Ruby loads, so it attests not_affected while an unpatched --user-install / GEM_PATH copy runs #420: Gem vex checks the gem env gemdir copy instead of the Gem.path copy Ruby loads, so it attests not_affected while an unpatched --user-install / GEM_PATH copy runs #420 (gem vex checks the gemdir copy instead of the Gem.path copy Ruby loads)
• Filed On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421: On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421 (Windows RubyInstaller: -g finds no global gems because bare gem never resolves to gem.cmd)
• Commented on Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340, Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341 and Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390 (all still reproduce on v5 main).

False positives ruled out

• My first probe push failed only because of an indentation bug in my own heredoc mock (IndentationError). I fixed it and re-ran.
• get -g on Windows 2.7 printing "applied" isn't a pass: it only reached the ~/.gem fallback copy (folded into On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421).

Blocked

• I couldn't delete the probe branch bughunt/bundler/20261001-global-mode: git push --delete gets HTTP 403 from the session's git proxy. Its workflow fires only on push to bughunt/bundler/**, so it's inert, but a maintainer needs to delete it.

Next

1. Windows local (non--g) mode for a Bundler project on system gems (no BUNDLE_PATH): confirm On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421's gem env failure also hides project gems, then comment on On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421.
2. macOS system Ruby / Homebrew Ruby and rbenv / chruby / asdf global layouts for -g, plus a unicode or space-containing --global-prefix.
3. Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 / Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341 / Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390 on Bundler 2.2–2.5 (Linux).
4. Windows hosted cells: a CRLF Gemfile / lock, a BUNDLE_PATH with a drive letter or spaces, and x64-mingw-ucrt platform gems.
5. Git- and path-sourced gems in hosted mode (do the redirect and the stale-install guard ignore GIT / PATH sections cleanly?).

[github-actions[bot]]

[agent] 2026-10-01: handover from the Composer bug-hunt routine (lead, unverified for gem)

While I was confirming #438 (Composer, Windows), the root cause turned out to be SystemCommandRunner::run in crates/socket-patch-core/src/utils/process.rs:137. It calls Command::new(bin) directly, without the PATHEXT-aware resolve_tool in the same file, so on Windows it can't spawn a .bat / .cmd shim. crates/socket-patch-core/src/crawlers/ruby_crawler.rs:549 runs gem env <key> through the same runner. RubyInstaller ships gem as gem.cmd, so gem env discovery (global/-g gem homes) may silently return nothing on Windows. I haven't verified this with a real gem install. Please prove or rule it out with a Windows probe.

Composer evidence: #438 and the probe run https://github.com/SocketDev/socket-patch/actions/runs/36827949605

[github-actions[bot]]

[agent] 2026-10-01: Bundler (RubyGems) bug-hunt run

Tested: main 2463257 (unchanged since the last run; latest release tag v4.0.0). Ruby 3.3.6 on Linux with Bundler 4.0.17 and 2.6.9. This run used no probe branches.

Setup: a hold-open copy of e2e_redirect_gem_build.rs, uncommitted and deleted afterwards. Variant 1 serves a mock upstream plus the patch registry and API, with an optional x86_64-linux platform gem. Variant 2 uses the real rubygems.org as upstream, with the mock serving a patched colorize / rack from the patch registry. Variant 2 is what exercises the v5 upstream restore (rollback / remove), because the restore re-pins CHECKSUMS only from rubygems.org. Every cell ended with a real bundle install (frozen and unfrozen) and a require / dependency probe.

Re-triage

• Main hasn't moved, so Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 / Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341 / Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390 / Gem vex checks the gem env gemdir copy instead of the Gem.path copy Ruby loads, so it attests not_affected while an unpatched --user-install / GEM_PATH copy runs #420 / On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421 stand as reported last run. On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421 has a fix in flight (Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442, shared with On Windows, scan -g / get -g / vex -g find no global npm packages because npm root -g is spawned as bare npm, which never resolves to npm.cmd #434 / On Windows, scan -g finds no Composer global packages in the default %APPDATA%\Composer home, so apply -g and vex -g silently do nothing #438 / scan -g inside a Yarn Berry project runs the project's global package.json script and scans whatever directory it prints as a global install #440). The Composer handover (the SystemCommandRunner + gem.cmd lead) is the same root cause as On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421, which was already filed, so there's nothing new to do there.

Cells

Cell	Result
Hosted, multi-platform lock (ruby + x86_64-linux), CHECKSUMS	pass: fails closed with redirect_gem_platform_unsupported (documented)
Hosted, multi-platform lock, no CHECKSUMS	pass: the frozen install exits 16 (the documented caveat); unfrozen switches to the patched ruby gem
Hosted, gemspec-driven project (the dep comes from a local .gemspec, PATH section), CHECKSUMS	pass: converges; frozen and unfrozen both install patched bytes
Hosted, lock with GIT + PATH sections + a registry dep, CHECKSUMS	pass
rollback with a non-rubygems.org upstream	pass: refused with the documented message
rollback, direct dep with ~> constraint (real rubygems.org)	pass; the constraint comes back as an exact pin (documented)
rollback / remove, transitive dep, CHECKSUMS, Bundler 4.0.17 and 2.6.9	fail → #457
rollback, transitive dep, Gemfile ending in a blank line	pass (byte-identical)
rollback, direct dep in a group … do block with require: false	pass (byte-identical)
rollback, CRLF Gemfile, direct dep	pass (byte-identical, CRLF kept)
rollback, CHECKSUMS-less (mixed) Bundler 2.6.9 lock	Gemfile-only pin; rollback says Manifest not found (documented as out of reach)

Issues

• Filed Gem hosted rollback / remove turn a redirected transitive gem into a top-level exact pin, because the restore looks for a blank line the rewriter never writes #457: Gem hosted rollback / remove turn a redirected transitive gem into a top-level exact pin, because the restore looks for a blank line the rewriter never writes #457. Hosted rollback / remove turn a redirected transitive gem into a top-level gem "x", "<v>" pin plus a DEPENDENCIES entry, so bundle update stays on the vulnerable version. The restore's provably_appended needs a blank line that the rewriter's append (redirect/mod.rs:5070) never writes.

False positives ruled out

• A multi-platform lock that doesn't redirect is the documented redirect_gem_platform_unsupported refusal.
• rollback with no --patch-server-url against the loopback mock finds no pins. Discovery only trusts patch.socket.dev or the configured origin, as documented.
• Bundler 2.6.9 writes no CHECKSUMS unless you run bundle lock --add-checksums. My first 2.6.9 attempt was the mixed state, not a repro. I re-ran it with checksums.

Blocked

• git push --delete of bughunt/bundler/20261001-global-mode is still refused by the session's git proxy ("remote end hung up"). A maintainer needs to delete it.

Next

1. A hosted redirect of a transitive gem when the Gemfile is CRLF, or has no trailing newline (the append path), plus rollback (feeds Gem hosted rollback / remove turn a redirected transitive gem into a top-level exact pin, because the restore looks for a blank line the rewriter never writes #457).
2. A vendor/cache (bundle package) project in hosted mode: the stale-install guard's committed-cache warning, and rollback.
3. Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 / Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341 / Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390 on Bundler 2.2–2.5 (Linux).
4. Windows hosted cells: a CRLF lock, BUNDLE_PATH with a drive letter or spaces, x64-mingw-ucrt platform gems (probe branch).
5. Re-check On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421 after Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 merges (Windows -g on RubyInstaller 2.7 / 3.3 / 3.4).

[github-actions[bot]]

[agent] 2026-10-01: Bundler (RubyGems) bug-hunt run

Tested: main 6e7ef74; the latest release tag is still v4.0.0, and I also ran the npm v4.0.0 binary to bisect. Ruby 3.3.6 on Linux with Bundler 4.0.17, 2.6.9 and 2.4.22. This run used no probe branches.

Setup: a hold-open copy of e2e_redirect_gem_build.rs (uncommitted, and deleted afterwards), plus a parent-gem → vuln-gem fixture for the transitive cells. Every cell ended with a real bundle install on a fresh checkout, and I compared the installed bytes against the patched blob.

Re-triage

• Main's new commits (npm hosted and vendored modes rewire git-sourced lock entries, so npm ci silently installs the unpatched git bytes while scan and VEX report success #326, Agent-mode scan misses Poetry's venv for nameless non-package-mode projects, [project].name overrides, and in-project = false with a stray .venv, and still exits 0 #327, npm VEX attests not_affected while a bundled (inBundle) copy of the same package@version stays unpatched #325, Hosted Maven Trusted Checksums are silently inert on Maven 3.9.0–3.9.3 (docs and the test gate claim ≥3.9 enforces) #258) don't touch gem code, so Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 / Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341 / Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390 / Gem vex checks the gem env gemdir copy instead of the Gem.path copy Ruby loads, so it attests not_affected while an unpatched --user-install / GEM_PATH copy runs #420 / On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421 / Gem hosted rollback / remove turn a redirected transitive gem into a top-level exact pin, because the restore looks for a blank line the rewriter never writes #457 stand. Gem hosted rollback / remove turn a redirected transitive gem into a top-level exact pin, because the restore looks for a blank line the rewriter never writes #457 has draft PR Fix gem rollback pinning redirected transitive gems (#457) #460.
• Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390 also reproduces on Bundler 2.4.22. I commented on the issue.

Cells

Cell	Result
Hosted, direct dep declared via eval_gemfile "Gemfile.shared" (4.0.17 / 2.6.9 / 2.4.22)	fail → #482 (appended a duplicate declaration; bundle install exits 4)
Hosted, %w[x].each { |g| gem g } declaration	fail → #482
Same cells on the v4.0.0 release	fail (not a v5 regression)
Hosted, transitive dep, Gemfile with no trailing newline	pass (frozen install, patched bytes)
Hosted, transitive dep, CRLF Gemfile + lock	pass (frozen install, patched bytes)
Hosted, committed vendor/cache, fresh checkout (4.0.17, 2.4.22, 2.6.9)	pass: the documented redirect_gem_stale_install fires and VEX is withheld
Hosted, committed cache at a configured cache_path: vendor/gems (4.0.17 / 2.6.9 / 2.4.22)	fail → #483 (no warning, VEX attests; 2.4 silently installs the unpatched gem, 2.6 / 4.0 exit 37)
Hosted, BUNDLE_GEMFILE in .bundle/config, Bundler 2.4.22	fail #390 (commented)
Vendored, eval_gemfile declaration	blocked: v5 vendoring needs a service artifact (vendor --offline → vendor_service_offline_conflict). The append path at vendor/gem.rs:1304 has the same shape, but that's unverified.

Issues

• Filed Hosted gem redirect appends a second declaration when the gem is declared through eval_gemfile or a loop, so every bundle install fails with "You cannot specify the same gem twice" #482: Hosted gem redirect appends a second declaration when the gem is declared through eval_gemfile or a loop, so every bundle install fails with "You cannot specify the same gem twice" #482
• Filed Gem hosted stale-install guard only checks vendor/cache, so a committed cache at a configured cache_path gets no warning, the in-run VEX attests it, and Bundler 2.4 installs the unpatched gem #483: Gem hosted stale-install guard only checks vendor/cache, so a committed cache at a configured cache_path gets no warning, the in-run VEX attests it, and Bundler 2.4 installs the unpatched gem #483
• Commented on Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390: Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390 (comment)

False positives ruled out

• An "UNPATCHED" reading on the transitive cells came from my own probe (it grepped for the wrong marker). The installed bytes cmp-match the patched blob.
• A first vendor/cache run that looked like "no warning" came from a broken copy step in my script (cp -r created vendor/ as the cache dir). After fixing the copy, the default path warns correctly.
• scan --vex --product is a clap usage error (exit 2). The flag is --vex-product.

Next

1. Vendored eval_gemfile / loop declaration (Hosted gem redirect appends a second declaration when the gem is declared through eval_gemfile or a loop, so every bundle install fails with "You cannot specify the same gem twice" #482's sibling), driven through a copy of e2e_vendor_gem_build.rs with its service-artifact fixture.
2. Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 / Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341 on Bundler 2.2–2.5 (Linux).
3. Windows hosted cells (probe branch): CRLF lock, BUNDLE_PATH with a drive letter or spaces, x64-mingw-ucrt platform gems.
4. BUNDLE_CACHE_PATH given through the environment (not .bundle/config), and vendor/cache with rollback.
5. Re-check On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421 after Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 merges, and Gem hosted rollback / remove turn a redirected transitive gem into a top-level exact pin, because the restore looks for a blank line the rewriter never writes #457 after Fix gem rollback pinning redirected transitive gems (#457) #460 merges.

[github-actions[bot]]

[agent] 2026-10-01: Bundler (RubyGems) bug-hunt run

Tested: main 61cfb9b; the latest release tag is still v4.0.0. Ruby 3.3.6 on Linux with Bundler 4.0.17, 2.6.9 and 2.4.22. This run used no probe branches.

Setup: a copy of e2e_redirect_gem_build.rs with an extra driver, uncommitted and reverted afterwards. It reuses the ScanVexDualBoot project (.bundle/config BUNDLE_GEMFILE: Gemfile.next) and runs the CLI with BUNDLE_GEMFILE=Gemfile in its environment, then runs a real bundle install with that same env and compares the installed bytes.

Re-triage

• Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341, Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390 and Gem hosted rollback / remove turn a redirected transitive gem into a top-level exact pin, because the restore looks for a blank line the rewriter never writes #457 were closed by Fix gem modes wiring a manifest Bundler ignores (#341, #390) #431 / Fix gem rollback pinning redirected transitive gems (#457) #460 since the last run.
• Hosted gem redirect appends a second declaration when the gem is declared through eval_gemfile or a loop, so every bundle install fails with "You cannot specify the same gem twice" #482 / Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340: main's diff since 6e7ef74 doesn't touch the Gemfile rewriter (formats/gem/ only gained manifest.rs), so both stand. I didn't re-run them.
• Gem vex checks the gem env gemdir copy instead of the Gem.path copy Ruby loads, so it attests not_affected while an unpatched --user-install / GEM_PATH copy runs #420 / On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421 / Gem hosted stale-install guard only checks vendor/cache, so a committed cache at a configured cache_path gets no warning, the in-run VEX attests it, and Bundler 2.4 installs the unpatched gem #483: no related commits, so they stand.

Cells

Cell	Result
Real Bundler precedence: .bundle/config gemfile vs the BUNDLE_GEMFILE env (4.0.17 / 2.6.9 / 2.4.22)	Config wins on all three (bundle lock writes the config manifest's lock; bundle config get gemfile lists local first)
Hosted, config Gemfile.next + env BUNDLE_GEMFILE=Gemfile (4.0.17 ×2, 2.6.9, 2.4.22)	fail → #507: rewrites Gemfile, redirected 1, VEX 1 statement; bundle install installs the unpatched gem from Gemfile.next
BUNDLE_APP_CONFIG relative resolution (code read vs Bundler.app_config_path)	matches Bundler

Issues

• Filed Gem manifest resolution lets the BUNDLE_GEMFILE env var override .bundle/config, but Bundler does the reverse, so hosted mode wires Gemfile while bundler installs Gemfile.next unpatched and VEX attests it #507: Gem manifest resolution lets the BUNDLE_GEMFILE env var override .bundle/config, but Bundler does the reverse, so hosted mode wires Gemfile while bundler installs Gemfile.next unpatched and VEX attests it #507 (first bad commit 9d718cf / Fix gem modes wiring a manifest Bundler ignores (#341, #390) #431)

False positives ruled out

• None this run.

Next

1. Vendored arm of Gem manifest resolution lets the BUNDLE_GEMFILE env var override .bundle/config, but Bundler does the reverse, so hosted mode wires Gemfile while bundler installs Gemfile.next unpatched and VEX attests it #507 (vendor/gem.rs:149, same bundler_loaded_manifest), driven through a copy of e2e_vendor_gem_build.rs.
2. Vendored eval_gemfile / loop declaration (Hosted gem redirect appends a second declaration when the gem is declared through eval_gemfile or a loop, so every bundle install fails with "You cannot specify the same gem twice" #482's sibling).
3. BUNDLE_CACHE_PATH given through the environment (Gem hosted stale-install guard only checks vendor/cache, so a committed cache at a configured cache_path gets no warning, the in-run VEX attests it, and Bundler 2.4 installs the unpatched gem #483's variant); vendor/cache with rollback.
4. Re-run Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 on Bundler 2.2–2.5 and re-check On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421 after Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 merges.
5. Windows hosted cells (probe branch): CRLF lock, BUNDLE_PATH with a drive letter, x64-mingw-ucrt platform gems.