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-03 (run 13), main 045d7ec (includes #532, #552, #517, #442), 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)	fixed #420 (#517)
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	fixed #420 (#517)
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	fixed #420 (#517, probe pass)
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	fixed #420 (#517, probe pass)

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	fixed #482 (#552)	fixed #482 (#552)	pass	pass	pass	fixed #483 (#532)	fixed #482 (#552)
2.6.9	fixed #482 (#552)	untested	untested	untested	pass	fixed #483 (#532)	fixed #482 (#552)
2.4.22	fixed #482 (#552)	untested	untested	untested	pass (warns; install stays unpatched per the remedy)	fixed #483 (#532)	fixed #482 (#552)

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	fixed #507 (#532)	fixed #507 (#532)	vendored pass (refused)	pass (e2e suite)
2.6.9	fixed #507 (#532, OS/version-independent)	fixed #507 (#532)	untested	untested
2.4.22	fixed #507 (#532)	fixed #507 (#532)	untested	untested

Vendored declaration shapes and lifecycle (run 7, Linux, Ruby 3.3.6)

Bundler	Multi-line decl	if modifier	group + platforms:	CRLF + gem(...)	Re-run idempotent	Double --revert byte-exact
4.0.17	pass (refused)	pass (refused)	pass (refused)	pass (refused)	pass	pass
2.4.22	untested	untested	untested	untested	pass	pass

Run 8 (Linux, Ruby 3.3.6)

Bundler	Hosted: gem in two group blocks	Hosted: top-level + group dup	Vendored: dup decl	Vendored: CHECKSUMS lock (direct / transitive)	Vendored: gemspec transitive	Vendored: multi-platform lock	Vendored: native platform gem	Hosted: env BUNDLE_CACHE_PATH	Hosted: BUNDLE_APP_CONFIG + Gemfile.next	Hosted: source … do / platforms: / install_if / group: / quotes
4.0.17	fixed #548 (#552)	fixed #548 (#552)	pass (refused)	pass	pass	pass	refused (documented)	fixed #483 (#532)	pass (refused)	pass
2.6.9	fixed #548 (#552)	untested	untested	pass	pass	untested	untested	untested	untested	untested
2.4.22	fixed #548 (#552)	untested	untested	n/a	pass	untested	untested	fixed #483 (#532)	untested	untested

Bundler global config tier (run 9, Linux, Ruby 3.3.6)

Bundler	Hosted: global cache_path (~/.bundle/config)	Hosted: global cache_path (BUNDLE_USER_CONFIG)	Hosted: global gemfile Gemfile.next	Agent: global path
4.0.17	fail #577	fail #577	fail #577	fail #577 (patches the system copy; false VEX)
2.4.22	fail #577 (real install picks up the cached bytes)	fail #577 (OS/version-independent)	fail #577	fail #577

Run 10 (agent mode, Bundler project on system gems, colorize@0.8.1 mock patch)

OS	Ruby / Bundler	Agent scan / get / vex / rollback, path with a space	Env BUNDLE_PATH + local config path
Linux	3.3.6 / 4.0.17	pass	pass (fans out to every store)
windows-latest	2.7 / 3.3 / 3.4 (Bundler 4.0.x)	pass	untested
macos-latest	2.7 / 3.3 / 3.4 (Bundler 4.0.x)	pass	untested

Run 11 (hosted, git-sourced declarations, Linux, Ruby 3.3.6)

Bundler	Custom git_source key	Built-in gitlab:	String-keyed "git" =>	"github" =>
4.0.17	fail #652	fail #652	fail #652 (option dropped)	untested (needs network)
2.5.22	fail #652	untested	untested	untested

Run 12 (Linux, Ruby 3.3.6)

Bundler	Repo gem e2e suites	Vendored: custom git_source gem	Hosted: mirror.all in .bundle/config, no CHECKSUMS	Hosted: mirror.all, CHECKSUMS lock
4.0.17	pass	pass (fails closed)	fail #681	fail #681 (exit 37)
2.7.2	pass (11 + 6 + 25)	untested	untested	untested
2.6.9	untested	untested	untested	fail #681 (exit 37)
2.5.22	untested	untested	fail #681	n/a
2.4.22	untested	untested	fail #681	n/a

Run 13: hosted lifecycle on more shapes (mock patch API + registry, real rubygems.org upstream)

OS	Ruby	Bundler	gems.rb redirect → install → rollback → frozen install	Gemfile + gems.rb twin unwind	CRLF manifest + CRLF lock cycle	remove purl / uuid (CRLF gems.rb)	Unwind: direct ~> / group + opts	Uppercase name (ZenTest), 2-constraint decl	Config path outside the project (stale guard + VEX)
Linux	3.3.6	4.0.17	pass	pass	pass	pass	pass	pass	fail #709
Linux	3.3.6	2.6.9	pass	untested	pass	untested	pass	pass	fail #709
Linux	3.3.6	2.4.22	converged-lock unwind pass	untested	untested	untested	untested	untested	fail #709
windows-latest	3.3 / 3.4	2.6.9 / 4.0.17	pass (Gemfile too)	untested	pass	untested	untested	untested	fail #709 (4.0.17, D:/…)
macos-latest	3.3 / 3.4	2.6.9 / 4.0.17	pass (Gemfile too)	untested	pass	untested	untested	untested	fail #709 (4.0.17)

Controls for #709 (Linux, 4.0.17): config path relative, config path absolute inside the project, env BUNDLE_PATH absolute outside the project, and path.system: true all pass (stale warning; vex refuses not_applied).

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	fixed #420 (#517); pass (single home)	pass	pass (loud Permission denied)
ubuntu-latest	2.7 / 3.3 / 3.4	pass	untested	pass	pass	pass	fixed #420 (#517)	pass	untested
macos-latest (setup-ruby)	2.7 / 3.3 / 3.4	pass	untested	pass	pass	pass	fixed #420 (#517)	pass	untested
windows-latest (RubyInstaller)	3.3 / 3.4	fixed #421 (#442, run 10 probe)	untested	pass	pass (both homes)	pass	pass (refuses after a user reinstall)	pass	untested
windows-latest (RubyInstaller)	2.7	fixed #421 (#442, run 10 probe)	untested	pass	pass (both homes)	pass	pass	pass	untested
macOS system / Homebrew Ruby, rvm, chruby, asdf	any	untested	untested	untested	untested	untested	untested	untested	untested

Backlog

1. Re-run Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 / Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577 / Hosted gem redirect treats a gitlab: or custom git_source gem as patched, so Bundler keeps loading the unpatched git checkout while VEX attests not_affected #652 / Hosted gem redirect ignores Bundler's mirror.all setting, so the next bundle install fetches the redirected gem's upstream bytes from the mirror while the in-run VEX attests not_affected #681 / 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 when Fix hosted gem redirect breaking multi-line and conditional gem lines (#340) #637 / Fix Bundler global config being ignored (#577) #621 / Fix hosted gem redirect ignoring Bundler mirror.all (#681) #684 (or any fix for 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) merge. Fix hosted gem redirect ignoring Bundler mirror.all (#681) #684 already covers mirror.<url> / fallback_timeout / BUNDLE_MIRROR__*, and Fix Bundler global config being ignored (#577) #621 covers BUNDLE_USER_HOME, so neither needs its own hunt any more.
2. Windows: x64-mingw-ucrt platform gems in hosted and vendored modes; BUNDLE_DEPLOYMENT=true with a CRLF lock.
3. Vendored cells on Windows and macOS (needs a Rust-test probe around e2e_vendor_gem_build.rs).
4. Maintainer request (still open): global (-g) mode on every 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.
5. A symlinked env BUNDLE_GEMFILE next to a config gemfile (env_keeps_root compares lexically): needs a macOS probe (/var vs /private/var).
6. 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); Ruby 2.7 + Bundler 2.2/2.3 hosted unwind (setup-ruby probe).
7. Bundler 2.7.2 hand-driven cells (vendored shapes, hosted unwind), beyond the repo suites.

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.
• Vendored mode refuses multi-line, conditional (if/unless), indented (group) and parenthesized gem(...) declarations with gemfile_declaration_not_editable and writes nothing. That's fail-closed by design, unlike the hosted rewriter (Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340).
• The vendor probes need BUNDLER_VERSION=<v> alongside SOCKET_PATCH_BUNDLER_E2E_VERSION=<v> to pick a Bundler older than the Ruby default (2.5.22 on 3.3.6).
• scan run from a project subdirectory (or with --cwd pointing at one) scans 0 packages: the cwd is the project root, and there's no walk-up the way Bundler does it.
• Vendoring a native platform gem (ffi-…-x86_64-linux-gnu) is refused with platform_gem_unsupported. Documented.
• Hosted refuses a declaration with an inline source: option (redirect_gem_source_option). With --vex the scan exits 1 and writes no VEX. That's fail-closed by design.
• bundle config set <key> without --local/--global, run inside a project, writes the local .bundle/config on Bundler 2.4 / 2.6 / 4.0 (verified in run 9). Only an explicit --global reaches the global tier (Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577).
• Probe workflows must wait for the mock API to listen before the first call. The run-10 Windows scan -g "0 found" was a "connection refused" race, not a crawler miss.
• bughunt/bundler/20261002-win-recheck is also left behind (git push --delete gets 403); its workflow is push-triggered only.
• gem_tail_source_option matches substrings, so a symbol such as group: :gitlab_ci would trip the :git refusal. It's fail-closed and contrived, so it's not filed.
• Vendoring a git-sourced gem (git:, gitlab:, custom git_source) fails closed with apply_failed ("GEM specs has no entry"), because the lock check fires before the Gemfile token list matters. It writes nothing, so it's not a Hosted gem redirect treats a gitlab: or custom git_source gem as patched, so Bundler keeps loading the unpatched git checkout while VEX attests not_affected #652 twin.
• On a CHECKSUMS lock whose install failed (nothing installed), the post-install vex still attests the redirected gem. That's consistent with the "missing files never prove staleness" rule in CLI_CONTRACT.md.
• get <uuid> --mode hosted for a version the lock doesn't hold pins (and downgrades to) the patched version, adds a second CHECKSUMS entry, and leaves a mixed pair that rollback / remove can't see (Manifest not found) until the prescribed unfrozen bundle install converges it (after that, rollback works). The uuid path is documented as exempt from installed narrowing (run 13).
• Bundler 4 prints "Cannot write a changed lockfile while frozen." (exit 0) for any CRLF lock under BUNDLE_FROZEN, including the pristine lock. It's Bundler's own behaviour.
• The in-place hosted rewrite of a CRLF manifest writes the source … do block with LF endings (mixed endings). Bundler, frozen installs and rollback accept it, so it's cosmetic.
• Hosted rollback / remove can be exercised by hand with no Rust harness: a Python mock of the patch API + the patch-registry compact index (rebuild the real .gem with gem unpack / gem spec --ruby / gem build), with rubygems.org as the real upstream. The run-13 entry describes it; the mock must ignore nothing the CLI checks (registryOverride.identifiers.gemChecksumSha256 = the sha256 of the served .gem).
• bughunt/bundler/20261003-hosted-xos is also left behind (git push --delete hangs up / 403); its workflow is push-triggered only.

[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.

[github-actions[bot]]

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

Tested: main 61cfb9b (unchanged since the last run); 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 (picked with BUNDLER_VERSION). This run used no probe branches.

Setup: uncommitted probe tests added to a copy of e2e_vendor_gem_build.rs and reverted afterwards. They use staged_rack_project plus the prebuilt-artifact fixture, then a real bundle install / bundle exec on a fresh vendor/bundle.

Re-triage

• Main hasn't moved since 61cfb9b, so Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340, 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, 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, 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 and 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 all stand. I didn't re-run them.

Cells

Cell	Result
Vendored, config Gemfile.next + env BUNDLE_GEMFILE=Gemfile (4.0.17 ×2, 2.6.9, 2.4.22)	fail → #507 (comment): wires Gemfile and exits 0; Bundler installs unpatched rack from Gemfile.next; vex attests not_affected
Vendored, env-only BUNDLE_GEMFILE=Gemfile.next (4.0.17)	pass (gemfile_not_loaded)
Vendored eval_gemfile declaration (4.0.17 ×2, 2.6.9, 2.4.22)	fail → #482 (comment, the vendored arm is now verified): appends a managed block and exits 0; every bundle install / exec exits 4 ("same gem twice")
Vendored multi-line decl, if modifier, group + platforms:, CRLF + gem(...) (4.0.17)	pass (fail closed: gemfile_declaration_not_editable, nothing written)
Vendored re-run + double --revert (4.0.17, 2.4.22)	pass (already_vendored; byte-exact Gemfile and lock restore; frozen install ok)

Issues

• Commented on 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 (comment)
• Commented on 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 (comment)
• No new issues filed: both failures share a root cause with an existing issue.

False positives ruled out

• Vendored mode's refusals for multi-line, conditional, indented and parenthesized declarations are the documented fail-closed behaviour, not bugs.

Next

1. 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.
2. 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 (hosted, Linux).
3. Windows hosted and vendored cells (probe branch): CRLF lock, BUNDLE_PATH with a drive letter or spaces, x64-mingw-ucrt platform gems.
4. Global mode on macOS system and Homebrew Ruby; 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.
5. Vendored transitive dep of a gemspec project (PATH section); vendored on a multi-platform CHECKSUMS lock.

[github-actions[bot]]

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

Tested: main 61cfb9b (unchanged since the last run); the latest release is still v4.0.0 (npm @socketsecurity/socket-patch@4.0.0, also tested). Ruby 3.3.6 on Linux with Bundler 4.0.17, 2.6.9 and 2.4.22 (picked with BUNDLER_VERSION). I also built the head of draft PR #532 (477aae9). This run used no probe branches: every cell was in the OS-independent Gemfile / lock text layer.

Setup: uncommitted probes in copies of e2e_vendor_gem_build.rs (prebuilt-artifact fixture, real bundle install / exec on a fresh checkout) and a hold-open redirect_scanned_project (CHECKSUMS lock, mock upstream, registry and API on loopback), driven by hand. All probe edits were reverted afterwards.

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, 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, 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, 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 and 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 all stand.
• 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: draft PR Fix Bundler settings resolution order (#483, #507) #532 fixes both the BUNDLE_CACHE_PATH env arm and the .bundle/config cache_path arm. On main, the env arm gives no warning; on 4.0.17 the next install exits 37 (checksum mismatch), and on 2.4.22 it silently installs unpatched. Comment: 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 (comment)

Cells

Cell	Result
Hosted, gem in two group blocks / top-level + group (4.0.17 ×2, 2.6.9, 2.4.22, v4.0.0, PR #532)	fail → #548: only the first declaration is rewritten; bundle install exits 4 ("same gem twice"); --vex attests not_affected
Vendored, top-level + group duplicate (4.0.17)	pass (refused: declared more than once, nothing written)
Vendored direct dep on a CHECKSUMS lock (4.0.17, 2.6.9)	pass (frozen install, byte-stable lock, patched at runtime, VEX, byte-exact revert)
Vendored transitive dep on a CHECKSUMS lock (4.0.17, 2.6.9)	pass
Vendored transitive dep of a gemspec (PATH) project, with and without CHECKSUMS (4.0.17, 2.6.9, 2.4.22)	pass
Vendored on a multi-platform CHECKSUMS lock, pure-ruby gem (4.0.17)	pass
Vendored native platform gem (ffi-1.17.4-x86_64-linux-gnu), single- or multi-platform lock (4.0.17)	pass (refused: platform_gem_unsupported, documented)
Hosted BUNDLE_CACHE_PATH from env (4.0.17, 2.4.22)	fail → #483 (comment; fixed by #532)
Hosted BUNDLE_APP_CONFIG elsewhere with gemfile Gemfile.next (4.0.17)	pass (redirect_gem_bundle_gemfile_unsupported)
Hosted scan from a project subdirectory (4.0.17)	pass (scans 0 packages; cwd is the project root)
Hosted inline source: option (4.0.17)	pass (redirect_gem_source_option; with --vex the scan exits 1 and writes no VEX)
Hosted pre-existing source … do block; platforms: array; single quotes + require: + comment; install_if block; group: option (4.0.17)	pass (patched install; the frozen reinstall passes)

Issues

• Filed Hosted gem redirect rewrites only the first of a gem's declarations, so a gem listed in two group blocks makes every bundle install fail with "You cannot specify the same gem twice" #548: Hosted gem redirect rewrites only the first of a gem's declarations, so a gem listed in two group blocks makes every bundle install fail with "You cannot specify the same gem twice" #548
• Commented on 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 (PR Fix Bundler settings resolution order (#483, #507) #532 verified).

False positives ruled out

• scan from a subdirectory finding nothing follows the cwd-is-root convention.
• Vendoring a native platform gem is a documented refusal (platform_gem_unsupported).

Next

1. Hosted gem redirect rewrites only the first of a gem's declarations, so a gem listed in two group blocks makes every bundle install fail with "You cannot specify the same gem twice" #548 on macOS and Windows isn't needed (text layer). Re-run once the rewriter changes; also check that rollback restores both declarations.
2. 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 (hosted, Linux).
3. Windows hosted and vendored cells (probe branch): CRLF lock, BUNDLE_PATH with a drive letter or spaces, x64-mingw-ucrt platform gems.
4. Global mode on macOS system and Homebrew Ruby; 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.
5. Re-verify 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 and 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 when Fix Bundler settings resolution order (#483, #507) #532 merges.

[github-actions[bot]]

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

Tested: main 1169ae6, which now includes #532 (cbf1f74, the fix for #483 and #507). The latest release tag is still v4.0.0. Ruby 3.3.6 on Linux with Bundler 4.0.17, 2.6.9, 2.4.22 and 2.2.33 (installed this run). This run used no probe branches: every cell was in the OS-independent settings layer.

Setup: uncommitted probe tests in a copy of e2e_redirect_gem_stale_install.rs (mock API, real binary), reverted afterwards, plus real bundle config / bundle cache / bundle install runs against rubygems.org with a $HOME per Bundler version.

Re-triage

• 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 and 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 were closed by Fix Bundler settings resolution order (#483, #507) #532's merge. The new e2e cases (local cache_path, env BUNDLE_CACHE_PATH, BUNDLE_IGNORE_CONFIG, config gemfile Gemfile.next vs env BUNDLE_GEMFILE) pass on main. I left no comment because they're already closed.
• Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340, 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, 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 and Hosted gem redirect rewrites only the first of a gem's declarations, so a gem listed in two group blocks makes every bundle install fail with "You cannot specify the same gem twice" #548 stand. Nothing on main touched the gem rewriter, the vex gem-home lookup or the Windows gem spawn, so I didn't re-run them.

Cells

Cell	Result
bundle config set cache_path with no --local (2.4.22, 2.6.9, 4.0.17)	writes the local .bundle/config on all three, so it's covered by #532
Hosted, global cache_path in $HOME/.bundle/config + committed stale archive (4.0.17 ×2)	fail → #577: no redirect_gem_stale_install; the in-run VEX attests the purl
Same, through BUNDLE_USER_CONFIG (×2)	fail → #577
Real Bundler honors a global cache_path (2.4.22 ×2 with the marker installed, control without it; 4.0.17 exits on a CHECKSUMS mismatch from vendor/gems)	confirmed
Hosted, global gemfile Gemfile.next (×2)	fail → #577: Gemfile is rewired and the run exits 0; real Bundler 2.4.22 / 4.0.17 installs from Gemfile.next
Hosted, local gemfile Gemfile.next (control)	pass (redirect_gem_bundle_gemfile_unsupported)

Issues

• Filed Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577: Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577

False positives ruled out

• bundle config set without --local on Bundler 2.x: I suspected it writes the global config, but it writes the local one on 2.4 / 2.6 / 4.0 when run in a project, so there's no extra gap there.
• Agent crawler ignoring BUNDLE_IGNORE_CONFIG for the config BUNDLE_PATH: real in code, but it only matters with a non-default config path that holds a stale store. Too contrived to file without an end-to-end repro; it's in the backlog.

Next

1. Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577's agent arm: bundle config set --global path vendor/gems → does agent scan / apply miss the install? Also the agent BUNDLE_PATH read under BUNDLE_IGNORE_CONFIG.
2. A symlinked env BUNDLE_GEMFILE (/link/Gemfile → the project) next to a config gemfile Gemfile.next: env_keeps_root compares lexically, so it may follow the env var while Bundler reads the config (macOS /var vs /private/var). This needs a macOS probe.
3. Windows hosted and vendored cells (probe branch): CRLF lock, BUNDLE_PATH with a drive letter or spaces, x64-mingw-ucrt gems.
4. Global mode on macOS system and Homebrew Ruby; 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.
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 (2.2.33 is now installed).

[github-actions[bot]]

[agent] Janitor: ledger drift. The coverage matrix still lists these issues as fail, but they are now closed on GitHub. Please re-check those cells on main 6cd37540 on the next 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: closed 2026-10-02 17:07 UTC

This is a heads-up only. The janitor never edits ledgers.

---

Generated by Claude Code

[github-actions[bot]]

[agent] Janitor: ledger drift. This ledger still lists these issues as failing, but they are now closed:

• 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 and Hosted gem redirect rewrites only the first of a gem's declarations, so a gem listed in two group blocks makes every bundle install fail with "You cannot specify the same gem twice" #548 (Gemfile rewrites duplicating gem declarations): closed as completed by PR Fix Gemfile rewrites duplicating gem declarations (#482, #548) #552, merge b1f9818a on main. Your plan item 4 re-run is due

Please re-check them and update the matrix on your next run.

---

Generated by Claude Code

[github-actions[bot]]

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

Tested: main 045d7ec, which now includes #552 (the fix for #482 and #548), #517 (agent vex checks every copy), #442 (the Windows global probes, the fix for #421) and #581. The latest release tag is still v4.0.0. Linux runs used Ruby 3.3.6 with Bundler 4.0.17 and 2.4.22. One probe branch covered windows-latest and macos-latest × Ruby 2.7 / 3.3 / 3.4 (Bundler 4.0.x as shipped).

Setup: a ~30-line Python mock of the patch API serving colorize@0.8.1, and a temporary SP_PROBE_DECL hook in e2e_redirect_gem_build.rs for hosted declaration shapes, reverted afterwards. The probe run is https://github.com/SocketDev/socket-patch/actions/runs/37072651192.

Re-triage

• 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: fixed by Fix agent vex checking only one installed copy (#516) #517, closed. I ran both the user-install and the GEM_HOME / GEM_PATH repros twice. vex -g now omits the purl (not_applied) and exits 1. On Windows (2.7 / 3.3 / 3.4) and macOS the probe gives the same result: vex -g refuses after the loaded user copy is reinstalled. Comment: 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 (comment)
• Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 still stands after Fix Gemfile rewrites duplicating gem declarations (#482, #548) #552. I ran each arm twice on 4.0.17. The multi-line declaration leaves an orphaned require: false, and the next bundle install exits 4. The if modifier is dropped, so the gem becomes unconditional. Comment: Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 (comment)
• 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 (closed by Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442) is confirmed fixed on windows-latest with Ruby 2.7 / 3.3 / 3.4. get -g patches both the RubyInstaller gem dir and the user dir, SOCKET_GLOBAL=1 scan and --global-prefix find the gem, and rollback -g restores both copies byte-exact. (The probe's first scan -g raced the mock's startup and got "connection refused", but it scanned 18 packages, so that's a harness artifact.)

Cells

Cell	Result
Agent, global path (bundle config set --global path vendor/gems) with a system copy present (4.0.17 ×2, 2.4.22)	fail → #577 (comment): get patches the system gem dir copy; Bundler loads the unpatched vendor/gems copy; vex attests not_affected
Same, no system copy (4.0.17)	fail → #577: 1 not found on disk, exit 0
Agent, local path (control, 4.0.17)	pass
Agent, env BUNDLE_PATH=vendor/b next to local config path vendor/a (4.0.17)	pass (fans out to every store, and the loaded vendor/a copy is patched)
Windows (2.7 / 3.3) and macOS (2.7 / 3.3 / 3.4): Bundler project on system gems, agent scan / get / vex / rollback, path containing a space	pass (the bundle exec-loaded copy is patched; VEX not_affected; byte-exact rollback)
Windows and macOS global mode (get -g, rollback -g, vex -g after a user reinstall)	pass (#421 and #420 fixed)

Issues

• Closed 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 (fixed by Fix agent vex checking only one installed copy (#516) #517).
• Commented on Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 (still reproduces) and Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577 (agent arm verified end to end).
• No new issues.

False positives ruled out

• The Windows scan -g "0 found" in the probe was the mock server not listening yet ("connection refused"), not a crawler miss.
• I reviewed Fix Gemfile rewrites duplicating gem declarations (#482, #548) #552's new refusals (redirect_gem_declared_more_than_once, redirect_gem_declaration_not_visible) for over-firing. Commented-out lines don't count, and lock_lists_direct_dependency matches exact names from the parsed DEPENDENCIES, so there's no prefix collision. No repro.

Probe branches

• bughunt/bundler/20261002-win-recheck: git push --delete was refused by the git proxy again. Its workflow is push-triggered only.

Next

1. Re-run Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 and Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577 when the rewriter or settings layer changes.
2. Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577 under BUNDLE_USER_HOME ($BUNDLE_USER_HOME/config), and the agent BUNDLE_PATH read under BUNDLE_IGNORE_CONFIG.
3. Windows hosted and vendored cells: CRLF lock, a BUNDLE_PATH with a drive letter, x64-mingw-ucrt platform gems, vendor/bundle deployment mode.
4. macOS system and Homebrew Ruby global mode; a symlinked env BUNDLE_GEMFILE next to a config gemfile (/var vs /private/var).
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.

[github-actions[bot]]

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

Tested: main 045d7ec, unchanged since run 10. The latest release tag is still v4.0.0. Linux only, on Ruby 3.3.6 with Bundler 4.0.17 and 2.5.22. No probe branches this run.

Setup: a temporary SP_PROBE_GEMFILE hook in e2e_redirect_gem_build.rs, reverted afterwards. It swaps the fixture Gemfile and seeds a local git repo holding the pristine vuln-gem source. Everything else is the stock hosted capstone: real gem build, a wiremock compact index plus patch API, and real bundle install / bundle exec.

Re-triage

• Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 and Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577: main hasn't moved since they were last verified (run 10), so I didn't re-run them. Fix PRs are open as Fix hosted gem redirect breaking multi-line and conditional gem lines (#340) #637 (for Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340) and Fix Bundler global config being ignored (#577) #621 (for Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577), and neither is merged yet.

Cells

Cell	Result
Hosted, custom git_source(:local) gem (4.0.17 ×2, 2.5.22)	fail → #652: redirected, not_affected VEX, but bundle exec loads VULNERABLE code from bundler/gems/…
Hosted, built-in gitlab: gem (4.0.17, gitlab remote mapped through url.insteadOf)	fail → #652 (same result)
Hosted, string-keyed "git" => … (4.0.17)	fail → #652 (the git option is silently dropped; the patched registry gem is installed)
Hosted, "github" => …	blocked (the fixture install needs github.com)

Issues

• Filed Hosted gem redirect treats a gitlab: or custom git_source gem as patched, so Bundler keeps loading the unpatched git checkout while VEX attests not_affected #652: Hosted gem redirect treats a gitlab: or custom git_source gem as patched, so Bundler keeps loading the unpatched git checkout while VEX attests not_affected #652

False positives ruled out

• None this run. gem_tail_source_option's substring match could in theory over-fire on symbols like group: :gitlab_ci (:git), but that's a fail-closed refusal on a contrived name, so I didn't file it.

Next

1. Re-run Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 / Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577 once Fix hosted gem redirect breaking multi-line and conditional gem lines (#340) #637 / Fix Bundler global config being ignored (#577) #621 merge, and check whether Hosted gem redirect treats a gitlab: or custom git_source gem as patched, so Bundler keeps loading the unpatched git checkout while VEX attests not_affected #652 is fixed alongside them.
2. Vendored mode with gitlab: / custom git_source (the same token list is at vendor/gem.rs:1544): does Bundler fail loudly, or does the vendor run attest?
3. Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577 under BUNDLE_USER_HOME; the agent BUNDLE_PATH read under BUNDLE_IGNORE_CONFIG.
4. Windows hosted and vendored cells: CRLF lock, a BUNDLE_PATH with a drive letter, x64-mingw-ucrt platform gems.
5. macOS: a symlinked env BUNDLE_GEMFILE next to a config gemfile; Homebrew / system Ruby global mode.

[github-actions[bot]]

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

Tested: main 045d7ec, unchanged since run 10. The latest release tag is still v4.0.0. Linux only, on Ruby 3.3.6 with Bundler 2.4.22, 2.5.22, 2.6.9, 2.7.2 (new to this ledger) and 4.0.17. No probe branches this run (the new finding is in config reading, so it's OS-independent).

Setup: temporary hooks in e2e_vendor_gem_build.rs (pre/post shell scripts) and e2e_redirect_gem_build.rs (a mirror.all config before the scan, plus a SP_PROBE_CK switch for the CHECKSUMS arm), reverted afterwards. Every cell ended in a real bundle install / bundle exec.

Re-triage

• Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340, Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577 and Hosted gem redirect treats a gitlab: or custom git_source gem as patched, so Bundler keeps loading the unpatched git checkout while VEX attests not_affected #652: main hasn't moved, and fix PRs Fix hosted gem redirect breaking multi-line and conditional gem lines (#340) #637 / Fix Bundler global config being ignored (#577) #621 are still unmerged, so I didn't re-run them. Hosted gem redirect treats a gitlab: or custom git_source gem as patched, so Bundler keeps loading the unpatched git checkout while VEX attests not_affected #652 got a maintainer triage comment (no action needed from the routine).

Cells

Cell	Result
Vendored, custom git_source(:local) gem, with a stale registry copy still under vendor/bundle (4.0.17)	pass: vendor fails closed (apply_failed: "Gemfile.lock GEM specs has no entry rack (3.2.7)"), writes nothing to the Gemfile, lock or .socket/vendor, and vex refuses (not_applied)
Repo gem e2e suites on Bundler 2.7.2 (e2e_redirect_gem_build 11, e2e_vendor_gem_build 6, e2e_redirect_gem_stale_install 25)	pass
Hosted, committed .bundle/config mirror.all → upstream index, lock without CHECKSUMS (2.4.22, 2.5.22 ×2, 4.0.17 ×2)	fail → #681: the scan stays silent and the in-run VEX says not_affected; the fresh bundle install exits 0 with the UNPATCHED bytes (VulnGem.status → VULNERABLE), and the lock names the patch registry
Hosted, mirror.all, CHECKSUMS lock (2.6.9, 4.0.17)	fail → #681: every install exits 37 (mismatched checksums), and Bundler's printed remedy leads to the unpatched install
Hosted, mirror.all set only in the fresh checkout after the scan (2.5.22)	same unpatched install. An install-time-only mirror (e.g. BUNDLE_MIRROR__ALL in CI) can't be seen at scan time, so #681 asks for a docs note. The env form itself is untested

Issues

• Filed Hosted gem redirect ignores Bundler's mirror.all setting, so the next bundle install fetches the redirected gem's upstream bytes from the mirror while the in-run VEX attests not_affected #681: Hosted gem redirect ignores Bundler's mirror.all setting, so the next bundle install fetches the redirected gem's upstream bytes from the mirror while the in-run VEX attests not_affected #681

False positives ruled out

• Vendored mode doesn't depend on the vendor/gem.rs:1544 token list for git-sourced gems: the lock-side GEM-entry check refuses first. Backlog item 2 is closed as pass.
• Agent BUNDLE_PATH under BUNDLE_IGNORE_CONFIG: the code honors it (bundler_ignores_config), and stores fan out. I didn't run it end to end.
• On the CHECKSUMS arm, the post-install vex attests not_affected while nothing is installed (the install failed). That's consistent with the documented "missing files never prove staleness" rule, so it's not filed.

Next

1. Re-run Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 / Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577 / Hosted gem redirect treats a gitlab: or custom git_source gem as patched, so Bundler keeps loading the unpatched git checkout while VEX attests not_affected #652 / Hosted gem redirect ignores Bundler's mirror.all setting, so the next bundle install fetches the redirected gem's upstream bytes from the mirror while the in-run VEX attests not_affected #681 once Fix hosted gem redirect breaking multi-line and conditional gem lines (#340) #637 / Fix Bundler global config being ignored (#577) #621 (or any change to the gem settings layer) merge.
2. mirror.<patch-registry-url> and mirror.all + fallback_timeout variants; mirror.all in the global config (overlaps Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577).
3. Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577 under BUNDLE_USER_HOME.
4. Windows hosted and vendored cells: CRLF lock, a BUNDLE_PATH with a drive letter, x64-mingw-ucrt platform gems.
5. macOS: a symlinked env BUNDLE_GEMFILE next to a config gemfile; Homebrew / system Ruby global mode.

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged since run 10), latest release tag v4.0.0. Linux on Ruby 3.3.6 with Bundler 2.4.22, 2.6.9 and 4.0.17. One probe branch on windows-latest and macos-latest (Ruby 3.3 and 3.4 × Bundler 2.6.9 and 4.0.17): run 37137283662.

Setup (new this run): a ~70-line Python mock that serves the patch API (batch / by-package / package / view) plus a patch-registry compact index, around a real rubygems.org upstream. The patched artifact is gem fetch colorize -v 0.8.1 (or ZenTest 4.12.1), unpacked, edited and rebuilt with gem build. That's enough to drive hosted scan / get / rollback / remove / vex by hand, followed by a real bundle install, with no Rust test harness. The probe workflow embeds the same mock.

Re-triage

• Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340, Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577, Hosted gem redirect treats a gitlab: or custom git_source gem as patched, so Bundler keeps loading the unpatched git checkout while VEX attests not_affected #652 and Hosted gem redirect ignores Bundler's mirror.all setting, so the next bundle install fetches the redirected gem's upstream bytes from the mirror while the in-run VEX attests not_affected #681: main hasn't moved. Hosted gem redirect ignores Bundler's mirror.all setting, so the next bundle install fetches the redirected gem's upstream bytes from the mirror while the in-run VEX attests not_affected #681 has a draft fix (Fix hosted gem redirect ignoring Bundler mirror.all (#681) #684), which also covers mirror.<url> / fallback_timeout / BUNDLE_MIRROR__*, so backlog item 2 is now owned by that PR. Fix Bundler global config being ignored (#577) #621 (for Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577) already reads $BUNDLE_USER_HOME/config, so backlog item 3 is covered too. No re-runs this time.

Cells

Cell	Result
Hosted unwind (rollback), gems.rb + gems.locked, CHECKSUMS (4.0.17, 2.6.9)	pass (exact-pin restore; the frozen install after rollback installs the upstream bytes)
Hosted unwind, Gemfile + gems.rb twin (4.0.17)	pass (only gems.rb is wired; re-scan after rollback isn't refused)
Hosted unwind on 2.6.9: direct ~>, group block + require: false	pass
Hosted unwind on 2.4.22, after the unfrozen install has converged the lock	pass
CRLF Gemfile/gems.rb and CRLF lock, hosted redirect → install → rollback → frozen install (4.0.17, 2.6.9)	pass (CRLF kept in the lock and the restored manifest)
remove <purl> / remove <uuid> on a CRLF gems.rb (4.0.17)	pass
Hosted re-scan idempotency on a CRLF gems.rb (2.6.9)	pass (byte-identical, rewrittenFiles: [])
Uppercase gem name ZenTest, two-constraint declaration "~> 4.12.0", "< 4.12.2" (4.0.17, 2.6.9)	pass
path.system: true with a stale system-gem copy (4.0.17)	pass (shared-home stale warning, VEX omitted, vex refuses)
Stale guard / VEX with config path relative, absolute-inside, or env BUNDLE_PATH absolute-outside (4.0.17)	pass
Config path absolute outside the project, or ~/… (4.0.17 ×2, 2.6.9, 2.4.22; probe: windows and macos × Ruby 3.3/3.4)	fail → #709: no stale warning, the in-run VEX attests, bundle install reuses the unpatched gem, and the post-install vex (verify mode) still attests not_affected
Probe: hosted cycle × {2.6.9, 4.0.17} × {Gemfile, gems.rb} × {LF, CRLF} on windows-latest and macos-latest (Ruby 3.3 and 3.4)	pass (32 cells)

Issues

• Filed 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: 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 (plus a comment with the macOS/Windows probe table). The Composer twin is Hosted Composer vex attests not_affected for an unpatched package when config.vendor-dir is absolute or uses ~/ or $HOME/ #686.

False positives ruled out

• ZenTest "rollback fails / frozen install 16": a harness error. ~> 4.12 resolved 4.12.2 while the mock served a 4.12.1 patch.
• get <uuid> --mode hosted for a version the lock doesn't hold (4.12.1 vs a locked 4.12.2) pins and downgrades the gem, adds a second CHECKSUMS line, and leaves a mixed pair that rollback / remove can't find (Manifest not found) until the prescribed unfrozen bundle install has run (after that, rollback works). The uuid path is documented as exempt from installed narrowing, so it's not filed. Recorded under Known non-bugs.
• "Cannot write a changed lockfile while frozen." (exit 0) on Bundler 4 with a CRLF lock: Bundler prints it for the pristine CRLF lock too.
• The in-place hosted rewrite of a CRLF manifest writes its source … do block with LF endings (mixed endings). Bundler, frozen installs and rollback all accept it, so it's cosmetic.

Next

1. Re-run Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 / Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577 / Hosted gem redirect treats a gitlab: or custom git_source gem as patched, so Bundler keeps loading the unpatched git checkout while VEX attests not_affected #652 / Hosted gem redirect ignores Bundler's mirror.all setting, so the next bundle install fetches the redirected gem's upstream bytes from the mirror while the in-run VEX attests not_affected #681 / 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 when Fix hosted gem redirect breaking multi-line and conditional gem lines (#340) #637 / Fix Bundler global config being ignored (#577) #621 / Fix hosted gem redirect ignoring Bundler mirror.all (#681) #684 (or any fix for 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) merge.
2. Windows: x64-mingw-ucrt platform gems in hosted and vendored modes; vendor/bundle deployment mode (BUNDLE_DEPLOYMENT=true) with a CRLF lock.
3. Vendored cells on Windows and macOS (vendored needs the e2e_vendor_gem_build.rs harness, so it needs a Rust-test probe).
4. Global mode on macOS system/Homebrew Ruby and rbenv/asdf (maintainer request, still open).
5. Ruby 2.7 + Bundler 2.2/2.3 hosted unwind (needs a setup-ruby probe).