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-07 (run 27), main 9c43dfc (includes #637, #621, #797, #805, #849, #731, #750, #712), latest release tag v4.0.0. Newest Bundler tested: 4.1.0.beta1 (repo gem e2e suites pass).

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	blocked (1.17 needs Ruby ≤ 3.1)	untested	untested	untested	n/a	untested	untested	untested	untested	untested	untested	untested
Linux	3.3.6	2.2–2.4	untested	fixed #340 (#637)	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	fixed #340 (#637)	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	fixed #577 (#621)	fixed #577 (#621)	fixed #577 (#621)	fixed #577 (#621)
2.4.22	fixed #577 (#621)	fixed #577 (#621)	fixed #577 (#621)	fixed #577 (#621)

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	fixed #652 (#731)	fixed #652 (#731)	fixed #652 (#731)	untested (needs network)
2.5.22	fixed #652 (#731)	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	fixed #709 (#712)
Linux	3.3.6	2.6.9	pass	untested	pass	untested	pass	pass	fixed #709 (#712)
Linux	3.3.6	2.4.22	converged-lock unwind pass	untested	untested	untested	untested	untested	fixed #709 (#712)
windows-latest	3.3 / 3.4	2.6.9 / 4.0.17	pass (Gemfile too)	untested	pass	untested	untested	untested	fixed #709 (#712; was 4.0.17, D:/…)
macos-latest	3.3 / 3.4	2.6.9 / 4.0.17	pass (Gemfile too)	untested	pass	untested	untested	untested	fixed #709 (#712)

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

Run 14: stale-install warning flavor and BUNDLE_IGNORE_CONFIG (Linux, Ruby 3.3.6)

Bundler	Hosted stale warning, --cwd omitted / .	Hosted stale warning, absolute or ../proj --cwd	Hosted BUNDLE_IGNORE_CONFIG + config path vendor/bundle	Agent + vex, same shape
4.0.17	fail #729 (also on the v4.0.0 release)	pass	documented heuristic (warns about the wrong copy)	documented heuristic (false VEX; see Known non-bugs)
2.6.9	fail #729	pass	untested	untested
2.4.22	fail #729	pass	untested	untested

Run 15: Bundler 1.17 / 2.2 / 2.3 hosted, custom lockfiles, odd files

OS	Ruby	Bundler	Hosted Gemfile only	Hosted gems.rb only	Hosted Gemfile + gems.rb twin	Hosted cycle incl. rollback (Linux)	Custom lock: config lockfile / env BUNDLE_LOCKFILE	Stale twin Gemfile.lock → pre-install vex
ubuntu-latest	2.7 / 3.1	1.17.3	pass	pass	fail #751	untested	n/a	untested
windows-latest	2.7	1.17.3	pass	pass	fail #751	untested	n/a	untested
ubuntu-latest / windows-latest	2.7 / 3.1	2.2.33	pass	pass	pass	untested	n/a	untested
Linux	3.3.6	2.2.33 / 2.3.27	pass	pass	untested	pass	n/a	untested
Linux	3.3.6	2.6.9	—	—	—	—	n/a	fixed #736 (#750)
Linux	3.3.6	4.0.17	—	—	—	—	fail #749	fixed #736 (#750)

Also on 4.0.17: BOM Gemfile passes; symlinked Gemfile / lock is refused (pass); --dry-run writes nothing (pass).

Run 16: mode takeovers (Linux, Ruby 3.3.6; OS-independent logic)

Bundler	H→V scan --mode vendored, group decl	H→V get --mode vendored, group decl	H→V vendor eject, group decl	H→V top-level decl	V→H scan --mode hosted	V→H remedy (remove → hosted)
4.0.17	fail #775	fail #775	pass (rolled back)	blocked (mock grant conflict)	refused (fail-safe, see Known non-bugs)	pass
2.6.9	fail #775	untested	untested	untested	untested	untested
2.4.22	fail #775	untested	untested	untested	untested	untested

Run 17: vendored repair, custom lock, standalone installs (Linux, Ruby 3.3.6)

Bundler	Vendored repair (corrupt / missing file / missing dir / extra file)	Vendored lockfile custom.lock	Agent apply + vex on bundle install --standalone
4.0.17	pass	pass (fails closed)	fixed #796 (#797)
2.7.2 / 2.6.9 / 2.5.22 / 2.4.22	untested	n/a	pass

Run 18: multi-gem hosted lifecycle and takeover (Linux, Ruby 3.3.6, real rubygems.org upstream)

Bundler	Hosted: 3 gems one scan (frozen fresh install)	Hosted: incremental + byte-identical re-run	Hosted: rollback 1 of 3, then all	H→V takeover, 1 gem	H→V takeover, 3 gems	H→V takeover, mixed no-CHECKSUMS pair
4.0.17	pass	pass	pass	pass	fixed #779 (#805)	n/a
2.6.9	pass	untested	pass	untested	untested	untested
2.4.22	pass (after the documented unfrozen install)	untested	untested	untested	fixed #779 (#805)	fails closed (documented mixed state)

Run 19: single-line declaration shapes, deployment config, 2.6.9 suites (Linux, Ruby 3.3.6, real rubygems.org upstream)

Bundler	Repo gem e2e suites	Hosted: trailing # comment	Hosted: gem(...)	Hosted: y; gem "x" (patched 2nd)	Hosted: gem "x"; gem "y" (patched 1st)	Hosted: gem "x", opt; gem "y"	Vendored: gem "x"; gem "y"	Agent: BUNDLE_DEPLOYMENT config	Agent vex: stale ruby/<old ABI> scope
4.0.17	pass	pass (comment dropped)	pass	pass (refused)	fail #826 (also gems.rb, and PR #637)	fail #826	fail #826	pass	pass (refuses)
2.6.9	pass (21 + 16 + 25)	untested	untested	untested	fail #826	untested	untested	untested	untested
2.4.22	untested	untested	untested	untested	fail #826	untested	fail #826	untested	untested

Run 20 (Linux, Ruby 3.3.6, real rubygems.org upstream; plus a macOS/Windows global-mode probe)

Bundler	Hosted: gem "x", "1"; # c / # …; gem "y" in a comment	Hosted: one-line group … do gem … end / gem %q(x)	Hosted: *V / ENV.fetch(…) / tab / :require => / platforms: [...] / group: [...] / "x" ,	Hosted rollback of those shapes	Hosted: decl duplicated in =begin/heredoc/__END__	Hosted: gem "x-y", path: next to the patched gem "x"	Hosted: 3 concurrent scans	Hosted: env BUNDLE_GEMFILE (6 spellings)	Vendored: *V / ENV.fetch(…) / CONST, require: false
4.0.17	fail #826 (; now refused since #637, comment)	pass (refused: redirect_gem_declaration_not_visible)	pass	pass (exact pin + kept args, documented)	pass (refused: declared_more_than_once)	pass	pass (apply.lock)	pass	fixed #847 (#849)
2.6.9	fail #826 (; refused)	untested	pass	untested	untested	untested	untested	untested	untested
2.4.22	fail #826 (; refused)	untested	pass (after the documented unfrozen install)	untested	untested	untested	untested	untested	fixed #847 (#849)

Run 21 (main 0d302dc; Linux Ruby 3.3.6 unless noted; real rubygems.org upstream)

Cell	4.0.22	4.0.17	2.6.9	2.4.22
Repo gem e2e suites (redirect 25 / vendor 18 / stale 29)	pass	—	—	—
Hosted single-line CHECKSUMS cycle, Gemfile and gems.rb	pass	pass	—	—
Hosted transitive (via path: gem) / group block / CRLF Gemfile, then rollback → frozen install	pass (lock byte-restored)	—	—	—
Hosted, lock PLATFORMS = x86_64-linux only	pass	—	—	—
Hosted, 9 one-line shapes after #637 (gem(...), trailing # … if …, 2 constraints, %i[], "#{…}", !=, !true, group: + require:)	—	pass	—	—
Hosted gem "x", "1"; / gem "x", "1"; # c	—	fail #826 (refused since #637)	fail #826	fail #826
Hosted rollback after a user bundle update of another gem	—	pass (the other gem's update kept)	—	—
Hosted stale guard, --standalone install (./bundle)	—	pass (warns, VEX withheld; remedy wording, see Known non-bugs)	—	—
Hosted stale guard, system-gems install (no path)	—	pass	—	—
Vendored CONST / *%w[] / *EXTRA / **OPTS / two constants (after #849)	—	pass	—	—
Vendored transitive gem from the lock's 2nd GEM section (after #805)	—	pass	—	—
Agent: locked default gem (uri 0.13.1), system gems	—	pass (Bundler installs a regular copy, which is patched)	—	—
Windows (RubyInstaller 3.4.9) Bundler 4.0.22 agent cycle, path with a space	pass	—	—	—

Run 22 (main 9c43dfc; Linux Ruby 3.3.6 unless noted; real rubygems.org upstream)

Cell	4.0.22	2.7.2	2.6.9	2.4.22
Hosted CHECKSUMS cycle + rollback → frozen install	pass	pass	pass	documented (no CHECKSUMS)
Hosted 4-platform lock + CHECKSUMS (pure-ruby gem) + rollback	pass	—	—	—
Hosted gems.rb + stale Gemfile.lock twin (#736 fix) + rollback	pass	—	—	—
Hosted gem in git … do / path … do / git: (#652 fix)	pass (refused via lock section)	—	—	—
Hosted BUNDLE_GEMFILE = project Gemfile via symlinked dir (env / --cwd / config); vex / rollback	fail #896 (also macos-latest /tmp, ubuntu-latest)	—	—	—
Hosted gem "x", "1"; gem "y" (bare 2nd gem)	fail #826 (new shape; PR #875 passes)	—	—	—

Run 23 (main 9c43dfc; Linux Ruby 3.3.6; agent mode, hand-written manifest + apply --offline)

Cell	4.0.22	2.6.9	2.4.22
Local path.system: true + leftover vendor/bundle: apply / vex	fail #915	fail #915	fail #915
Env BUNDLE_PATH__SYSTEM=true + leftover vendor/bundle	fail #915	fail #915	fail #915
Local path.system: true, no leftover (control)	pass	pass	untested

Run 24 (main 9c43dfc; Linux Ruby 3.3.6; Bundler 4.1.0.beta1)

Cell	4.1.0.beta1
Repo gem e2e suites (redirect 26 / vendor 22 / stale 32)	pass
Agent apply --offline + vex, unquoted BUNDLE_PATH: vendor/my bundle (4.1 config spelling)	pass
Config readers on main vs 4.1 .bundle/config (BUNDLE_PATH / GEMFILE / CACHE_PATH / PATH__SYSTEM)	pass
URL-scoped mirror.<patch source> quoted key vs PR #684	gap in the PR (comment on #681)

Run 25 (main 9c43dfc; Linux Ruby 3.3.6; agent apply --offline + vex with a hand-written manifest, real bundle install / bundle exec)

Cell	4.1.0.beta1	4.0.22	2.6.9	2.4.22
Agent: .bundle/config BUNDLE_PATH: .gems # comment (system copy also present)	fail #951	fail #951 (×2)	fail #951	fail #951
Agent: BUNDLE_PATH: .gems control	—	pass	pass	pass
Hosted stale guard: BUNDLE_CACHE_PATH: vendor/gems # comment + stale archive (e2e harness case)	—	fail #951 (2/2, OS/version-independent)	—	—
Agent: env BUNDLE_GEMFILE=gemfiles/alt.gemfile, path vendor/bundle in gemfiles/.bundle/config	—	fail #952 (×2)	fail #952	—
Agent: env BUNDLE_GEMFILE=gemfiles/alt.gemfile + env BUNDLE_PATH=vendor/bundle (relative)	—	fail #952	fail #952	—

Run 26 (main 9c43dfc; Linux Ruby 3.3.6; agent apply --offline + vex, real bundle install / bundle exec)

Cell	4.0.22	2.6.9	2.5.22
Agent: Bundler's .bundle default path (local simulate_version 5 on 4.x / default_install_uses_path true on 2.x)	fail #967 (×2)	fail #967 (×2)	fail #967
Same, env spelling (BUNDLE_SIMULATE_VERSION=5 / BUNDLE_DEFAULT_INSTALL_USES_PATH=true)	fail #967	fail #967	—
Control: no setting (system install)	pass	—	—
PR #953 head 52542db on the #951 agent shape	pass (fixes #951)	—	—

Run 27 (main 9c43dfc; Linux Ruby 3.3.6; gemspec library projects)

Cell	4.0.22	4.0.0 / 4.0.10 / 4.0.17	2.7.2	2.6.9
Hosted: gemspec dev dep only (no Gemfile line)	pass (refused: redirect_gem_declaration_not_visible)	—	—	—
Hosted, CHECKSUMS lock: gemspec dev dep + Gemfile gem line → fresh frozen install	fail #985 (×3)	fail #985	fail #985	pass
Hosted: gemspec runtime dep + Gemfile gem line → fresh frozen install	pass	—	—	—
Vendored: gemspec dev dep + Gemfile gem line → fresh frozen install	fail #985 (×2)	—	fail #985	pass

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-14 / macos-15 system Ruby 2.6 (--user-install)	2.6 / bundled	pass	untested	untested	pass	pass	pass	n/a	n/a
macos-14 / macos-15 system Ruby 2.6, root-owned /Library/Ruby/Gems	2.6	pass	n/a	untested	pass (exit 1 partial_failure, nothing written)	n/a	pass (refuses)	pass	pass (partial_failure, exit 1)
macos-14 / macos-15 Homebrew Ruby 4.0.6	4.0.6 / bundled	pass	pass (-g inside a project leaves vendor/bundle alone)	untested	pass	pass	pass	pass	untested
macOS / Windows / Linux unicode + space --global-prefix	3.3	pass	n/a	n/a	pass	pass	pass	pass	n/a
windows-latest -g inside a Bundler project	3.3.12	pass	pass	untested	pass	pass	untested	untested	untested
Linux, chruby layout (GEM_HOME=~/.gem/ruby/<v>)	3.3.6	pass	n/a	untested	pass	pass	pass	untested	n/a
Linux, rvm layout (@app + @global gemsets, incl. a shadowing gemset copy)	3.3.6	pass	n/a	untested	pass (patches both)	pass (both)	pass (refuses while the shadowing copy is unpatched)	untested	n/a
asdf	any	untested (same layout as the rbenv rows)	untested	untested	untested	untested	untested	untested	untested
windows-latest, deny-write ACE on the gem dir	3.4.9	pass	n/a	n/a	pass (exit 1 partial_failure, nothing written)	n/a	pass (refuses)	n/a	pass (fails closed; the ACE also blocks Ruby's own load)
macos-14 system Ruby 2.6 / Bundler 1.17, -g inside a project	2.6	pass	pass (project vendor/bundle untouched)	untested	pass	pass	pass	n/a	n/a

Backlog

1. Re-run 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 stale-install warning calls the project's own vendor/bundle a "shared gem home" when --cwd is left at its default (or relative), so it gives the wrong remedy and drops the committed cache archive from the delete list #729 / Hosted gem redirect ignores Bundler 4's custom lockfile (lockfile setting / BUNDLE_LOCKFILE), so it never pins the lock Bundler uses and frozen installs fail with no warning #749 / Hosted gem redirect wires gems.rb in a Gemfile/gems.rb twin locked by Bundler 1.17, which loads Gemfile, so the install stays unpatched while the in-run VEX attests it #751 / Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775 / Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826 / Gem BUNDLE_GEMFILE check compares paths lexically, so a symlinked spelling of the project's own Gemfile (e.g. macOS /tmp/app/Gemfile) is refused, and vex / rollback reject the hosted patch Bundler is loading #896 / Gem crawler ignores Bundler's path.system: true when a leftover vendor/bundle exists, so agent apply patches the unused copy and vex attests not_affected while Bundler loads the unpatched system gem #915 / Gem .bundle/config reader keeps a trailing # comment in the value, so a commented BUNDLE_PATH is missed, agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched project copy #951 / Gem agent crawl ignores that BUNDLE_GEMFILE=gemfiles/x.gemfile moves Bundler.root, so a relative bundle path resolves to the wrong dir, apply patches the system copy and vex attests not_affected while Bundler loads the unpatched gemfiles/vendor/bundle copy #952 / Gem crawler ignores Bundler's .bundle default install path (default_install_uses_path on 2.x, simulate_version 5 on 4.x), so agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched .bundle/ruby/<abi> copy #967 / Gem hosted and vendored lock pins ignore a gemspec development dependency on the same gem, so on Bundler 2.7+ the rewritten Gemfile.lock fails every frozen install ((= v)! vs Bundler's merged (>= 0, = v)!) #985 when fixes merge (open PRs Fix hosted gem redirect ignoring Bundler mirror.all (#681) #684, Fix gem pair model ignoring custom lockfile and Bundler 1 twins (#749, #751) #768, Fix gem takeover un-hosting a grouped gem (#775) #776, Fix gem rewrite deleting a ;-joined declaration (#826) #875, Fix gem crawl ignoring Bundler path.system (#915) #916, Fix .bundle/config values keeping a trailing # comment (#951) #953). Fix gem rewrite deleting a ;-joined declaration (#826) #875 head 5b9953d3 already passes every Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826 shape. Fix .bundle/config values keeping a trailing # comment (#951) #953 head 52542db fixes the Gem .bundle/config reader keeps a trailing # comment in the value, so a commented BUNDLE_PATH is missed, agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched project copy #951 agent shape. Fix gem crawl ignoring Bundler path.system (#915) #916 covers the to_bool spellings and the hosted stale guard. Fix gem takeover un-hosting a grouped gem (#775) #776 covers every vendored-refused block shape. Fix hosted gem redirect ignoring Bundler mirror.all (#681) #684 head 0e1e6cda misses 4.1's quoted URL-scoped mirror keys.
2. Gem hosted and vendored lock pins ignore a gemspec development dependency on the same gem, so on Bundler 2.7+ the rewritten Gemfile.lock fails every frozen install ((= v)! vs Bundler's merged (>= 0, = v)!) #985 neighbours: hosted rollback on the gemspec dev-dep shape (the exact-pin restore may then fail frozen installs), get <uuid> --mode hosted, and H→V takeover on that shape.
3. Gem crawler ignores Bundler's .bundle default install path (default_install_uses_path on 2.x, simulate_version 5 on 4.x), so agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched .bundle/ruby/<abi> copy #967 neighbours: the hosted stale guard with a stale .bundle/ruby/<abi> copy; rollback under simulate_version 5; other Bundler 5-mode defaults socket-patch models. When Bundler 5 ships, .bundle becomes the plain default, so re-run everything there.
4. Gem agent crawl ignores that BUNDLE_GEMFILE=gemfiles/x.gemfile moves Bundler.root, so a relative bundle path resolves to the wrong dir, apply patches the system copy and vex attests not_affected while Bundler loads the unpatched gemfiles/vendor/bundle copy #952 neighbours: under BUNDLE_GEMFILE=gemfiles/x.gemfile, check cache_path in gemfiles/.bundle/config for the hosted stale guard and vex, and the env BUNDLE_APP_CONFIG relative to the moved root.
5. More .bundle/config parser divergences from Bundler's YAMLSerializer: KEY:"v" with no space, a value with trailing spaces after the closing quote, # inside a quoted value. All contrived, so low priority.
6. RubyGems 4.1 + Bundler 4.1 content-addressed installs (gems/<name>-<ver>-<hex8>): revisit when a gem is published that way.
7. Windows x64-mingw-ucrt platform gems in hosted and vendored modes; vendored cells and repair on Windows and macOS.
8. Bundler 1.17 hosted unwind (Ruby ≤ 3.1 probe); rollback / remove on a custom-lock project.

Known non-bugs

• patches-api.socket.dev / api.socket.dev are blocked from the sandbox. Use a local mock API (--api-url, --api-token fake --org org). A ~60-line Python mock serving /v0/orgs/org/patches/{batch,view/<uuid>,by-package/…} with blobContent is enough for agent and -g flows; for hosted, use a hold-open copy of e2e_redirect_gem_build.rs.
• v5 vendoring downloads service artifacts only (--vendor-source build is gone). To drive vendored cells, copy e2e_vendor_gem_build.rs (its prebuilt_common fixture serves the artifact) rather than calling the CLI by hand: vendor --offline without a prestaged artifact fails with vendor_service_offline_conflict, which is expected.
• --global-prefix takes the package-leaf dir (<gem home>/gems), like node_modules / site-packages for the other ecosystems. Pointing it at the gem home itself scans 0 packages; that's the convention, not a bug.
• -g agent runs keep their manifest at <cwd>/.socket/manifest.json, and rollback -g removes the entry. vex -g then needs a fresh get -g plus --product (no project to auto-detect from).
• A git-sourced gem (bundler/gems/<name>-<sha>) isn't crawled in agent mode. Patches target registry bytes, so this is plausibly intended (unconfirmed with the docs).
• A gems.rb-only project can't vendor. It's documented, and the refusal is no Gemfile at …/Gemfile.
• A CHECKSUMS-less lock gets redirect_gem_no_checksums_section + redirect_gem_frozen_install and needs one unfrozen bundle install. Documented.
• A platform-resolved gem (-x86_64-linux) on a CHECKSUMS-less lock is redirected, and the next install switches to the patched ruby-platform gem. It's intended. With CHECKSUMS it fails closed (redirect_gem_platform_unsupported).
• bundle install --deployment exits 15 on Bundler 4 (the flag was removed). Use BUNDLE_DEPLOYMENT=true / --frozen.
• Moving a gem into a hosted source block inside a group … do block dedents it. Cosmetic.
• Bundler 1.17 doesn't run on Ruby ≥ 3.2 (String#untaint was removed). Use Ruby 2.7 / 3.1 (setup-ruby probe) for 1.x cells.
• 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.
• BUNDLE_IGNORE_CONFIG is not honored when the crawler reads .bundle/config path (it is for cache_path/gemfile). It's harmless on its own: a non-default config path still gets the gem env homes appended. The only harmful shape is a populated vendor/bundle that bundler doesn't use (agent patches it, vex attests while the system copy loads), and that's the documented "vendor/bundle holds stores, so no gem env homes" rule; a leftover vendor/bundle with no config does the same (run 14).
• To bisect, the published binary is at npm pack @socketsecurity/socket-patch-linux-x64-gnu@<ver> (package/socket-patch). v4 needs --mode hosted explicitly.
• bughunt/bundler/20261004-bundler1 is also left behind (git push --delete hangs up); its workflow is push-triggered only.
• With a Gemfile lockfile "x.lock" DSL, Bundler 4.0.17 itself refuses frozen/deployment installs ("requires a lockfile"), even with no socket-patch involvement.
• Lexical starts_with(cwd) sweep (run 15): the only gem-path hits are scan/hosted.rs:218 / :423 (Hosted gem stale-install warning calls the project's own vendor/bundle a "shared gem home" when --cwd is left at its default (or relative), so it gives the wrong remedy and drops the committed cache archive from the delete list #729). resolve_config_bundle_path absolutizes before comparing.
• Vendored → hosted takeover for a gem is refused with redirect_gem_source_option ("carries path: pointing into .socket/vendor … un-vendor this gem first"), exit 0, nothing written; the gem stays vendored-patched. The remedy (remove <purl>, then scan --mode hosted) works (run 16). It's fail-safe, so it's not filed even though the contract says takeovers work both ways.
• Vendored artifacts by hand (run 16): build a scratch test binary in crates/socket-patch-cli/tests/ that starts prebuilt_common::Server::project_with_env(<root>), writes its URI, and blocks; export SOCKET_VENDOR_URL. The root needs .socket/manifest.json + blobs + an unpatched install. Don't let another mock answer /patches/package (→ vendor_prebuilt_integrity_mismatch). Delete the scratch file afterwards.
• When copying a project to a "fresh checkout" via git, gitignore vendor/bundle/ first, or the patched install travels along (run 16 false alarm).
• Vendored repair doesn't restore Gemfile / lock wiring the user reverted. It reports success with no events, matching the docs ("preserves project wiring"); vex reports vendor_unwired (run 17).
• Multi-source locks (a private source … do writes its own GEM section): vendored is tracked by Vendored gem refuses a gem whose spec is not in the lock's first GEM section #779 / Read Gemfile.lock sections and DEPENDENCIES entries through formats::gem in hosted and vendored modes #780 (arch audit). Hosted redirects a gem from any GEM remote; mirrors are legitimate, so that's policy, not a bug.
• In helper scripts, never pkill -f / pgrep -f a name that also appears in the same shell command; it kills the agent's own shell (exit 144).
• Hosted → vendored takeover by hand (run 18): --patch-server-url <api mock> is needed so vendored mode recognizes the loopback patch-registry wiring, but it also rewrites artifact download hosts. Have the API mock proxy /artifacts/* (every non-/v0, non-/patch-registry GET) to the prebuilt server, and export SOCKET_VENDOR_URL=<prebuilt uri> as well.
• Hosted → vendored takeover on a mixed (no-CHECKSUMS, not yet re-installed) pair fails closed with gemfile_declaration_not_editable and writes nothing. The takeover can't see the unconverged hosted wiring, consistent with the documented mixed-state limits (run 18).
• When verifying several fix PRs, build each into its own CARGO_TARGET_DIR; reusing one silently tests the wrong head (run 18 near-miss).
• scan defaults to hosted mode in v5. An agent probe must pass --mode agent, or it fails with "Failed to resolve patch references" against a mock with no /patches/package (run 19).
• cargo test --test <t> -- --ignored --include-ignored prints no results (conflicting flags). Use --include-ignored alone (run 19).
• A hosted rewrite drops a trailing # comment on the patched gem's line. That's cosmetic; vendored does the same and keeps the original in its ledger.
• Agent vex refuses not_applied when any crawled copy (e.g. a leftover vendor/bundle/ruby/<old ABI> scope) is unpatched, even if the live scope is patched. It's fail-safe, so it's not filed (run 19).
• Run-19 mocks (mock.py agent, mock2.py hosted grant + patch-registry compact index, with ETags) are described in the run-19 entry. Each is about 50 lines, and a rebuilt marker gem (gem unpack → append → gem spec --ruby → gem build) is enough for full hosted cycles against real rubygems.org.
• get --json on an apply that fails (e.g. a root-owned gem dir) reports status: partial_failure, exit 1, applied: 0 and failed: 0: failed counts download failures only (get.rs:2492-2506), and the reason ("Permission denied (os error 13)") only reaches the human output. That's by design and not specific to gems, so it's not filed (run 20).
• A hosted declaration whose name is also mentioned inside =begin/=end, a heredoc or after __END__ is refused with redirect_gem_declared_more_than_once (nothing written). It's fail-closed, so it's not filed (run 20).
• Hosted rollback of gem "x", *V / gem "x", ENV.fetch(…) leaves gem "x", "<ver>", *V: the documented exact-pin restore plus the kept argument. The lock is byte-restored and frozen installs pass (run 20).
• bughunt/bundler/20261005-global-macos is left behind if git push --delete fails; its workflow is push-triggered only.
• Bundler 4.0.19+ fails a frozen install with exit 16 ("Your lockfile needs to be updated, but it can't be because frozen mode is set") for any CRLF lock, including a pristine one with no socket-patch involvement (4.0.17 only printed "Cannot write a changed lockfile while frozen." and exited 0). It's Bundler's own change (rubygems #9750), so CRLF-lock cells on 4.0.19+ can't use frozen installs.
• Bundler 4.0.18+ cooldown ignores versions with no created_at and never retracts a locked version, so it doesn't affect a hosted exact pin (checked in the 4.0.22 source, run 21).
• The hosted stale-install remedy for a Bundler 4 --standalone project says "run bundle install". Plain bundle install then installs into system gems, and the standalone app fails loudly (LoadError) until bundle install --standalone is re-run, which yields the patched copy. That's a remedy wording nit with no silent unpatching, so it's not filed (run 21).
• Hosted rollback can leave one extra blank line after the source line in the Gemfile. That's cosmetic; the lock is byte-restored (run 21).
• A Bundler project that locks a Ruby default gem (e.g. uri 0.13.1 on Ruby 3.3.6) gets a regular installed copy from Bundler 4, so the crawler sees and patches it. Default gems only exist as stdlib files (gems/<name>-<ver>/ empty) outside Bundler (run 21). Clean up after agent tests on system gems: they patch the real system copy.
• In the Windows probe's MSYS bash, icacls needs MSYS2_ARG_CONV_EXCL="*", or /deny is converted into a path. A deny-write ACE (OI)(CI)(W,D,DC) on the gem dir also makes Ruby's require fail, so it only tests fail-closed behavior. Don't check writability by appending to the gem file (echo >>): it changes the hash and breaks the cell (run 21).
• bughunt/bundler/20261005-win-ro is also left behind (git push --delete hangs up); its workflow is push-triggered only.
• Hand-rolled hosted harness: commit the project after the scan and before cloning the "fresh checkout"; committing before it clones the pristine Gemfile and fakes an "UNPATCHED" result (run 22 near-miss). A manifest-less vex needs --patch-server-url <mock> too, or it finds no hosted references.
• A Gemfile reverted by hand while the lock still carries the hosted wiring: vex attests as long as the installed bytes are patched (verified on disk), and refuses once bundle install re-resolves the lock to upstream (Bundler keeps the patched installed copy, but the reference is gone). That's fail-safe, so it's not filed (run 22).
• bughunt/bundler/20261005-symlink-gemfile is also left behind (git push --delete hangs up); its workflow is push-triggered only.
• Agent cells need no mock API: write .socket/manifest.json (files keys package/<rel>, git-sha256 beforeHash/afterHash) plus .socket/blobs/<afterHash> by hand and run apply --offline (run 23). Restore a patched system gem with gem pristine <gem> -v <ver>.
• A leftover populated vendor/bundle with no config while Bundler uses system gems makes agent apply patch the unused copy and vex attest. That matches the documented "vendor/bundle holds stores, so no gem env homes" heuristic and isn't filed; Gem crawler ignores Bundler's path.system: true when a leftover vendor/bundle exists, so agent apply patches the unused copy and vex attests not_affected while Bundler loads the unpatched system gem #915 covers only the explicit path.system signal (run 23).
• Bundler refuses path together with path.system (or disable_shared_gems) in the same tier ("Using a custom path while using system gems is unsupported"), so the crawler's handling of that combination can't mislead an install. Only the Gem crawler ignores Bundler's path.system: true when a leftover vendor/bundle exists, so agent apply patches the unused copy and vex attests not_affected while Bundler loads the unpatched system gem #915 shape (no path, leftover vendor/bundle) matters (run 24).
• parse_dir_name_version misparses gem names that contain -<digits>.<…> (32 of 197k rubygems.org names, all obscure, e.g. citus-rails-4.2). Not filed (run 24).
• Bundler 4.1 writes .bundle/config with unquoted values and double-quotes any key containing : (URL-scoped mirror. / credential keys). The keys main reads have no :, and backslash escaping inside quotes predates 4.1 (4.0's inspect did it too) (run 24).
• Bundler 4.1's Gemfile override DSL can't silently unpatch a hosted pin (the pinned source only serves the patched version), and it isn't counted as a gem declaration (run 24).
• Bundler's config loader keeps the double quotes when a quoted value is followed by a comment (BUNDLE_PATH: ".gems" # c → "\".gems\"") or by trailing spaces. Bundler itself breaks there, so only the unquoted value # comment shape (Gem .bundle/config reader keeps a trailing # comment in the value, so a commented BUNDLE_PATH is missed, agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched project copy #951) is a socket-patch bug (run 25).
• Bundler's config loader doesn't unescape inspect-written values ("D:\\a\\proj", "\u00FC"), and neither does socket-patch, so they agree (run 25).
• Under BUNDLE_GEMFILE=gemfiles/x.gemfile, Bundler reads gemfiles/.bundle/config and ignores the root .bundle/config (verified with 4.0.22: the root path vendor/bundle went unused and the gem landed in system gems). setup-ruby's bundler-cache writes an absolute $PWD/vendor/bundle, so the crawler's default vendor/bundle probe happens to find it; only relative paths hit Gem agent crawl ignores that BUNDLE_GEMFILE=gemfiles/x.gemfile moves Bundler.root, so a relative bundle path resolves to the wrong dir, apply patches the system copy and vex attests not_affected while Bundler loads the unpatched gemfiles/vendor/bundle copy #952 (run 25).
• Gemspec-library cells (run 27): the hosted/vendored harness copies must also copy mylib.gemspec + lib/ into every fresh or scratch checkout; otherwise Bundler aborts with "There are no gemspecs" (a harness artifact, not a bug). A gemspec dev dependency with no Gemfile line is refused by hosted mode (redirect_gem_declaration_not_visible), which is fail-closed by design.

[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-04: Bundler (RubyGems) bug-hunt run

Tested: main 045d7ec (unchanged since run 10), latest release v4.0.0. Linux, Ruby 3.3.6, Bundler 2.2.33 / 2.3.27 / 2.4.22 / 2.6.9 / 4.0.17, using the run-13 Python mock (rebuilt from the leftover bughunt/bundler/20261003-hosted-xos workflow), with real rubygems.org as the upstream. One probe branch, bughunt/bundler/20261004-bundler1: ubuntu-latest and windows-latest × Ruby 2.7 / 3.1 × Bundler 1.17.3 / 2.2.33. Run: https://github.com/SocketDev/socket-patch/actions/runs/37176834794

Re-triage

• main hasn't moved, so I didn't 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 / Hosted gem stale-install warning calls the project's own vendor/bundle a "shared gem home" when --cwd is left at its default (or relative), so it gives the wrong remedy and drops the committed cache archive from the delete list #729.
• Lock inventory reads only Gemfile.lock, so a gems.rb project's gems.locked is invisible and a stale Gemfile.lock is read instead #736 (new; filed by the architecture audit, not by this routine): added a real-install repro. A leftover redirected Gemfile.lock beside gems.rb + gems.locked makes a pre-install vex attest not_affected while Bundler installs unpatched bytes from gems.locked (4.0.17 ×2, 2.6.9). Lock inventory reads only Gemfile.lock, so a gems.rb project's gems.locked is invisible and a stale Gemfile.lock is read instead #736 (comment)

Cells

Cell	Result
#736 stale-twin Gemfile.lock → pre-install vex (4.0.17 ×2, 2.6.9)	fail → commented on #736 (2.4.22 n/a: no CHECKSUMS, so no registry pin)
Bundler 4 custom lock: .bundle/config lockfile, env BUNDLE_LOCKFILE, with and without a leftover Gemfile.lock (4.0.17)	fail → #749: only the Gemfile (and the ignored Gemfile.lock) is rewritten, no warning is emitted, and the frozen install exits 16 (control: 0)
Gemfile lockfile "custom.lock" DSL (4.0.17)	Bundler itself fails frozen installs here even before a scan; noted in #749
Bundler 1.17.3 Gemfile + gems.rb twin (probe: ubuntu 2.7 / 3.1, windows 2.7)	fail → #751: hosted wires gems.rb, Bundler 1.17 loads Gemfile, the install is unpatched and the in-run VEX attests
Bundler 1.17.3 hosted, Gemfile only / gems.rb only (probe)	pass (install patched, post-install vex exit 0)
Bundler 2.2.33 hosted, Gemfile / gems.rb / twin (probe, Linux + Windows, Ruby 2.7 / 3.1)	pass
Bundler 2.2.33 / 2.3.27 hosted cycle on Ruby 3.3.6 (Linux), Gemfile and gems.rb: redirect → install → converge → rollback → frozen install	pass
UTF-8 BOM Gemfile hosted redirect (4.0.17)	pass (BOM kept; install patched)
Symlinked Gemfile / Gemfile.lock (4.0.17)	pass (refused: redirect_symlinked_file_unsupported, nothing written)
Hosted --dry-run writes nothing (4.0.17)	pass
Backlog 8: other lexical starts_with(cwd) comparisons	only scan/hosted.rs:218 and :423 (both part of #729); ruby_crawler.rs:1118 absolutizes first. Closed.

Issues

• Filed Hosted gem redirect ignores Bundler 4's custom lockfile (lockfile setting / BUNDLE_LOCKFILE), so it never pins the lock Bundler uses and frozen installs fail with no warning #749: Hosted gem redirect ignores Bundler 4's custom lockfile (lockfile setting / BUNDLE_LOCKFILE), so it never pins the lock Bundler uses and frozen installs fail with no warning #749
• Filed Hosted gem redirect wires gems.rb in a Gemfile/gems.rb twin locked by Bundler 1.17, which loads Gemfile, so the install stays unpatched while the in-run VEX attests it #751: Hosted gem redirect wires gems.rb in a Gemfile/gems.rb twin locked by Bundler 1.17, which loads Gemfile, so the install stays unpatched while the in-run VEX attests it #751
• Commented on Lock inventory reads only Gemfile.lock, so a gems.rb project's gems.locked is invisible and a stale Gemfile.lock is read instead #736.

False positives ruled out

• Bundler 1.17 can't run on Ruby ≥ 3.2 (String#untaint). That was the real cause of the old "1.17 on Ruby 3.3 can't resolve against the mock" note; use Ruby ≤ 3.1.
• Hosted rollback reporting Manifest not found right after a 2.2 / 2.3 scan is the documented mixed-state (no-CHECKSUMS) case. After the unfrozen install converges the lock, rollback passes.
• In-run VEX on a twin under Bundler 2.2: correct (2.x loads gems.rb).

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 / Hosted gem stale-install warning calls the project's own vendor/bundle a "shared gem home" when --cwd is left at its default (or relative), so it gives the wrong remedy and drops the committed cache archive from the delete list #729 / Lock inventory reads only Gemfile.lock, so a gems.rb project's gems.locked is invisible and a stale Gemfile.lock is read instead #736 / Hosted gem redirect ignores Bundler 4's custom lockfile (lockfile setting / BUNDLE_LOCKFILE), so it never pins the lock Bundler uses and frozen installs fail with no warning #749 / Hosted gem redirect wires gems.rb in a Gemfile/gems.rb twin locked by Bundler 1.17, which loads Gemfile, so the install stays unpatched while the in-run VEX attests it #751 when fixes merge.
2. Vendored mode with Bundler 4 lockfile / BUNDLE_LOCKFILE (vendored hard-codes Gemfile.lock; needs the e2e_vendor_gem_build.rs harness).
3. rollback / remove on a custom-lock project (4.0.17).
4. Windows: x64-mingw-ucrt platform gems; BUNDLE_DEPLOYMENT=true with a CRLF lock.
5. Global mode on macOS system / Homebrew Ruby and rbenv / asdf (maintainer request).

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged), latest release v4.0.0. Linux, Ruby 3.3.6, Bundler 2.4.22 / 2.6.9 / 4.0.17. I used the run-13 Python mock (patch API + patch-registry compact index, real rubygems.org upstream). For vendored artifacts I used a scratch integration-test binary wrapping prebuilt_common::Server::project_with_env (it prints its URI and blocks), passed via SOCKET_VENDOR_URL. No probe branches this run: the new cell is OS-independent.

Re-triage

• main hasn't moved, so I didn't re-run the open issues. Hosted gem redirect ignores Bundler 4's custom lockfile (lockfile setting / BUNDLE_LOCKFILE), so it never pins the lock Bundler uses and frozen installs fail with no warning #749 and Hosted gem redirect wires gems.rb in a Gemfile/gems.rb twin locked by Bundler 1.17, which loads Gemfile, so the install stays unpatched while the in-run VEX attests it #751 are claimed, with draft PR Fix gem pair model ignoring custom lockfile and Bundler 1 twins (#749, #751) #768 (shared LoadedManifest::pair fix); I'll re-check them once it merges.

Cells (new focus: mode takeovers, never covered before)

Cell	Result
Hosted → vendored takeover, gem declared in a group block, scan --mode vendored (4.0.17 ×2, 2.6.9, 2.4.22)	fail → #775: the restore is written, then gemfile_declaration_not_editable fires; the frozen install loads unpatched bytes; the dry run says would_vendor (exit 0)
Same, get <purl> --mode vendored (4.0.17)	fail → #775
Same, vendor eject (no manifest) (4.0.17)	pass (eject_rolled_back, hosted pin intact, still patched)
Same on the v4.0.0 release	different path (no_local_source, hosted pin kept)
Hosted → vendored, top-level decl, scan --mode vendored	blocked (my two mocks issue conflicting grants → vendor_prebuilt_integrity_mismatch; it also un-hosts first, same shape as #659/#688; mentioned in #775 as a side note)
Vendored (vendor, real fixture artifact) → frozen install loads .socket/vendor copy (4.0.17)	pass
Vendored → hosted takeover, scan --mode hosted (4.0.17)	refused redirect_gem_source_option (exit 0, nothing written, stays vendored-patched); see Known non-bugs
Its remedy: remove <purl> → scan --mode hosted → install → frozen install → vex (4.0.17)	pass (patched, vex exit 0)

Issues

• Filed Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775: Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775

False positives ruled out

• The "patched after un-hosting" result was my harness committing vendor/bundle (add vendor/bundle/ to .gitignore before git add -A).
• vendor_prebuilt_integrity_mismatch comes from the Python mock answering /patches/package with its own grant while the fixture serves a different .gem. For the manifest vendor path, point --api-url at a dead port so only SOCKET_VENDOR_URL serves artifacts.

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 / Hosted gem stale-install warning calls the project's own vendor/bundle a "shared gem home" when --cwd is left at its default (or relative), so it gives the wrong remedy and drops the committed cache archive from the delete list #729 / Lock inventory reads only Gemfile.lock, so a gems.rb project's gems.locked is invisible and a stale Gemfile.lock is read instead #736 / Hosted gem redirect ignores Bundler 4's custom lockfile (lockfile setting / BUNDLE_LOCKFILE), so it never pins the lock Bundler uses and frozen installs fail with no warning #749 / Hosted gem redirect wires gems.rb in a Gemfile/gems.rb twin locked by Bundler 1.17, which loads Gemfile, so the install stays unpatched while the in-run VEX attests it #751 / Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775 when fixes (PR Fix gem pair model ignoring custom lockfile and Bundler 1 twins (#749, #751) #768 etc.) merge.
2. Hosted → vendored takeover success cell with a unified mock (one grant + artifact), including transitive gems and gems.rb (expected refusal) on 2.4 / 2.6 / 4.0.
3. Takeover on other shapes vendored refuses but hosted accepts: platform gems on a no-CHECKSUMS lock, eval_gemfile decls, install_if / platforms: blocks.
4. Vendored mode with Bundler 4 lockfile / BUNDLE_LOCKFILE; rollback / remove on a custom-lock project.
5. Windows x64-mingw-ucrt platform gems; global mode on macOS system / Homebrew Ruby (maintainer request).

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged), latest release v4.0.0. Linux, Ruby 3.3.6, Bundler 2.4.22 / 2.5.22 / 2.6.9 / 2.7.2 / 4.0.17. No probe branches this run: the new finding is in OS-independent crawler logic. Vendored artifacts came from the run-16 scratch test binary (prebuilt_common::Server::project_with_env, deleted afterwards).

Re-triage

• main hasn't moved, so I didn't re-run the open issues. Two new pm:bundler issues from the architecture audit, Vendored gem refuses a gem whose spec is not in the lock's first GEM section #779 (vendored lock reads only the first GEM section) and Read Gemfile.lock sections and DEPENDENCIES entries through formats::gem in hosted and vendored modes #780 (refactor), now cover multi-source locks. I'll leave that shape to them.

Cells

Cell	Result
Vendored repair: corrupted lib/rack.rb (4.0.17)	pass (rebuilt, vendor_artifact_corrupt, bytes restored)
Vendored repair: deleted stub rack.gemspec	pass (restored)
Vendored repair: deleted artifact dir	pass (vendor_artifact_missing, redownloaded)
Vendored repair: extra file planted in the artifact	pass (treated as corrupt, removed)
Vendored repair after the user reverts the Gemfile + lock wiring	no-op (success, no events). Repair is documented to preserve wiring, not restore it, so this isn't a bug
Vendored with Bundler 4 lockfile custom.lock (no Gemfile.lock)	pass (fails closed: vendor_lockfile_missing, nothing written)
Agent apply / vex on a bundle install --standalone tree, 4.0.17 (×2)	fail → #796: no .bundle/config is written, so ./bundle is invisible. The system copy is patched, and VEX attests not_affected while the app loads the unpatched copy. Same on the v4.0.0 release
Same, 2.4.22 / 2.5.22 / 2.6.9 / 2.7.2	pass (BUNDLE_PATH: "bundle" recorded; the standalone copy is patched)

Issues

• Filed Gem crawler misses a Bundler 4 bundle install --standalone tree (./bundle), so agent apply patches the system copy and VEX attests not_affected while the app loads the unpatched standalone copy #796: Gem crawler misses a Bundler 4 bundle install --standalone tree (./bundle), so agent apply patches the system copy and VEX attests not_affected while the app loads the unpatched standalone copy #796

False positives ruled out

• pkill -f / pgrep -f with the helper's name also matches the agent's own shell command line (exit 144). Kill helpers by a stored PID instead.
• A non-gem private source … do section is redirected by hosted mode with no upstream-remote check. That's policy (mirrors are legitimate) and earlier runs already relied on it. It's not filed.

Next

1. Hosted mode on a Bundler 4 standalone project: does the stale-install guard miss ./bundle, and does a re-run of bundle install --standalone reuse the unpatched copy? Also vendored + standalone.
2. 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 / Hosted gem stale-install warning calls the project's own vendor/bundle a "shared gem home" when --cwd is left at its default (or relative), so it gives the wrong remedy and drops the committed cache archive from the delete list #729 / Lock inventory reads only Gemfile.lock, so a gems.rb project's gems.locked is invisible and a stale Gemfile.lock is read instead #736 / Hosted gem redirect ignores Bundler 4's custom lockfile (lockfile setting / BUNDLE_LOCKFILE), so it never pins the lock Bundler uses and frozen installs fail with no warning #749 / Hosted gem redirect wires gems.rb in a Gemfile/gems.rb twin locked by Bundler 1.17, which loads Gemfile, so the install stays unpatched while the in-run VEX attests it #751 / Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775 / Gem crawler misses a Bundler 4 bundle install --standalone tree (./bundle), so agent apply patches the system copy and VEX attests not_affected while the app loads the unpatched standalone copy #796 when fixes (PRs Fix hosted gem redirect breaking multi-line and conditional gem lines (#340) #637 / Fix hosted gem redirect ignoring Bundler mirror.all (#681) #684 / Fix gem VEX ignoring out-of-tree bundle path (#709) #712 / Fix gem pair model ignoring custom lockfile and Bundler 1 twins (#749, #751) #768 …) merge.
3. Hosted → vendored takeover success cell with a unified mock (top-level, transitive, gems.rb) on 2.4 / 2.6 / 4.0.
4. Windows x64-mingw-ucrt platform gems; global mode on macOS system / Homebrew Ruby (maintainer request).
5. repair on 2.4 / 2.6 and on Windows (path separators in the ledger fileInventory).

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged), latest release v4.0.0. Linux, Ruby 3.3.6, Bundler 2.4.22 / 2.6.9 / 4.0.17. No probe branches this run: everything exercised is OS-independent lock and Gemfile logic. I also built the heads of the open fix PRs #805 (30d3a70) and #797 (20898fd) to check them against my repros.

Setup (new, reusable): a Python mock (mock2.py pattern) serving the patches API (batch / by-package / package / view with blobContent) plus one patch-registry compact index per uuid, with real rubygems.org as the upstream. It serves real gems rebuilt with a marker line (gem unpack → append SOCKET_PATCHED_<NAME> = true → gem spec --ruby → gem build). For vendored takeovers, the run-16 scratch test binary (prebuilt_common::Server::project_with_env(<staging root>)) serves artifacts, and the Python mock proxies every non-/v0, non-/patch-registry GET to it. That way --patch-server-url <mock> makes the hosted wiring recognizable and routes artifact downloads correctly. Export SOCKET_VENDOR_URL=<prebuilt uri> too, or /patches/package hits the API mock (tarball artifact has no sha512 integrity). The scratch test file was deleted afterwards.

Re-triage

• Gem crawler misses a Bundler 4 bundle install --standalone tree (./bundle), so agent apply patches the system copy and VEX attests not_affected while the app loads the unpatched standalone copy #796 (mine): still reproduces on main (3rd time). PR Fix gem crawler missing Bundler 4 standalone bundle (#796) #797 fixes it: the ./bundle copy is patched and loaded. I commented with the table: Gem crawler misses a Bundler 4 bundle install --standalone tree (./bundle), so agent apply patches the system copy and VEX attests not_affected while the app loads the unpatched standalone copy #796 (comment)
• Vendored gem refuses a gem whose spec is not in the lock's first GEM section #779 (arch audit): new trigger found (see below). PR Fix vendored gem lookup beyond the first GEM section (#779) #805 verified. Comment: Vendored gem refuses a gem whose spec is not in the lock's first GEM section #779 (comment)
• Other open issues: main hasn't moved, so I didn't re-run them.

Cells

Cell	Result
Hosted, 3 gems in one scan (2 direct + 1 transitive), CHECKSUMS lock, 4.0.17 / 2.6.9	pass: 3 patch-registry GEM sections + ! pins + patched shas, frozen fresh install with the lock unchanged, all patched
Same, no-CHECKSUMS lock, 2.4.22	pass after the documented unfrozen install (frozen exits 16, as documented)
Hosted incremental (1 gem, then 3 gems as patches appear) + byte-identical re-run, 4.0.17	pass
Post-install manifest-less vex across 3 redirected gems	pass (3 × not_affected / redirected)
Hosted rollback <one purl> out of 3 on a converged lock, then unscoped rollback, real rubygems.org upstream, 4.0.17 / 2.6.9	pass (only that gem unwound, frozen install OK at each step; exact pins documented)
Hosted → vendored takeover, 1 gem, CHECKSUMS lock, 4.0.17	pass (backlog item 3 top-level cell)
Hosted → vendored takeover, 3 gems, 4.0.17 CHECKSUMS (×2) and 2.4.22 converged (×1)	fail → #779 (comment): only the last gem vendors. The others are un-hosted and hit apply_failed "GEM specs has no entry", leaving upstream bytes, exit 1. A re-run recovers. PR #805 fixes it on both versions (frozen install, all patched)
Hosted → vendored takeover on a mixed (no-CHECKSUMS, not yet installed) 2.4.22 pair	fails closed (gemfile_declaration_not_editable, nothing written). Consistent with the documented "mixed state is out of the unwind's reach"
Agent scan / vex on a Bundler 4 --standalone tree, main vs PR #797	main fail (#796), PR pass

Issues

• No new issues. Commented on Vendored gem refuses a gem whose spec is not in the lock's first GEM section #779 and Gem crawler misses a Bundler 4 bundle install --standalone tree (./bundle), so agent apply patches the system copy and VEX attests not_affected while the app loads the unpatched standalone copy #796.

False positives ruled out

• My first takeover run failed rainbow with serve returned 404. That was a harness artifact: --patch-server-url rewrites the artifact host to the API mock. It's fixed by the proxy described above.
• On the 2.4.22 takeover, I briefly measured a stale binary: the PR target dir had been rebuilt from Fix gem crawler missing Bundler 4 standalone bundle (#796) #797. Build each PR into its own CARGO_TARGET_DIR.
• pgrep/ps | grep patterns that also appear later in the same command line (e.g. a rm …zz_scratch… in the same shell) kill the agent's shell (exit 144) again. Keep kill commands in their own Bash call.

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 / Hosted gem stale-install warning calls the project's own vendor/bundle a "shared gem home" when --cwd is left at its default (or relative), so it gives the wrong remedy and drops the committed cache archive from the delete list #729 / Lock inventory reads only Gemfile.lock, so a gems.rb project's gems.locked is invisible and a stale Gemfile.lock is read instead #736 / Hosted gem redirect ignores Bundler 4's custom lockfile (lockfile setting / BUNDLE_LOCKFILE), so it never pins the lock Bundler uses and frozen installs fail with no warning #749 / Hosted gem redirect wires gems.rb in a Gemfile/gems.rb twin locked by Bundler 1.17, which loads Gemfile, so the install stays unpatched while the in-run VEX attests it #751 / Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775 / Vendored gem refuses a gem whose spec is not in the lock's first GEM section #779 / Gem crawler misses a Bundler 4 bundle install --standalone tree (./bundle), so agent apply patches the system copy and VEX attests not_affected while the app loads the unpatched standalone copy #796 when fixes merge (PRs Fix hosted gem redirect breaking multi-line and conditional gem lines (#340) #637 / Fix hosted gem redirect ignoring Bundler mirror.all (#681) #684 / Fix gem VEX ignoring out-of-tree bundle path (#709) #712 / Fix gem pair model ignoring custom lockfile and Bundler 1 twins (#749, #751) #768 / Fix gem crawler missing Bundler 4 standalone bundle (#796) #797 / Fix vendored gem lookup beyond the first GEM section (#779) #805 …).
2. Hosted stale-install guard on a Bundler 4 standalone project once Fix gem crawler missing Bundler 4 standalone bundle (#796) #797 lands.
3. Takeover over shapes that hosted accepts but vendored refuses: platform gem on a no-CHECKSUMS lock, eval_gemfile, install_if / platforms: blocks (likely Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775-shaped).
4. Windows x64-mingw-ucrt platform gems, hosted and vendored. The CI gem e2e suites run on ubuntu only, and Command::new("bundle") won't resolve bundle.bat, so use script-based probes (the Python mock runs under shell: bash).
5. Global mode on macOS system / Homebrew Ruby (maintainer request).

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged; no gem fix PR merged), latest release v4.0.0. Linux, Ruby 3.3.6, Bundler 2.4.22 / 2.6.9 / 4.0.17. No probe branches: the new finding is OS-independent string handling. I also built PR #637's head (464896d) into its own target dir to check it against the new repro.

Setup (re-created this run): two small Python mocks around real colorize 0.8.1 from rubygems.org. mock.py (agent: batch / by-package / view with blobContent). mock2.py (hosted: adds POST …/patches/package with a rubygems-compact-index grant, plus a patch-registry compact index /versions / /info/colorize / /names / /gems/… serving a rebuilt gem with a SOCKET_PATCHED_COLORIZE marker, with ETags). Drive hosted scans with --patch-server-url <mock>. A wrapper script runs: write the Gemfile → bundle install into vendor/bundle → scan --mode hosted → diff the Gemfile → fresh checkout with BUNDLE_FROZEN=true bundle install → grep the marker. For vendored, I used a scratch copy of e2e_vendor_gem_build.rs with only the fixture Gemfile line changed, and deleted it afterwards.

Re-triage

• Main hasn't moved since 045d7ec and none of the gem fix PRs (Fix hosted gem redirect breaking multi-line and conditional gem lines (#340) #637, Fix hosted gem redirect ignoring Bundler mirror.all (#681) #684, Fix gem VEX ignoring out-of-tree bundle path (#709) #712, Fix gem source-option guard missing git sources (#652) #731, Fix gem lock readers ignoring gems.locked (#736) #750, Fix gem pair model ignoring custom lockfile and Bundler 1 twins (#749, #751) #768, Fix gem takeover un-hosting a grouped gem (#775) #776, Fix gem crawler missing Bundler 4 standalone bundle (#796) #797, Fix vendored gem lookup beyond the first GEM section (#779) #805) have merged, so the open issues weren't re-run.

Cells

Cell	Result
Repo gem e2e suites on Bundler 2.6.9 (e2e_redirect_gem_build 21, e2e_vendor_gem_build 16, e2e_redirect_gem_stale_install 25)	pass
Agent scan/apply + vex, .bundle/config BUNDLE_DEPLOYMENT: "true" with no path (installs to vendor/bundle), 4.0.17	pass
Agent vex with a stale Ruby-ABI scope (vendor/bundle/ruby/3.2.0 patched, live 3.3.0 unpatched after bundle pristine), 4.0.17	pass (refuses not_applied)
Agent scan on a gems.rb-only project on system gems, 4.0.17	pass
Hosted baseline (single-line decl, CHECKSUMS lock, real upstream), 4.0.17	pass
Hosted, decl with a trailing # comment, 4.0.17	pass (comment dropped; cosmetic)
Hosted, parenthesized gem("colorize", "0.8.1"), 4.0.17	pass (frozen fresh install patched)
Hosted, gem "rainbow", …; gem "colorize", … (patched gem second), 4.0.17	pass (refused: redirect_gem_unrecognized_declaration)
Hosted, gem "colorize", …; gem "rainbow", … (patched gem first), 4.0.17 ×3 / 2.6.9 / 2.4.22 / gems.rb	fail → #826: rainbow's declaration is deleted, the frozen install exits 16, and the unfrozen install drops rainbow (LoadError). rollback doesn't restore it
Same, PR #637 head	fail → #826 (its tail guard doesn't treat ; as a separator)
Hosted, gem "colorize", "0.8.1", require: false; gem "rainbow", …, 4.0.17	fail → #826 (rainbow is moved into the Socket source block; frozen exit 16)
Vendored, gem "rack", "~> 3.1"; gem "colorize", "0.8.1", 4.0.17 / 2.4.22	fail → #826 (colorize deleted; frozen fresh install exits 16)

Issues

• Filed Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826: Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826

False positives ruled out

• scan without --mode is hosted in v5. My first agent probe hit "Failed to resolve patch references" because the agent-only mock has no /patches/package endpoint. Pass --mode agent explicitly.
• cargo test … -- --ignored --include-ignored prints nothing, because the flags conflict. Use --include-ignored alone.
• An agent probe on a system-gems project patches the shared /opt/rbenv/…/colorize-0.8.1. My mock serves no blobs, so rollback can't restore it; restore with gem pristine colorize -v 0.8.1.

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 / Hosted gem stale-install warning calls the project's own vendor/bundle a "shared gem home" when --cwd is left at its default (or relative), so it gives the wrong remedy and drops the committed cache archive from the delete list #729 / Lock inventory reads only Gemfile.lock, so a gems.rb project's gems.locked is invisible and a stale Gemfile.lock is read instead #736 / Hosted gem redirect ignores Bundler 4's custom lockfile (lockfile setting / BUNDLE_LOCKFILE), so it never pins the lock Bundler uses and frozen installs fail with no warning #749 / Hosted gem redirect wires gems.rb in a Gemfile/gems.rb twin locked by Bundler 1.17, which loads Gemfile, so the install stays unpatched while the in-run VEX attests it #751 / Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775 / Vendored gem refuses a gem whose spec is not in the lock's first GEM section #779 / Gem crawler misses a Bundler 4 bundle install --standalone tree (./bundle), so agent apply patches the system copy and VEX attests not_affected while the app loads the unpatched standalone copy #796 / Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826 when fixes merge.
2. More single-line shapes for both rewriters: gem "x", "1.0"; # trailing, gem "x" unless …; gem "y", one-line group :t do gem "x" end, gem "x", *VERSIONS, gem "x", ENV.fetch("V").
3. Takeover over shapes hosted accepts but vendored refuses (platform gem on a no-CHECKSUMS lock, install_if / platforms: blocks).
4. Windows x64-mingw-ucrt platform gems, hosted and vendored (script-based probe with the mock2 pattern under shell: bash).
5. Global mode on macOS system / Homebrew Ruby (maintainer request).

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged; no gem fix PR merged), latest release v4.0.0. Linux, Ruby 3.3.6, Bundler 4.0.17 / 2.4.22, plus one probe branch (bughunt/bundler/20261005-global-macos, runs 37296630547 and 37297725910) on macos-14, macos-15 and windows-latest.

Setup: I re-created run 19's mock2.py (it now also serves beforeBlobContent, so agent rollback works) around real colorize 0.8.1 from rubygems.org, plus a run.sh wrapper: write the Gemfile → bundle install → scan --mode hosted → diff → frozen fresh-checkout install → check for the marker constant. For vendored cells I used scratch copies of e2e_vendor_gem_build.rs with only the fixture Gemfile changed, and deleted them afterwards.

Re-triage

• Main hasn't moved and none of the gem fix PRs have merged, so I re-ran none of the open issues.

Cells

Cell	Result
Hosted, 4.0.17: gem "x", "1"; # c, gem "x" # …; gem "y" (in a comment), *V, ENV.fetch(…), tab separator, :require =>, platforms: [...], group: [...], "x" ,, require: "x#y"	pass (frozen fresh install loads the patched gem)
Hosted, 4.0.17: one-line group :t do gem "x" end, gem %q(x)	pass (refused: redirect_gem_declaration_not_visible, nothing written)
Hosted, 4.0.17: gem "x" if true; gem "y"	fail, already covered by #340 / #826
Hosted rollback, 4.0.17, of the shapes above	pass (lock byte-restored; Gemfile gets the documented exact pin plus any kept arguments)
Hosted, 4.0.17: name also in =begin/=end, a heredoc, or after __END__	pass (refused: redirect_gem_declared_more_than_once)
Hosted, 4.0.17: gem "colorize-x", path: before/after gem "colorize"	pass
Hosted, 4.0.17: 3 concurrent scans ×3	pass (one wins; the others exit 1 on .socket/apply.lock)
Hosted, 4.0.17: env BUNDLE_GEMFILE = gemfiles/x.gemfile, another project's Gemfile (abs / ../), ./Gemfile, Gemfile, abs own Gemfile	pass (refuses / selects as documented)
Vendored, 4.0.17 and 2.4.22: gem "rack", *RV / ENV.fetch("RV", "~> 3.1") / RACK_VERSION, require: false	fail → #847 (positional arg written after path: → Gemfile syntax error; vendor reports success, VEX attests)
Global -g, Linux: unicode + space --global-prefix full cycle	pass
Global -g, macos-14 / macos-15 system Ruby 2.6, --user-install	pass (scan/get/vex/rollback)
Global -g, macos-14 / macos-15 system Ruby, root-owned /Library/Ruby/Gems/2.6.0 (with and without --global-prefix)	pass (get exits 1 partial_failure, nothing patched; vex refuses not_applied)
Global -g, macos-14 / macos-15 Homebrew Ruby 4.0.6 (with and without prefix)	pass
Global -g, macOS + Windows unicode/space prefix	pass
Global -g inside a Bundler project (macOS Homebrew 3.3, Windows RubyInstaller 3.3.12)	pass (patches the global copy; the project's vendor/bundle stays unpatched)

Issues

• Filed Vendored gem rewrite puts non-string arguments after path:, so gem "x", *V, gem "x", ENV.fetch(…) or gem "x", VERSION becomes a Gemfile syntax error and every bundle command fails #847: Vendored gem rewrite puts non-string arguments after path:, so gem "x", *V, gem "x", ENV.fetch(…) or gem "x", VERSION becomes a Gemfile syntax error and every bundle command fails #847

False positives ruled out

• get --json after a failed apply shows failed: 0. failed counts downloads only; status partial_failure + exit 1 carry the failure (by design, not specific to gems). Added to Known non-bugs.
• pkill -f mock2.py inside a command line that contains mock2.py killed my own shell (exit 144), as the ledger already warns.
• Bundler 2.4.22 wasn't preinstalled in this container (gem install bundler -v 2.4.22); the harness gate catches it.
• git push --delete for the probe branch hung up again, so the branch is left behind (push-triggered workflow only).

Next

1. Re-run the open issues (Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 … Vendored gem rewrite puts non-string arguments after path:, so gem "x", *V, gem "x", ENV.fetch(…) or gem "x", VERSION becomes a Gemfile syntax error and every bundle command fails #847) when fixes merge.
2. Vendored: more positional-tail shapes; the run-20 hosted shapes on 2.6.9 / 2.4.22.
3. Takeover over shapes hosted accepts but vendored refuses.
4. Windows x64-mingw-ucrt platform gems, hosted and vendored.
5. Global mode on rvm / chruby / asdf; a non-writable gem dir on Windows.

[github-actions[bot]]

[agent] Janitor: ledger drift. This ledger was last updated on main 045d7ec, before the 2026-10-05 11:13–13:20Z merge wave. It still cites these issues as fail, but they are now closed as completed:

• Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 (fixed by PR Fix hosted gem redirect breaking multi-line and conditional gem lines (#340) #637)
• 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 (fixed by PR Fix Bundler global config being ignored (#577) #621)
• Vendored gem refuses a gem whose spec is not in the lock's first GEM section #779 (fixed by PR Fix vendored gem lookup beyond the first GEM section (#779) #805)

Please re-verify those cells on main 6811b4e7.

---

Generated by Claude Code

[github-actions[bot]]

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

Tested: main 0d302dc (main was force-updated since run 20; it now includes #637 / #340, #621 / #577, #797 / #796, #805 / #779 and #849 / #847), latest release v4.0.0. Linux, Ruby 3.3.6, Bundler 4.0.22 (new: the newest release, not tested before), 4.0.17, 2.6.9 and 2.4.22. One probe branch, bughunt/bundler/20261005-win-ro: runs 37342493443 (windows-latest + macos-14), 37343269602 and 37344225242 (Windows re-runs after harness fixes).

Setup: re-created mock2.py (agent and hosted endpoints, patch-registry compact index with ETags, rebuilt colorize 0.8.1 marker gem). It's now parameterized by PNAME / PVER / PFILE / PORIG / PPAT, so it can serve any gem file as an agent patch. run.sh does: Gemfile → bundle install → scan --mode hosted → diff → git-clone fresh checkout → BUNDLE_FROZEN=true bundle install → marker check. Vendored cells used a scratch copy of e2e_vendor_gem_build.rs with a SP_GEMFILE-driven report-only test (deleted afterwards).

Re-triage

• Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826 (mine): still reproduces on 0d302dc (2/2), even with Fix hosted gem redirect breaking multi-line and conditional gem lines (#340) #637 merged. I also found that Fix hosted gem redirect breaking multi-line and conditional gem lines (#340) #637 now refuses a bare trailing ; (gem "x", "1"; and gem "x", "1"; # c), which redirected fine in run 20: same ; handling, opposite symptom, fail-closed. I added both to one comment rather than filing a near-duplicate: Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826 (comment)
• 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, Gem crawler misses a Bundler 4 bundle install --standalone tree (./bundle), so agent apply patches the system copy and VEX attests not_affected while the app loads the unpatched standalone copy #796, Vendored gem rewrite puts non-string arguments after path:, so gem "x", *V, gem "x", ENV.fetch(…) or gem "x", VERSION becomes a Gemfile syntax error and every bundle command fails #847 and Vendored gem refuses a gem whose spec is not in the lock's first GEM section #779 were closed by maintainers with merged fixes. The run-21 cells below re-exercise the fixed code (Fix hosted gem redirect breaking multi-line and conditional gem lines (#340) #637 shapes, Fix vendored gem rewrite breaking positional args (#847) #849 vendored positional args, Fix vendored gem lookup beyond the first GEM section (#779) #805 second GEM section, Fix gem crawler missing Bundler 4 standalone bundle (#796) #797 standalone stale guard), and all pass.

Cells

Cell	Result
Repo gem e2e suites on Bundler 4.0.22 (redirect 25, vendor 18, stale-install 29)	pass
Hosted CHECKSUMS cycle on 4.0.22: Gemfile, gems.rb, transitive via a path: gem, group block, CRLF Gemfile, PLATFORMS x86_64-linux only; rollback of each → frozen install	pass (lock byte-restored)
Hosted, 9 legitimate one-line shapes after #637 (4.0.17)	pass
Hosted gem "x", "1"; / gem "x", "1"; # c (4.0.17 / 2.6.9 / 2.4.22, 2× each)	fail → #826 comment (redirect_gem_unrecognized_declaration "continues on the next line"; was a pass before #637)
Hosted run-20 shapes (*[V], ENV.fetch, tab, :require =>, platforms: [...], group: [...], "x" ,) on 2.6.9 / 2.4.22	pass (2.4.22 after the documented unfrozen install)
Hosted rollback after a user bundle update rainbow (4.0.17)	pass (rainbow 3.1.1 kept, colorize unwound)
Hosted stale guard: Bundler 4 --standalone (./bundle) / system-gems install	pass / pass (warn, VEX withheld)
Vendored CONST, *%w[], *EXTRA, **OPTS, two constants (after #849)	pass (frozen fresh install patched, VEX ok)
Vendored transitive gem from the lock's 2nd GEM section (after #805)	pass
Agent, locked default gem uri 0.13.1 on system gems	pass (Bundler installs a regular copy; patched, rolled back byte-exact)
Global -g, Linux chruby env layout	pass (scan/get/vex/rollback)
Global -g, Linux rvm env layout (@global only; plus a shadowing @app copy)	pass (vex refuses while the loaded copy is unpatched; get patches both; rollback restores both)
Global -g, macos-14 system Ruby 2.6 / Bundler 1.17, inside a project	pass (global copy patched, vendor/bundle untouched)
Windows (RubyInstaller 3.4.9), Bundler 4.0.22 agent cycle, project path with a space	pass
Windows, deny-write ACE on the global gem dir	pass (fail-closed: get exit 1 partial_failure, nothing written, vex refuses). The ACE also blocks Ruby's own require, so a "read-only but loadable" cell is still untested

Issues

• No new issues. Commented on Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826 (re-check + the Fix hosted gem redirect breaking multi-line and conditional gem lines (#340) #637 trailing-; regression).

False positives ruled out

• Bundler 4.0.19+ fails frozen installs on any CRLF lock, pristine included (exit 16; 4.0.17 only warned). That's Bundler's change (rubygems #9750), not socket-patch. The Known non-bugs entry is updated.
• Bundler 4.0.18+ cooldown: versions without created_at and locked versions are never filtered, so a hosted pin is unaffected (read from the 4.0.22 source).
• The standalone stale-install remedy says bundle install rather than bundle install --standalone. The failure that follows is loud (LoadError), so it's a wording nit and not filed.
• An earlier standalone remedy test installed the patched colorize into system gems, which made a later system-gems cell look "PATCHED". I uninstalled it and re-ran. Agent cells on system gems patch the real system copy, so clean up after them.
• Windows probe harness: MSYS converted icacls /deny into a path (run 1), and my writability check appended to the gem file (run 2). Both were fixed in run 3.

Next

1. Re-run 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 / Hosted gem stale-install warning calls the project's own vendor/bundle a "shared gem home" when --cwd is left at its default (or relative), so it gives the wrong remedy and drops the committed cache archive from the delete list #729 / Lock inventory reads only Gemfile.lock, so a gems.rb project's gems.locked is invisible and a stale Gemfile.lock is read instead #736 / Hosted gem redirect ignores Bundler 4's custom lockfile (lockfile setting / BUNDLE_LOCKFILE), so it never pins the lock Bundler uses and frozen installs fail with no warning #749 / Hosted gem redirect wires gems.rb in a Gemfile/gems.rb twin locked by Bundler 1.17, which loads Gemfile, so the install stays unpatched while the in-run VEX attests it #751 / Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775 / Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826 when fixes merge.
2. Re-run the 4.0.17-only cells on 4.0.22 (frozen now fails instead of warning): multi-gem hosted, H→V takeover, eval_gemfile, multi-platform locks, BUNDLE_DEPLOYMENT.
3. Takeover over shapes hosted accepts but vendored refuses.
4. Windows x64-mingw-ucrt platform gems, hosted and vendored; a read-only ((R) ACE) but loadable gem dir.
5. Real rvm / chruby installs on macOS.

[github-actions[bot]]

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

Tested: main 9c43dfc (since run 21 it adds #731 / #652, #750 / #736 and #712 / #709; all three issues were already closed by maintainers), latest release v4.0.0. Linux sandbox, Ruby 3.3.6, Bundler 4.0.22 / 2.7.2 (new to the hosted cells) / 2.6.9 / 2.4.22, real rubygems.org upstream, Python mock of the patch API and registry. One probe branch, bughunt/bundler/20261005-symlink-gemfile: run 37382646373 (macos-latest + ubuntu-latest, Ruby 3.4, Bundler 4.0.22).

Re-triage

• Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826 (mine): still reproduces on 9c43dfc (2/2) and has a new shape: gem "x", "1"; gem "y" (the second gem has no version) moves y into the Socket source block and doubles the requirement (gem "x", "1", "1"; gem "y"). The frozen install fails (exit 16). PR Fix gem rewrite deleting a ;-joined declaration (#826) #875 head 5b9953d3 refuses both ;-joined shapes and redirects a bare trailing ; correctly (frozen install patched). Comment: Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826 (comment)
• Hosted gem stale-install warning calls the project's own vendor/bundle a "shared gem home" when --cwd is left at its default (or relative), so it gives the wrong remedy and drops the committed cache archive from the delete list #729: still reproduces (the default --cwd warning says "shared gem home" for the project's own vendor/bundle). Seen incidentally on every hosted cell this run; no comment, nothing new to add.
• 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 / Lock inventory reads only Gemfile.lock, so a gems.rb project's gems.locked is invisible and a stale Gemfile.lock is read instead #736 / 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 were fixed and closed by maintainers. Exercised the fixed code below: git … do / path … do blocks and git: refused through the lock's GIT/PATH section; gems.rb with a stale Gemfile.lock twin redirects gems.locked.

Cells

Cell	Result
Hosted single-line CHECKSUMS cycle → frozen fresh install → rollback → frozen install, 4.0.22 / 2.7.2 / 2.6.9	pass (Gemfile + lock byte-restored)
Same on 2.4.22 (no CHECKSUMS)	documented (frozen fails until the unfrozen install; rollback refuses the mixed state)
Hosted, 4-platform lock (arm64-darwin, x86_64-darwin, ruby, x86_64-linux) + CHECKSUMS, pure-ruby gem, 4.0.22, + rollback	pass
Hosted gems.rb + stale Gemfile.lock twin (after #750), 4.0.22, + rollback	pass (gems.locked wired)
Hosted gem in git "…" do / path "…" do block, git: option (after #731), 4.0.22	pass (refused: redirect_gem_source_option via the lock section)
Hosted, Gemfile reverted by hand while the lock is still redirected: vex	pass (attests while the installed bytes are patched; refuses once bundle install re-resolves)
Hosted, BUNDLE_GEMFILE naming the project's Gemfile through a symlinked dir (env $PWD/Gemfile, --cwd link + env real, config abs link path), plus vex / rollback	fail → #896 (macOS /tmp + Linux, 4.0.22)
#826 shapes on main / PR #875	fail on main; pass on #875

Issues

• Filed Gem BUNDLE_GEMFILE check compares paths lexically, so a symlinked spelling of the project's own Gemfile (e.g. macOS /tmp/app/Gemfile) is refused, and vex / rollback reject the hosted patch Bundler is loading #896: Gem BUNDLE_GEMFILE check compares paths lexically, so a symlinked spelling of the project's own Gemfile (e.g. macOS /tmp/app/Gemfile) is refused, and vex / rollback reject the hosted patch Bundler is loading #896 (first bad commit 9d718cf5 / Fix gem modes wiring a manifest Bundler ignores (#341, #390) #431; not in v4.0.0).
• Commented on Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826.

False positives ruled out

• First baseline "UNPATCHED after frozen install": my harness committed before the scan, so the fresh clone had the pristine Gemfile. Fixed (commit after the scan, then clone).
• Probe installed=false / vex_unset exit=1: the probe didn't delete the stale vendor/bundle after the redirect, so this is the expected stale-install guard; the Linux sandbox covered the vex/rollback cells instead.

Next

1. Re-run 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 stale-install warning calls the project's own vendor/bundle a "shared gem home" when --cwd is left at its default (or relative), so it gives the wrong remedy and drops the committed cache archive from the delete list #729 / Hosted gem redirect ignores Bundler 4's custom lockfile (lockfile setting / BUNDLE_LOCKFILE), so it never pins the lock Bundler uses and frozen installs fail with no warning #749 / Hosted gem redirect wires gems.rb in a Gemfile/gems.rb twin locked by Bundler 1.17, which loads Gemfile, so the install stays unpatched while the in-run VEX attests it #751 / Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775 / Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826 / Gem BUNDLE_GEMFILE check compares paths lexically, so a symlinked spelling of the project's own Gemfile (e.g. macOS /tmp/app/Gemfile) is refused, and vex / rollback reject the hosted patch Bundler is loading #896 when fixes merge (open PRs Fix hosted gem redirect ignoring Bundler mirror.all (#681) #684, Fix gem pair model ignoring custom lockfile and Bundler 1 twins (#749, #751) #768, Fix gem takeover un-hosting a grouped gem (#775) #776, Fix gem rewrite deleting a ;-joined declaration (#826) #875).
2. 4.0.22 versions of the remaining 4.0.17-only cells: H→V takeover, eval_gemfile, BUNDLE_DEPLOYMENT.
3. Takeover over shapes hosted accepts but vendored refuses.
4. Windows x64-mingw-ucrt platform gems; a read-only (R) ACE gem dir that Ruby can still load.
5. Vendored mode with a symlinked BUNDLE_GEMFILE (shares classify; expected to be refused like Gem BUNDLE_GEMFILE check compares paths lexically, so a symlinked spelling of the project's own Gemfile (e.g. macOS /tmp/app/Gemfile) is refused, and vex / rollback reject the hosted patch Bundler is loading #896, not verified).

[github-actions[bot]]

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

Tested: main 9c43dfc (unchanged since run 22; no gem fix PR merged), latest release v4.0.0. Linux sandbox, Ruby 3.3.6, Bundler 4.0.22 / 2.6.9 / 2.4.22. No probe branches: the finding is OS-independent path selection.

Setup (no mock API needed): agent mode driven by a hand-written .socket/manifest.json plus .socket/blobs/<git-sha256> (patch package/lib/colorize.rb in real colorize 0.8.1 by appending a $SOCKET_PATCHED_COLORIZE marker), then socket-patch apply --offline. Check which copy Bundler loads with bundle exec ruby -e 'require "colorize"; … Gem.loaded_specs["colorize"].full_gem_path'. Restore the shared system copy with gem pristine colorize -v 0.8.1 after every cell.

Re-triage

• Main hasn't moved since run 22, so Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826 / Gem BUNDLE_GEMFILE check compares paths lexically, so a symlinked spelling of the project's own Gemfile (e.g. macOS /tmp/app/Gemfile) is refused, and vex / rollback reject the hosted patch Bundler is loading #896 and the other open issues weren't re-run (nothing new to report).

Cells

Cell	4.0.22	2.6.9	2.4.22
Agent apply + vex, local path.system: true + leftover vendor/bundle	fail #915 (2/2)	fail #915	fail #915
Same with env BUNDLE_PATH__SYSTEM=true	fail #915 (2/2)	fail #915	fail #915
Control: local path.system: true, no leftover vendor/bundle	pass	pass	—
Control: no config, leftover vendor/bundle	documented heuristic (same symptom; see Known non-bugs)	—	—
Published v4.0.0, local path.system + leftover	apply patches only vendor/bundle; vex omits for the old setup gating, so no false VEX there	—	—

Issues

• Filed Gem crawler ignores Bundler's path.system: true when a leftover vendor/bundle exists, so agent apply patches the unused copy and vex attests not_affected while Bundler loads the unpatched system gem #915: Gem crawler ignores Bundler's path.system: true when a leftover vendor/bundle exists, so agent apply patches the unused copy and vex attests not_affected while Bundler loads the unpatched system gem #915 (false not_affected VEX; the crawler keeps the default vendor/bundle root, which suppresses the gem env homes even when Bundler's winning tier says path.system).

False positives ruled out

• The no-config leftover vendor/bundle case shows the same symptom, but CLI_CONTRACT.md documents that heuristic, so Gem crawler ignores Bundler's path.system: true when a leftover vendor/bundle exists, so agent apply patches the unused copy and vex attests not_affected while Bundler loads the unpatched system gem #915 is scoped to the explicit path.system signal the crawler already parses.

Next

1. Re-run 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 stale-install warning calls the project's own vendor/bundle a "shared gem home" when --cwd is left at its default (or relative), so it gives the wrong remedy and drops the committed cache archive from the delete list #729 / Hosted gem redirect ignores Bundler 4's custom lockfile (lockfile setting / BUNDLE_LOCKFILE), so it never pins the lock Bundler uses and frozen installs fail with no warning #749 / Hosted gem redirect wires gems.rb in a Gemfile/gems.rb twin locked by Bundler 1.17, which loads Gemfile, so the install stays unpatched while the in-run VEX attests it #751 / Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775 / Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826 / Gem BUNDLE_GEMFILE check compares paths lexically, so a symlinked spelling of the project's own Gemfile (e.g. macOS /tmp/app/Gemfile) is refused, and vex / rollback reject the hosted patch Bundler is loading #896 / Gem crawler ignores Bundler's path.system: true when a leftover vendor/bundle exists, so agent apply patches the unused copy and vex attests not_affected while Bundler loads the unpatched system gem #915 when fixes merge (open PRs Fix hosted gem redirect ignoring Bundler mirror.all (#681) #684, Fix gem pair model ignoring custom lockfile and Bundler 1 twins (#749, #751) #768, Fix gem takeover un-hosting a grouped gem (#775) #776, Fix gem rewrite deleting a ;-joined declaration (#826) #875).
2. The Gem crawler ignores Bundler's path.system: true when a leftover vendor/bundle exists, so agent apply patches the unused copy and vex attests not_affected while Bundler loads the unpatched system gem #915 family on the hosted stale-install guard: does it warn about the wrong (vendor/bundle) copy and miss the system one under path.system? Also a global-config path.system, and a non-"true" bool spelling ("1", "yes"), which Bundler's to_bool accepts but parse_bundle_config_path doesn't.
3. 4.0.22 versions of the remaining 4.0.17-only cells: H→V takeover, eval_gemfile, multi-gem hosted.
4. Takeover over shapes hosted accepts but vendored refuses (platform gem on a no-CHECKSUMS lock, install_if / platforms: blocks).
5. Windows x64-mingw-ucrt platform gems; vendored mode with a symlinked BUNDLE_GEMFILE.

[github-actions[bot]]

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

Tested: main 9c43dfc (unchanged since run 22), latest release v4.0.0. Linux sandbox, Ruby 3.3.6, Bundler 4.1.0.beta1 (new, released 2026-09-09) plus 4.0.22 / 2.6.9 / 2.4.22 for comparisons. No probe branches this run: everything was OS-independent.

Re-triage

• Main hasn't moved and no gem fix PR has merged, so 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 stale-install warning calls the project's own vendor/bundle a "shared gem home" when --cwd is left at its default (or relative), so it gives the wrong remedy and drops the committed cache archive from the delete list #729 / Hosted gem redirect ignores Bundler 4's custom lockfile (lockfile setting / BUNDLE_LOCKFILE), so it never pins the lock Bundler uses and frozen installs fail with no warning #749 / Hosted gem redirect wires gems.rb in a Gemfile/gems.rb twin locked by Bundler 1.17, which loads Gemfile, so the install stays unpatched while the in-run VEX attests it #751 / Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775 / Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826 / Gem BUNDLE_GEMFILE check compares paths lexically, so a symlinked spelling of the project's own Gemfile (e.g. macOS /tmp/app/Gemfile) is refused, and vex / rollback reject the hosted patch Bundler is loading #896 / Gem crawler ignores Bundler's path.system: true when a leftover vendor/bundle exists, so agent apply patches the unused copy and vex attests not_affected while Bundler loads the unpatched system gem #915 weren't re-run.
• Read the open fix PRs against backlog items. PR Fix gem crawl ignoring Bundler path.system (#915) #916 (Gem crawler ignores Bundler's path.system: true when a leftover vendor/bundle exists, so agent apply patches the unused copy and vex attests not_affected while Bundler loads the unpatched system gem #915) already handles Bundler's to_bool spellings ("1", "yes", "TRUE"). PR Fix gem takeover un-hosting a grouped gem (#775) #776 (Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775) runs the full vendored declaration gate on the restored Gemfile, so it also covers platforms / install_if / source blocks, not just group.

Cells

Cell	Result
Repo gem e2e suites on Bundler 4.1.0.beta1 (e2e_redirect_gem_build / e2e_vendor_gem_build / e2e_redirect_gem_stale_install)	pass (26 / 22 / 32, SOCKET_PATCH_BUNDLER_E2E_REQUIRED=1)
Agent apply --offline + vex on 4.1.0.beta1, unquoted BUNDLE_PATH: vendor/my bundle (4.1's new config spelling)	pass (the loaded copy is patched; 1 VEX statement)
4.1 .bundle/config format vs the main readers (BUNDLE_PATH, BUNDLE_GEMFILE, BUNDLE_CACHE_PATH, BUNDLE_PATH__SYSTEM)	pass (no : in these keys; unquoted values parse)
4.1 URL-scoped mirror key vs PR #684 (capturing_mirror)	gap: the quoted key "BUNDLE_MIRROR__HTTPS://…/": isn't detected (scratch unit test on head 0e1e6cda, 2/2). Commented on #681
path.system bool spellings (#915 family)	covered by PR #916; and Bundler itself refuses path + path.system in one tier ("Using a custom path while using system gems is unsupported")
Hosted stale guard under path.system + leftover vendor/bundle	same root cause as #915 (get_gem_paths), fixed by PR #916; not filed separately
Vendored + symlinked BUNDLE_GEMFILE (backlog 7)	already covered by #896's body (it names the vendored manifest check)
Takeover over platforms: / install_if blocks (backlog 4)	covered by PR #776's generic gate

Issues

• Commented on 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 (Bundler 4.1 quotes URL-scoped mirror keys, and PR Fix hosted gem redirect ignoring Bundler mirror.all (#681) #684 misses them): 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 (comment)
• No new issues filed: nothing on main failed the filing bar.

False positives ruled out

• Gem dir names that contain -<digits>.<…> (citus-rails-4.2, cvss-to-3.1, and 30 more out of 197k names on rubygems.org) are misparsed by parse_dir_name_version's last-dotted-boundary rule. That's 32 obscure gems with no plausible patches, so it isn't filed.
• Bundler 4.1's new override Gemfile DSL can't silently unpatch a hosted pin: the pinned source … do block only serves the patched version, so any conflicting override fails loudly. It also isn't counted as a declaration (declaration_re needs gem).
• Bundler 4.1 content-addressed gems (gems/<name>-<ver>-<hex8+>, CONTENT ADDRESSES lock section) need RubyGems 4.1 and gems published that way. parse_dir_name_version / locate_gem_dir already drop the hex suffix like a platform. Untested end to end.

Next

1. Re-run 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 stale-install warning calls the project's own vendor/bundle a "shared gem home" when --cwd is left at its default (or relative), so it gives the wrong remedy and drops the committed cache archive from the delete list #729 / Hosted gem redirect ignores Bundler 4's custom lockfile (lockfile setting / BUNDLE_LOCKFILE), so it never pins the lock Bundler uses and frozen installs fail with no warning #749 / Hosted gem redirect wires gems.rb in a Gemfile/gems.rb twin locked by Bundler 1.17, which loads Gemfile, so the install stays unpatched while the in-run VEX attests it #751 / Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775 / Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826 / Gem BUNDLE_GEMFILE check compares paths lexically, so a symlinked spelling of the project's own Gemfile (e.g. macOS /tmp/app/Gemfile) is refused, and vex / rollback reject the hosted patch Bundler is loading #896 / Gem crawler ignores Bundler's path.system: true when a leftover vendor/bundle exists, so agent apply patches the unused copy and vex attests not_affected while Bundler loads the unpatched system gem #915 when fixes merge (open PRs Fix hosted gem redirect ignoring Bundler mirror.all (#681) #684, Fix gem pair model ignoring custom lockfile and Bundler 1 twins (#749, #751) #768, Fix gem takeover un-hosting a grouped gem (#775) #776, Fix gem rewrite deleting a ;-joined declaration (#826) #875, Fix gem crawl ignoring Bundler path.system (#915) #916).
2. RubyGems 4.1 + Bundler 4.1 (setup-ruby probe with rubygems: 4.1.0.beta1): content-addressed installs, the CONTENT ADDRESSES lock section through a hosted rewrite and rollback, specifications/<abi>/ layout for agent vex.
3. Hosted 4.1 cells by hand: override "x", version: next to a hosted pin, then rollback; .bundle/config written by 4.1 with a BUNDLE_GEMFILE value that needs quoting.
4. Windows x64-mingw-ucrt platform gems in hosted and vendored modes.
5. Bundler 1.17 hosted unwind (Ruby ≤ 3.1 probe); rollback / remove on a custom-lock project.

[github-actions[bot]]

[agent] Janitor: state drift for the bug-hunt routine to pick up (this ledger body is not edited).

#709 (gem VEX ignoring an out-of-tree bundle path) was closed as completed by PR #712 (merge a49427ec, 2026-10-05 18:16Z). The Ruby 3.3.6 rows for Bundler 4.0.17, 2.6.9 and 2.4.22 still say fail #709.

---

Generated by Claude Code

[github-actions[bot]]

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

Tested: main 9c43dfc (unchanged since run 22), latest release v4.0.0 (the npm @socketsecurity/socket-patch-linux-x64-gnu@4.0.0 binary was used to bisect). Linux sandbox, Ruby 3.3.6, Bundler 4.1.0.beta1 / 4.0.22 / 2.6.9 / 2.5.22 / 2.4.22. No probe branches: both findings are OS-independent config and path resolution.

Setup (no mock API): agent cells use a hand-written .socket/manifest.json + blob for colorize@0.8.1 (lib/colorize.rb plus a marker line), then apply --offline, vex --product, and a real bundle install / bundle exec to see which copy loads. A system copy of colorize 0.8.1 was present on purpose; each cell ran gem pristine before and after. The stale-guard cell was a one-line case added to e2e_redirect_gem_stale_install.rs locally and then reverted.

Re-triage

• Main hasn't moved and no gem fix PR has merged, so the open issues weren't re-run.
• Janitor drift: 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 (Fix gem VEX ignoring out-of-tree bundle path (#709) #712), Lock inventory reads only Gemfile.lock, so a gems.rb project's gems.locked is invisible and a stale Gemfile.lock is read instead #736 (Fix gem lock readers ignoring gems.locked (#736) #750) 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 (Fix gem source-option guard missing git sources (#652) #731) are closed. Their fail cells are now fixed in the state body.

Cells

Cell	Result
Agent: BUNDLE_PATH: .gems # project-local gems in .bundle/config (Bundler 4.1.0.beta1 / 4.0.22 ×2 / 2.6.9 / 2.4.22)	fail → #951: Bundler strips the comment and installs into .gems/. The crawler takes the path literally, patches the system copy, and vex attests not_affected while .gems/ loads unpatched
Same, without the comment (control)	pass
Hosted stale guard: BUNDLE_CACHE_PATH: vendor/gems # … + stale archive	fail → #951 (comment): no redirect_gem_stale_install, and the scan reports success (2/2). Bundler 4.0.22 and 2.4.22 really use vendor/gems (Bundler.app_cache)
v4.0.0 release, same agent cell	fail (not a regression)
Agent: env BUNDLE_GEMFILE=gemfiles/alt.gemfile, path vendor/bundle in gemfiles/.bundle/config (4.0.22 ×2, 2.6.9)	fail → #952: Bundler installs into gemfiles/vendor/bundle (Bundler.root moves). The crawler patches the system copy and vex attests not_affected
Agent: env BUNDLE_GEMFILE=gemfiles/alt.gemfile + env BUNDLE_PATH=vendor/bundle (4.0.22, 2.6.9)	fail → #952
RubyGems 4.1.0.beta1 content addressing (source read)	only for platform gems pinned to one ABI. None are published that way yet, so no end-to-end cell is possible

Issues

• Filed Gem .bundle/config reader keeps a trailing # comment in the value, so a commented BUNDLE_PATH is missed, agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched project copy #951: Gem .bundle/config reader keeps a trailing # comment in the value, so a commented BUNDLE_PATH is missed, agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched project copy #951 (plus a follow-up comment with the stale-guard evidence: Gem .bundle/config reader keeps a trailing # comment in the value, so a commented BUNDLE_PATH is missed, agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched project copy #951 (comment))
• Filed Gem agent crawl ignores that BUNDLE_GEMFILE=gemfiles/x.gemfile moves Bundler.root, so a relative bundle path resolves to the wrong dir, apply patches the system copy and vex attests not_affected while Bundler loads the unpatched gemfiles/vendor/bundle copy #952: Gem agent crawl ignores that BUNDLE_GEMFILE=gemfiles/x.gemfile moves Bundler.root, so a relative bundle path resolves to the wrong dir, apply patches the system copy and vex attests not_affected while Bundler loads the unpatched gemfiles/vendor/bundle copy #952

False positives ruled out

• BUNDLE_PATH: ".gems" # c (quoted value + comment) and a quoted value with trailing spaces: Bundler's own loader keeps the quotes and breaks too, so it's not socket-patch's divergence.
• inspect-escaped values (Windows backslashes, \u…): neither Bundler nor socket-patch unescapes them, so they agree.
• setup-ruby bundler-cache with a matrix BUNDLE_GEMFILE: it records an absolute $PWD/vendor/bundle, which the default probe finds. Only relative paths hit Gem agent crawl ignores that BUNDLE_GEMFILE=gemfiles/x.gemfile moves Bundler.root, so a relative bundle path resolves to the wrong dir, apply patches the system copy and vex attests not_affected while Bundler loads the unpatched gemfiles/vendor/bundle copy #952.

Next

1. Re-run 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 stale-install warning calls the project's own vendor/bundle a "shared gem home" when --cwd is left at its default (or relative), so it gives the wrong remedy and drops the committed cache archive from the delete list #729 / Hosted gem redirect ignores Bundler 4's custom lockfile (lockfile setting / BUNDLE_LOCKFILE), so it never pins the lock Bundler uses and frozen installs fail with no warning #749 / Hosted gem redirect wires gems.rb in a Gemfile/gems.rb twin locked by Bundler 1.17, which loads Gemfile, so the install stays unpatched while the in-run VEX attests it #751 / Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775 / Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826 / Gem BUNDLE_GEMFILE check compares paths lexically, so a symlinked spelling of the project's own Gemfile (e.g. macOS /tmp/app/Gemfile) is refused, and vex / rollback reject the hosted patch Bundler is loading #896 / Gem crawler ignores Bundler's path.system: true when a leftover vendor/bundle exists, so agent apply patches the unused copy and vex attests not_affected while Bundler loads the unpatched system gem #915 / Gem .bundle/config reader keeps a trailing # comment in the value, so a commented BUNDLE_PATH is missed, agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched project copy #951 / Gem agent crawl ignores that BUNDLE_GEMFILE=gemfiles/x.gemfile moves Bundler.root, so a relative bundle path resolves to the wrong dir, apply patches the system copy and vex attests not_affected while Bundler loads the unpatched gemfiles/vendor/bundle copy #952 when fixes merge (open PRs Fix hosted gem redirect ignoring Bundler mirror.all (#681) #684, Fix gem pair model ignoring custom lockfile and Bundler 1 twins (#749, #751) #768, Fix gem takeover un-hosting a grouped gem (#775) #776, Fix gem rewrite deleting a ;-joined declaration (#826) #875, Fix gem crawl ignoring Bundler path.system (#915) #916).
2. Gem agent crawl ignores that BUNDLE_GEMFILE=gemfiles/x.gemfile moves Bundler.root, so a relative bundle path resolves to the wrong dir, apply patches the system copy and vex attests not_affected while Bundler loads the unpatched gemfiles/vendor/bundle copy #952 neighbours: hosted stale guard and vex with cache_path in gemfiles/.bundle/config; relative BUNDLE_APP_CONFIG under a moved root.
3. Windows x64-mingw-ucrt platform gems, hosted and vendored.
4. Bundler 1.17 hosted unwind (Ruby ≤ 3.1 probe).

[github-actions[bot]]

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

Tested: main 9c43dfc (unchanged since run 22), latest release v4.0.0. Linux sandbox, Ruby 3.3.6, Bundler 4.0.22 / 2.6.9 / 2.5.22. No probe branches: the finding is OS-independent path discovery.

Setup: the same as run 25. Agent cells use a hand-written .socket/manifest.json + blob for colorize@0.8.1 (lib/colorize.rb plus a marker line), then apply --offline, vex --product … -O, and a real bundle install / bundle exec to see which copy loads. A system copy is present on purpose, and each cell runs gem pristine before and after.

Re-triage

• Main hasn't moved, so the open issues weren't re-run on main.
• Gem .bundle/config reader keeps a trailing # comment in the value, so a commented BUNDLE_PATH is missed, agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched project copy #951: verified the new PR Fix .bundle/config values keeping a trailing # comment (#951) #953 at head 52542db. The original agent repro (BUNDLE_PATH: .gems # comment, 4.0.22) now patches the loaded .gems copy. Comment: Gem .bundle/config reader keeps a trailing # comment in the value, so a commented BUNDLE_PATH is missed, agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched project copy #951 (comment)

Cells

Cell	Result
Agent: local simulate_version 5 (4.0.22 ×2)	fail → #967: Bundler installs into <root>/.bundle/ruby/3.3.0/gems. The crawler never probes it, patches the system copy, and vex attests not_affected
Agent: env BUNDLE_SIMULATE_VERSION=5 (4.0.22)	fail → #967
Agent: local default_install_uses_path true (2.6.9 ×2, 2.5.22)	fail → #967
Agent: env BUNDLE_DEFAULT_INSTALL_USES_PATH=true (2.6.9)	fail → #967
Agent: no setting (control, 4.0.22)	pass
PR #953 on the #967 shape	still fails (expected: it's a different root)

Issues

• Filed Gem crawler ignores Bundler's .bundle default install path (default_install_uses_path on 2.x, simulate_version 5 on 4.x), so agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched .bundle/ruby/<abi> copy #967: Gem crawler ignores Bundler's .bundle default install path (default_install_uses_path on 2.x, simulate_version 5 on 4.x), so agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched .bundle/ruby/<abi> copy #967
• Commented on Gem .bundle/config reader keeps a trailing # comment in the value, so a commented BUNDLE_PATH is missed, agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched project copy #951 (PR Fix .bundle/config values keeping a trailing # comment (#951) #953 verification).

False positives ruled out

• None this run. The control (system install, no setting) patches the loaded copy.

Next

1. Re-run 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 stale-install warning calls the project's own vendor/bundle a "shared gem home" when --cwd is left at its default (or relative), so it gives the wrong remedy and drops the committed cache archive from the delete list #729 / Hosted gem redirect ignores Bundler 4's custom lockfile (lockfile setting / BUNDLE_LOCKFILE), so it never pins the lock Bundler uses and frozen installs fail with no warning #749 / Hosted gem redirect wires gems.rb in a Gemfile/gems.rb twin locked by Bundler 1.17, which loads Gemfile, so the install stays unpatched while the in-run VEX attests it #751 / Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775 / Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826 / Gem BUNDLE_GEMFILE check compares paths lexically, so a symlinked spelling of the project's own Gemfile (e.g. macOS /tmp/app/Gemfile) is refused, and vex / rollback reject the hosted patch Bundler is loading #896 / Gem crawler ignores Bundler's path.system: true when a leftover vendor/bundle exists, so agent apply patches the unused copy and vex attests not_affected while Bundler loads the unpatched system gem #915 / Gem .bundle/config reader keeps a trailing # comment in the value, so a commented BUNDLE_PATH is missed, agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched project copy #951 / Gem agent crawl ignores that BUNDLE_GEMFILE=gemfiles/x.gemfile moves Bundler.root, so a relative bundle path resolves to the wrong dir, apply patches the system copy and vex attests not_affected while Bundler loads the unpatched gemfiles/vendor/bundle copy #952 / Gem crawler ignores Bundler's .bundle default install path (default_install_uses_path on 2.x, simulate_version 5 on 4.x), so agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched .bundle/ruby/<abi> copy #967 when fixes merge (open PRs Fix hosted gem redirect ignoring Bundler mirror.all (#681) #684, Fix gem pair model ignoring custom lockfile and Bundler 1 twins (#749, #751) #768, Fix gem takeover un-hosting a grouped gem (#775) #776, Fix gem rewrite deleting a ;-joined declaration (#826) #875, Fix gem crawl ignoring Bundler path.system (#915) #916, Fix .bundle/config values keeping a trailing # comment (#951) #953).
2. Gem crawler ignores Bundler's .bundle default install path (default_install_uses_path on 2.x, simulate_version 5 on 4.x), so agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched .bundle/ruby/<abi> copy #967 neighbours: the hosted stale guard with a stale .bundle/ruby/<abi> materialization (it shares the discovery); rollback under simulate_version 5; and whether simulate_version 5 changes anything else socket-patch models (lockfile / CHECKSUMS defaults).
3. Gem agent crawl ignores that BUNDLE_GEMFILE=gemfiles/x.gemfile moves Bundler.root, so a relative bundle path resolves to the wrong dir, apply patches the system copy and vex attests not_affected while Bundler loads the unpatched gemfiles/vendor/bundle copy #952 neighbours: hosted stale guard and vex with cache_path in gemfiles/.bundle/config.
4. Windows x64-mingw-ucrt platform gems, hosted and vendored.
5. Bundler 1.17 hosted unwind (Ruby ≤ 3.1 probe).

[github-actions[bot]]

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

Tested: main 9c43dfc (unchanged since run 22), latest release v4.0.0. Linux sandbox, Ruby 3.3.6, Bundler 4.0.22 / 4.0.17 / 4.0.10 / 4.0.0 / 2.7.2 / 2.6.9. No probe branches: the finding is OS-independent lock text. No new Bundler release since 4.0.22 (4.1.0.beta1 is still the newest pre-release).

Setup: throwaway copies of e2e_redirect_gem_build.rs (hosted; mock upstream + patch registry) and e2e_vendor_gem_build.rs (vendored; real rubygems.org rack), with the fixture project switched to a gemspec library (mylib.gemspec + lib/). Both were deleted afterwards. The fresh checkout copies the gemspec and lib/ too.

Re-triage

• Main hasn't moved, so the open issues weren't re-run. No human replies on the discussion.

Cells

Cell	Result
Hosted: gemspec add_development_dependency, no Gemfile line (4.0.22, CHECKSUMS)	pass (fails closed: redirect_gem_declaration_not_visible, which names gemspecs)
Hosted: gemspec dev dep + Gemfile gem line in a group block, CHECKSUMS lock → fresh BUNDLE_FROZEN install	fail → #985 on 4.0.22 (×2), 4.0.17, 4.0.10, 4.0.0, 2.7.2. The lock gets x (= v)!, but Bundler 2.7+ expects the merged x (>= 0, = v)! (exit 16). No warning is emitted. 2.6.9 passes
Hosted: same, gem "x", "~> 1.0", group: :development (4.0.22)	fail → #985
Hosted: gemspec runtime dep + Gemfile line (4.0.22)	pass (frozen install OK)
Vendored: gemspec dev dep (>= 3) + Gemfile gem "rack", "~> 3.1" → fresh frozen install	fail → #985 on 4.0.22 (×2) and 2.7.2; 2.6.9 passes the frozen install
Published v4.0.0 binary on the hosted shape	same (= v)! pin (not a regression; the trigger is Bundler 2.7's requirement merge)
.bundle/config parser vs Bundler 4 YAMLSerializer (code read)	no new divergence worth filing. KEY:"v" (no space) is ignored by Bundler; # inside a quoted value is truncated by Bundler itself
Bundler 4 Settings#path with disable_shared_gems: false + leftover vendor/bundle	#915 family; PR #916 already handles disable_shared_gems

Issues

• Filed Gem hosted and vendored lock pins ignore a gemspec development dependency on the same gem, so on Bundler 2.7+ the rewritten Gemfile.lock fails every frozen install ((= v)! vs Bundler's merged (>= 0, = v)!) #985: Gem hosted and vendored lock pins ignore a gemspec development dependency on the same gem, so on Bundler 2.7+ the rewritten Gemfile.lock fails every frozen install ((= v)! vs Bundler's merged (>= 0, = v)!) #985

False positives ruled out

• Vendored on 2.6.9 panicked in the harness's lock-only-revert leg: "There are no gemspecs". The scratch copy didn't carry mylib.gemspec, so that's a harness artifact; the frozen fresh install passed.
• v4.0.0 panicked in the harness's no-ledger check (v4 still wrote a ledger). It isn't relevant; its lock pin matched main's.

Next

1. Re-run 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 stale-install warning calls the project's own vendor/bundle a "shared gem home" when --cwd is left at its default (or relative), so it gives the wrong remedy and drops the committed cache archive from the delete list #729 / Hosted gem redirect ignores Bundler 4's custom lockfile (lockfile setting / BUNDLE_LOCKFILE), so it never pins the lock Bundler uses and frozen installs fail with no warning #749 / Hosted gem redirect wires gems.rb in a Gemfile/gems.rb twin locked by Bundler 1.17, which loads Gemfile, so the install stays unpatched while the in-run VEX attests it #751 / Gem hosted → vendored takeover un-hosts a gem declared inside a group block and then refuses to vendor it (gemfile_declaration_not_editable), so the project silently goes back to unpatched #775 / Gem hosted and vendored rewrites delete a second gem declaration that shares the patched gem's line after ;, so the next bundle install drops that dependency #826 / Gem BUNDLE_GEMFILE check compares paths lexically, so a symlinked spelling of the project's own Gemfile (e.g. macOS /tmp/app/Gemfile) is refused, and vex / rollback reject the hosted patch Bundler is loading #896 / Gem crawler ignores Bundler's path.system: true when a leftover vendor/bundle exists, so agent apply patches the unused copy and vex attests not_affected while Bundler loads the unpatched system gem #915 / Gem .bundle/config reader keeps a trailing # comment in the value, so a commented BUNDLE_PATH is missed, agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched project copy #951 / Gem agent crawl ignores that BUNDLE_GEMFILE=gemfiles/x.gemfile moves Bundler.root, so a relative bundle path resolves to the wrong dir, apply patches the system copy and vex attests not_affected while Bundler loads the unpatched gemfiles/vendor/bundle copy #952 / Gem crawler ignores Bundler's .bundle default install path (default_install_uses_path on 2.x, simulate_version 5 on 4.x), so agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched .bundle/ruby/<abi> copy #967 / Gem hosted and vendored lock pins ignore a gemspec development dependency on the same gem, so on Bundler 2.7+ the rewritten Gemfile.lock fails every frozen install ((= v)! vs Bundler's merged (>= 0, = v)!) #985 when fixes merge (open PRs Fix hosted gem redirect ignoring Bundler mirror.all (#681) #684, Fix gem pair model ignoring custom lockfile and Bundler 1 twins (#749, #751) #768, Fix gem takeover un-hosting a grouped gem (#775) #776, Fix gem rewrite deleting a ;-joined declaration (#826) #875, Fix gem crawl ignoring Bundler path.system (#915) #916, Fix .bundle/config values keeping a trailing # comment (#951) #953).
2. Gem hosted and vendored lock pins ignore a gemspec development dependency on the same gem, so on Bundler 2.7+ the rewritten Gemfile.lock fails every frozen install ((= v)! vs Bundler's merged (>= 0, = v)!) #985 neighbours: hosted rollback on the gemspec dev-dep shape (the exact-pin restore gem "x", "<v>" then merges to (>= 0, = v) against the restored lock, so a frozen install may fail); get <uuid> --mode hosted; H→V takeover on that shape.
3. Gem crawler ignores Bundler's .bundle default install path (default_install_uses_path on 2.x, simulate_version 5 on 4.x), so agent apply patches the system copy and vex attests not_affected while Bundler loads the unpatched .bundle/ruby/<abi> copy #967 neighbours: hosted stale guard with a stale .bundle/ruby/<abi> copy; rollback under simulate_version 5.
4. Gem agent crawl ignores that BUNDLE_GEMFILE=gemfiles/x.gemfile moves Bundler.root, so a relative bundle path resolves to the wrong dir, apply patches the system copy and vex attests not_affected while Bundler loads the unpatched gemfiles/vendor/bundle copy #952 neighbours: hosted stale guard and vex with cache_path in gemfiles/.bundle/config.
5. Windows x64-mingw-ucrt platform gems (hosted and vendored); Bundler 1.17 hosted unwind (Ruby ≤ 3.1 probe).