Bug hunt ledger: Bundler (RubyGems) #316

Mikola Lysenko (mikolalysenko) · 2026-09-30T14:23:48Z

Mikola Lysenko (mikolalysenko)
Sep 30, 2026
Maintainer

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

Last updated: 2026-10-16 (run 45), main 657fce2, latest release v5.0.1 (npm; no git tags). Newest Bundler tested: 4.1.0.beta2; newest stable 4.0.23 (full gem suites pass, run 45).

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

Run 28 (main `9c43dfc`; Linux Ruby 3.3.6; hosted mock + real rubygems.org upstream)

Cell	4.0.22	2.6.9
Hosted stale guard: config/env `path vendor/bundle` not installed + unused system copy	fail #1001 (×3; also v4.0.0, PR #968)	fail #1001
Hosted stale guard: `simulate_version 5`, unpatched `.bundle` install	fail #967 (false VEX; PR #968 pass)	—
Agent #967 shapes on PR #968 `25e3ca6`	pass	pass
Hosted gemspec dev-dep: converge → `rollback` → frozen install	pass	—
Hosted transitive via `git:` gem: cycle + `rollback`	pass (lock byte-identical)	—
Agent env `BUNDLE_PATH='~/x'`	pass	—

Run 29 (main `d47eab3`; Linux Ruby 3.3.6; hosted mock + real rubygems.org upstream, agent hand-written manifest)

Cell	4.0.22	2.6.9
Re-triage #951 agent shape (`BUNDLE_PATH: .gems # comment`)	still fails #951	—
Re-triage #952 agent shape (`BUNDLE_GEMFILE=gemfiles/alt.gemfile`)	still fails #952	—
Hosted: `~> 1.0` locked at 1.1.0, 0.8.1 only in the shared system gem home	fail #1055 (×2; also v4.0.0)	fail #1055
Hosted: same, transitive via a path gem (`~> 1.0`)	fail #1055 (unresolvable)	—
Hosted unwind: gem inside `source "https://rubygems.org" do` (4 shapes), `rollback` and `remove`	fail #1056 (×2)	fail #1056
Hosted cycle + rollback: prerelease `1.0.0.pre.1`	pass	—
Hosted cycle + rollback: `ruby "3.3.6"` / `ruby file:` / `# frozen_string_literal` / trailing `;` / `; # c` (#875)	pass	—
Hosted cycle + rollback: `install_if` / `platforms` / `group :a, :b` / `env` blocks	pass (lock byte-restored)	—
Hosted: `source: "https://rubygems.org"` option	pass (refused, documented)	—
Repo gem e2e suites	pass (redirect 32 / vendor 22 / stale 33)	—

Run 30 (main `05ecc6e`; Linux; agent hand-written manifest + `apply --offline`; real `bundle install` / `bundle exec`)

Cell	Ruby 3.3.6 / Bundler 4.0.18	Ruby 3.1.6 / Bundler 2.6.9
Agent: `ffi-1.17.2/` + `ffi-1.17.2-x86_64-linux-gnu/` in `vendor/bundle` (`force_ruby_platform` toggled), unqualified and `?platform=x86_64-linux-gnu` keys	fail #1092 (×2)	—
Agent: same pair in a shared `GEM_HOME` (`gem install --platform ruby` + default)	fail #1092	fail #1092
Global `apply -g` on the same pair	fail #1092 (comment)	—
Re-triage #952 (`BUNDLE_GEMFILE=gemfiles/alt.gemfile`, root Gemfile present)	still fails #952	—
#952 variant without a root `Gemfile`	pass (nothing applied, `vex` writes nothing)	—
Bisect #1092 on v4.0.0	also patches only the ruby dir (pre-v5)	—

Run 31 (main `05fd82b`; Linux Ruby 3.3.6; hosted stale guard via the `e2e_redirect_gem_stale_install.rs` harness, ×2 incl. real `gem env`; real `bundle install` for Bundler's own behaviour)

Cell	4.0.18	2.5.22
Hosted stale guard, explicit `path` not installed + unused system copy (#1001 fix)	pass	—
Same, local `deployment true` (no `path`)	fail #1109 (real Bundler installs into `vendor/bundle`)	—
Same, env `BUNDLE_DEPLOYMENT=true`	fail #1109	real Bundler installs into `vendor/bundle`
Same, `simulate_version 5` / `default_install_uses_path true`	fail #1109 (real Bundler installs into `.bundle`)	—
Control: no setting (system gems)	pass (warns)	—

Run 32 (main `b96a785`; Linux Ruby 3.3.6; agent hand-written manifest + `apply --offline` / `apply --check`; hosted via a scratch copy of `e2e_redirect_gem_build.rs` with real `bundle install`)

Cell	4.0.18	2.5.22
Repo gem e2e suites (redirect 32 / stale 37 / vendor 22 / multi-platform 7)	pass	—
Agent `apply --check`: system install / #915 / #967 / #951 / out-of-tree config + env path shapes	pass	—
Agent `apply --check`: #952 shape	fail #952	—
Agent `apply --check`: #1092 dual-platform pair (both key spellings); `rollback`	fail #1092; rollback pass	—
Hosted, lockless Gemfile `~> 2.0`, older version only in the shared home	fail #1125	fail #1125
Hosted, lockless Gemfile not declaring the shared-home gem	fail #1125	fail #1125

Run 33 (main `823810a`; Linux Ruby 3.3.6; scratch copy of `e2e_redirect_gem_build.rs`, real `bundle install`)

Cell	4.0.18
Hosted `lockfile custom.lock` via `.bundle/config` + leftover `Gemfile.lock` (#749 fixture)	pass (refused)
Hosted `Gemfile` + `gems.rb` twin (#751 fixture)	pass (refused)
Hosted Gemfile DSL `lockfile "custom.lock"` + leftover `Gemfile.lock`	fail, #749 gap (commented; ×2)

Run 34 (main `cb16bdd`; Linux Ruby 3.3.6; scratch copies of `e2e_redirect_gem_build.rs`, real `bundle install`, CHECKSUMS lock)

Cell	4.0.22	4.0.18
Hosted 1-gem superseding patch (new uuid, same version): re-scan, stale warning, cold frozen install of gen B, `vex`	—	pass
Hosted 2-gem re-scan, sorted section insert	pass	pass
Hosted 2-gem re-scan superseding one gem to a later-sorting uuid	fixed #1186 (#1190)	lock re-sorted by Bundler (warning only)

Run 35 (main `f3c6313`; Linux Ruby 3.3.6; scratch copies of `e2e_redirect_gem_build.rs`; rollout cap)

Cell	4.1.0.beta2	4.0.22	2.5.22
Repo gem e2e suites (redirect 35 / stale 37 / vendor 41 / multi-platform 7)	pass	—	—
Hosted, no-CHECKSUMS lock, re-scan `--max-new-patches 0`	—	fail #1224	fail #1224
Hosted, 2 gems, no-CHECKSUMS lock, `--max-new-patches 1` ×4	—	fail #1224 (starves)	fail #1224 (first bad `4d06019`)
Same, CHECKSUMS lock	—	pass	n/a
Hosted superseding patch under `--max-new-patches 0`, no-CHECKSUMS	—	—	fail (#1224 comment; predates #1058)
Same, CHECKSUMS lock	—	pass (`upgrade: 1`)	—

Run 36 (main `a80b89e`; Linux Ruby 3.3.6; 3–4 gem hosted mock + real rubygems.org upstream)

Cell	4.1.0.beta2	4.0.22	2.6.9	2.5.22
Hosted 3 gems CHECKSUMS: `rollback` first / middle / last / all, `remove` middle → frozen install	pass (middle)	pass	pass (middle)	—
Unfrozen install between scan and `rollback`	pass	—	pass	—
Patched gem with deps (`rack-test` → `rack`) cycle + `rollback`	—	pass	—	—
In-run `--vex` with 1 of 3 refused	—	pass	—	—
#1224 fix, capped re-scan `Gemfile` / `gems.rb` / lockless	—	—	—	pass
`bundle cache` after scan → `rollback` / `remove`	fixed #1260 (#1263)	fixed #1260 (#1263, run 37)	fixed #1260 (#1263)	fixed #1260 (#1263)

Run 37 (main `a8e9397`, v5.0.0; Linux Ruby 3.3.6)

Cell	4.0.18	2.6.9	2.5.22	2.4.22	2.3.27
#1260 fix: hosted `bundle cache` → `rollback <bare name>` / `remove <versionless purl>` / `rollback VULN-GEM` / bare `rollback` (#1034 target grammar)	pass (`upstream_gem_stale_cache` names the archive)	—	—	—	—
#1260 fix with config `cache_path vendor/gems`	pass	—	—	—	—
v4 `setup` plugin registered, then the v5 cleanup commit lands (block + `.socket/bundler-plugin/` removed)	warning on every install (#1295)	warning on every install (#1295)	fail #1295 (`LoadError`)	fail #1295	fail #1295
Migrator's own checkout following migrating-to-v5.md (incl. `bundle plugin uninstall`)	pass	—	—	—	—
v4.0.0 hosted scan → v5 re-scan (lock byte-identical) → v5 `rollback`	—	—	pass (documented exact pin)	—	—

Run 38 (main `6ad6add`, v5.0.0; Linux Ruby 3.3.6; agent hand-written manifest + `apply --offline` / `vex` / `rollback`, real `bundle install` / `bundle exec`; hosted via a scratch copy of `e2e_redirect_gem_build.rs`)

Cell	4.0.22	4.0.18	2.6.9	2.5.22	2.3.27
#952 fix: env `BUNDLE_GEMFILE=gemfiles/alt.gemfile` + `gemfiles/.bundle/config` path	—	pass	—	pass	—
#952 neighbours: root-config `gemfile` (+ gemfiles path / + root-only path), env `BUNDLE_PATH` relative, `gemfiles` deployment, absolute env gemfile	—	pass	—	—	—
#952 neighbours: `gemfiles/gems.rb`, leftover unpatched root `vendor/bundle` (left untouched)	pass	—	—	—	—
#1092 fix: `ffi-1.17.2/` + `ffi-1.17.2-x86_64-linux-gnu/` in one home: apply both / runtime / `vex` / `rollback` both	pass	—	—	—	—
#1295 fix: real Bundler-written stale `plugin/index` → `apply` `gem_bundler_plugin_stale`	—	pass	—	pass	pass
#1056 fix: source-block unwind (plain / CRLF)	pass	pass	pass	—	—
#1056 gap: `v = if … end` / `v = case … end` inside the user's `source … do` block → unwind drops `!`	fail (#1056 comment; exit 16 with CHECKSUMS)	fail (×2)	fail	—	—
macOS / Windows probe (#952 backslash spelling, #1092 ucrt pair, #1295)	blocked: probe branch pushed, no Actions run triggered

Run 39 (main `15c2c83`, v5.0.0; Linux Ruby 3.3.6; scratch copies of `e2e_redirect_gem_build.rs`, real `bundle install`)

Cell	4.0.22	4.0.18
`v = if … end` in the user's `source … do` block → `rollback` keeps the `!`	fail #1476	fail #1476
Same → frozen install of the restored pair	fail #1476 (exit 16)	pass (warning only)
Gemfile `lockfile "custom.lock"` DSL → hosted scan refused	fail #1477	fail #1477

Run 40 (main `aa85c6c`, v5.0.1; Linux Ruby 3.3.6; scratch copy of `gem_hosted_unwind_keeps_a_source_block_bang`, real `bundle install`)

Cell	4.0.22	2.6.9
#1476 fix: `x = while/until/unless … end`, endless def, one-line `x = if … then … end` in a source block (unit probe)	pass	—
Paren multi-line `source(\n "…"\n) do` → `rollback` / `remove` keeps the `!`	fail #1509 (exit 16)	fail #1509 (warning)
Brace `source("…") { … }` → `rollback` / `remove`	fail #1509 (exit 16, Gemfile not byte-restored)	fail #1509

Run 41 (main `a8da202`, v5.0.1; Linux Ruby 3.3.6; scratch copies of `e2e_redirect_gem_build.rs` / `e2e_vendor_gem_build.rs`, real `bundle install`)

Cell	4.0.23
Repo gem e2e suites (redirect 51 / stale 42 / vendor 43 / multi-platform 27)	pass
#1509 fix: multi-line `source(` opener / brace block → `rollback` / `remove` → frozen install	pass
`zz = 1; source "…" do` → `rollback` / `remove`	fail #1531 (frozen exit 16)
`in_source_block` unit probe, 52 other shapes	pass
Vendored + Gemfile `lockfile "custom.lock"` / `lockfile false`	pass (refused `gemfile_not_loaded`)
Vendored + `lockfile "Gemfile.lock"`	pass

Run 42 (main `015e871`, v5.0.1; Linux Ruby 3.3.6; scratch copies of `gem_hosted_unwind_keeps_a_source_block_bang`, real `bundle install`)

Cell	4.1.0.beta2	4.0.23	2.6.9	2.4.22
Repo gem e2e suites (redirect 51 / stale 42 / vendor 43)	—	pass	—	—
#1531 fix + all 10 source-block unwind shapes → frozen install	pass	pass	pass	pass
#1531 neighbours: `;`-opener inside `group … do`, `source … do end; source … do`, `if true; source … do`	—	pass	—	—
`in_source_block` unit probe, 64 shapes	63 pass (`self.source` miss, see Known non-bugs)

Run 43 (main `e76cb9b`, v5.0.1; Linux Ruby 3.3.6, Bundler 2.5.22; agent hand-written manifest + `apply --offline` / `vex`, real `bundle install`)

Cell	Result
Docker-style `GEM_HOME` = `BUNDLE_APP_CONFIG` = one dir, committed project `.bundle/config` `BUNDLE_PATH: vendor/bundle` (ignored by Bundler) → agent `apply` patches the `GEM_HOME` copy, `vex` attests	pass
Same, `$BUNDLE_APP_CONFIG/config` sets a `BUNDLE_PATH` with no install → `vex` refuses	pass
Gemspec product: commented `# spec.version = "…"` above `spec.version = Acme::VERSION`	fail #1573 (`pkg:gem/acme@0.0.1`)
Gemspec product: commented `# spec.name = "…"` above the real one	fail #1573

Run 44 (main `657fce2`, v5.0.1; Linux Ruby 3.3.6; scratch copies of `e2e_redirect_gem_stale_install.rs` / `e2e_redirect_gem_build.rs`, real `bundle install` / `bundle cache`)

Cell	4.0.18	2.5.22
#1573 fix (#1582): commented / `=begin` / heredoc `spec.name` / `spec.version`, last assignment wins	pass (closed)	—
Docker layout hosted stale guard (`GEM_HOME` = `BUNDLE_APP_CONFIG`): project `.bundle/config` `BUNDLE_PATH` / `BUNDLE_DEPLOYMENT` ignored → shared-home warning + not attested; same keys in `$BUNDLE_APP_CONFIG/config` → quiet + attested (6 variants)	pass	—
H→V takeover over a patched `vendor/cache` archive → takeover advisory `upstream_gem_stale_cache`	pass	pass
Same → `vendor --revert` / `remove` / `rollback` of the vendored gem → no warning, fresh frozen install keeps patched bytes	fail #1594	fail #1594
H→V takeover on a CHECKSUMS lock with a non-rubygems.org upstream	pass (refused `redirect_revert_failed`, documented)	—

Run 45 (main `657fce2`, v5.0.1; Linux Ruby 3.3.6; the repo's real-Bundler suites with `SOCKET_PATCH_BUNDLER_E2E_REQUIRED=1`)

Suite	4.0.23	2.7.2
`e2e_redirect_gem_build` (hosted, 51 tests)	pass	pass
`e2e_redirect_gem_stale_install` (42 tests)	pass	pass
`e2e_vendor_gem_build` (vendored, 43 tests)	pass	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

Re-run 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 / Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109 (agent:needs-human) and Gem vendored remove / rollback / vendor --revert after a hosted→vendored takeover leave the patched .gem in vendor/cache with no warning, so fresh installs of the restored upstream lock keep installing patched bytes #1594 when fixes merge.
Gem vendored remove / rollback / vendor --revert after a hosted→vendored takeover leave the patched .gem in vendor/cache with no warning, so fresh installs of the restored upstream lock keep installing patched bytes #1594 CHECKSUMS arm against real rubygems.org (needs an upstream the takeover can re-derive a checksum for; the mock upstream is refused).
V→H→V round trips with a committed vendor/cache (does a hosted re-pin leave the vendored-era cache consistent?).
Windows / macOS probe (Actions didn't trigger in run 38; leftover probe branches can't be deleted from the sandbox): 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 with BUNDLE_GEMFILE=gemfiles\alt.gemfile, Gem agent apply patches only the ruby-platform x-1.0/ dir when a x-1.0-x86_64-linux-gnu/ sibling is also installed, so Bundler loads the unpatched platform gem while vex attests not_affected #1092 x64-mingw-ucrt / arm64-darwin pairs, the Hosted gem rollback / remove leave the patched .gem in the project's committed vendor/cache, so every later bundle install fails with mismatched checksums (exit 37) while the unwind reports success #1260 stale-cache warning.
Re-run the three gem suites on 4.1.0 final when it ships.

Known non-bugs

To drive a successful gem H→V takeover from e2e_redirect_gem_build.rs, mount a priority-1 /patches/package answer with a sha512 tarball artifact and a gem-stub-gemspec artifact (gem spec <archive> --ruby); without them vendored mode fails vendor_prebuilt_required (run 44).
In the Docker layout, the stale-install remedy's bundle config set --local path vendor/bundle writes to $BUNDLE_APP_CONFIG/config (Bundler's own behaviour); it still takes effect (run 44).
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.
Agent .bundle/config path "~/x" (tilde, so out of tree) is skipped as a write root with gem_bundle_config_path_ignored, and vex refuses not_applied. Documented (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 contract); env BUNDLE_PATH='~/x' is expanded and works (run 28).
In mock dirs, never run gem install <gem> from a cwd that holds a rebuilt *.gem of the same name and version: RubyGems installs the local file first, which silently patches the system copy and fakes "pass" results. Reinstall from an empty dir, and check the system cache .gem sha (run 28 near-miss).
Bundler with an explicit path doesn't reuse a non-default gem from the system home (verified with rexml 3.3.9: it fetches into vendor/bundle). Default gems can still come from the system homes (run 28).
A global (~/.bundle/config) mirror.all isn't inspected by the 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 mirror guard. That's documented in the docs/ecosystems.md RubyGems row ("user-global config … not inspected"), so it's not filed (run 29).
Bundler 4.0.22 Settings#path applies deployment → vendor/bundle only when no tier sets path / path.system / disable_shared_gems, so a global path.system true plus a local deployment true really does use system gems; the crawler agrees (run 29). disable_shared_gems: false means system gems in Bundler, and the crawler ignores it, but Bundler never writes false itself (1.x writes true or removes the key), so it's contrived and not filed.
An unconstrained gem "x" whose lock resolves a newer version than the shared-home copy hits Hosted gem scan pins a version that only another project installed into the shared gem home, rewriting gem "x", "~> 1.0" to the older patched "0.8.1", so the prescribed bundle install downgrades the project's locked gem #1055, not a separate bug (run 29).
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 fix (Fix .bundle/config values keeping a trailing # comment (#951) #953) models Bundler's strip_comment exactly as Bundler 2.5.22 / 2.6.9 / 4.0.18 do (x#y → x, "a#b" → a, a value starting with # kept), so those spellings are not bugs (run 30).
The sandbox's rbenv also has Ruby 3.1.6 (Bundler 2.6.9 installable) and 3.2.6, plus Bundler 4.0.18 on 3.3.6. Use an isolated GEM_HOME per cell so the system gems stay clean (run 30).
To get both builds of a native gem into one gem home: gem install <x> -v V --platform ruby then gem install <x> -v V (needs gcc + libffi-dev for ffi, both present). Bundler 2.6+ locks list every platform variant by default (run 30).
Bundler's deployment true (local or env) and simulate_version 5 never reuse a system gem-home copy: they fetch into vendor/bundle / .bundle (verified with real installs, run 31). The hosted stale guard's false warning there is Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109.
The worktree is a fresh container each run: there's no rbenv now, only /usr/local/bin/ruby 3.3.6 with Bundler 2.5.22 (default) + 4.0.18. Install other Bundlers into an isolated GEM_HOME (run 31).
Hand-written agent manifests need BOTH blobs (beforeHash and afterHash) in .socket/blobs, or rollback --offline fails with "Before blob not found" (run 32 near-miss). Never derive a fixture from an already-patched file.
A scratch hosted test in e2e_redirect_gem_build.rs needs GEM_PATH=<shared home>:<system gem dir> to pick a non-default Bundler via BUNDLER_VERSION; otherwise it silently falls back to the default 2.5.22 (run 32).
Bundler 4.0.18 refuses every frozen install of a project whose Gemfile uses the lockfile "x.lock" DSL when no Gemfile.lock exists ("The frozen setting requires a lockfile"). With a leftover Gemfile.lock it passes that check and reads the DSL lock. That's Bundler's own behaviour (run 33).
#749 / #751 are fixed for the config / env / global spellings and the twin (Fix gem pair model ignoring custom lockfile and Bundler 1 twins (#749, #751) #768). The DSL spelling is tracked as a comment on 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.
Make the vendored-to-hosted takeover atomic #1039 made the V→H takeover atomic, but gem is not in hosted::takeover::takeover_ecosystem (cargo / npm / golang / pypi / maven), so the run-16 gem V→H refusal is unchanged (run 34).
A hosted single-gem superseding patch (same version, new uuid) works: the re-scan rewrites the block, lock remote and CHECKSUMS, and the stale guard flags the gen-A install (its wording says "UNPATCHED" for older-patch bytes; fail-safe, not filed) (run 34).
Layer extra patch generations over the e2e fixture's mocks with wiremock Mock::with_priority(1|2) (default priority is 5); cargo test on a cold target takes >10 min, so run it with a long background timeout (run 34).
A capped hosted re-scan never un-wires a deferred gem: the Gemfile source block stays, so Capped hosted gem re-scan counts a Gemfile-only (no-CHECKSUMS) pin as NEW, so --max-new-patches N spends its budget on gems it already wired and starves the next one forever (regression from #1058) #1224 is a stuck rollout, not silent unpatching (run 35).
Bundler 4.1.0.beta2 lock / DSL changes (OPTIONS regex allows _ for sparse_checkout:, the override from:/to: DSL, empty-CHECKSUMS re-resolve only when fetching remotely) don't touch the shapes socket-patch writes; the gem suites pass (run 35).
Bisect without rebuilding tests: temporarily make binary() in the e2e file honour a ZZ_BIN env override, and build the old commit's release binary into its own CARGO_TARGET_DIR (about 6 min) (run 35). std::env::var("X").is_ok() is true for X="", so leave scratch toggles unset rather than empty.
A 3–4 gem hosted mock (run 36) is in the run-36 entry's description: one uuid per gem, so the patch-registry GEM sections sort in a known order, and the compact-index info carries deps (rack-test → rack:>= 1.3). Its /patches/batch offers every gem whatever the query, so a lockless or shared-home scan "finds" gems the project never declared (a mock artifact, not Hosted gem scan of a Gemfile with no lock still pins shared-gem-home versions: gem "x", "~> 2.0" becomes the older patched "1.0.0", and a gem the project never declared is appended as a new dependency #1125).
A partial hosted rollback leaves a VEX statement whose subcomponents list only the still-patched gems, even when they share one advisory with the rolled-back gem (correct OpenVEX scoping, run 36).
A hosted unwind against the e2e harness's mock upstream on a CHECKSUMS lock is refused ("upstream GEM remote … is not rubygems.org"), so the Hosted gem rollback / remove leave the patched .gem in the project's committed vendor/cache, so every later bundle install fails with mismatched checksums (exit 37) while the unwind reports success #1260 CHECKSUMS branch can only be driven with a real rubygems.org upstream (run-36 harness); the e2e capstone covers the no-CHECKSUMS branch (run 37).
Bundler's Source::Path#cache never copies a path gem that lives inside the project root, so bundle cache --all leaves vendored .socket/vendor/... gems alone and vendor/cache/<name>/ can't shadow them (checked in the 4.0.18 source, run 37).
The v4.0.0 binary still runs setup for migration tests (npm pack @socketsecurity/socket-patch-linux-x64-gnu@4.0.0); bundle plugin uninstall exists on Bundler 2.3+ and clears .bundle/plugin/index even after the plugin dir is gone (run 37).
v5 list on a hosted gem project with a loopback patch registry shows 0 results unless --patch-server-url <mock> is passed (discovery trust rule, same as vex).
gem_bundler_plugin_stale reads only <root>/.bundle/plugin/index (or BUNDLE_APP_CONFIG), not the moved gemfiles/.bundle under a BUNDLE_GEMFILE Appraisal layout. It's warning-only, so a miss there isn't filed (run 38).
scan --mode agent with an unreachable API returns status: error with no warnings, so the v5 Bundler plugin cleanup leaves .bundle/plugin registered in every other checkout, so bundle install crashes with LoadError on Bundler 2.3–2.5 #1295 warning isn't shown on that path. That's expected; apply --offline shows it (run 38).
bughunt/bundler/20261012-win-mac-recheck is also left behind (git push --delete hangs up), and no run ever triggered on it; its workflow is push-triggered only.
Bundler 4.0.18 only warns ("Cannot write a changed lockfile while frozen.", exit 0) when a source-block gem's DEPENDENCIES ! is missing. 4.0.19+ fails with exit 16. Use 4.0.22 to show the frozen-install impact of ! bugs (run 39).
The bundle / bundle_env helpers in e2e_redirect_gem_build.rs strip GEM_*, so a Bundler installed into a scratch GEM_HOME is silently not used. gem install bundler -v <v> into the system gems, then set BUNDLER_VERSION + SOCKET_PATCH_BUNDLER_E2E_VERSION (run 39).
source "…", type: "rubygems" do isn't a valid Bundler source (type: selects a plugin source; Bundler fails with "Could not find gem 'bundler-source-rubygems'"). Use a paren multi-line opener to test multi-line source shapes (run 40).
The Fix gem source-block bang lost after x = if … end (#1476) #1478 source-block scanner misses a regex after a predicate method with no parentheses (x.match? /end/) and a %w[end] argument with no parentheses. Both are contrived, so they're not filed (run 40).
gemfile(5) lists BUNDLE_LOCKFILE env above the Gemfile lockfile DSL, but Dsl#to_definition lets the DSL win for install (4.0.23 changes only bundle lock, #9661). socket-patch follows the install order and refuses any DSL lock other than the default one, so the mismatch can't mislead an install (run 41).
The vendored gemfile_not_loaded message for lockfile false reads "bundler reads the lockfile lockfile false". That's cosmetic (run 41).
Wait loops like while pgrep -f "cargo test …" match their own shell and never exit. Wait on an output file instead (run 41 near-miss).
zz = 1; self.source "…" do isn't seen as a source block by the Hosted gem rollback / remove strip the DEPENDENCIES ! when the user's source … do block opens after a ; on the same line, so frozen installs fail on Bundler 4.0.19+ #1531 fix, which deliberately excludes receiver calls (x.source). An explicit self. on a Gemfile DSL call is contrived, so it's not filed (run 42).
vex --json needs --output (json_requires_output); grep the human output instead in probes (run 43).
e2e_gem.rs needs the real public patch API (patches-api.socket.dev), which the sandbox blocks, so its 3 lifecycle tests fail with "tunnel error". That's a sandbox artifact. Run the Bundler suites with cargo test --no-fail-fast, or cargo stops at that first failing binary (run 45).
Gemspec product: Gem::Specification.new "name", "1.0" do |s| constructor arguments aren't read, so the purl falls back to the file stem with no version. That's rare and only touches the VEX product id, so it's not filed (run 45, read-only).

2026-09-30T16:48:08Z

github-actions[bot]
Bot Sep 30, 2026

[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

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.

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.
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).
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.
A macOS/Windows probe branch running the hosted CRLF Gemfile/lock cells and a Windows BUNDLE_PATH with a drive letter or spaces.
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.

0 replies

2026-09-30T22:34:36Z

github-actions[bot]
Bot Sep 30, 2026

[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

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.

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.
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.
Git- and path-sourced gems: hosted and agent patch targets (bundler/gems/<name>-<sha>), and whether the plugin's patch_target_files misses them.
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.
Ruby 2.7 and 3.4 runtimes (Bundler 2.2 doesn't boot on 3.4; check that setup still probes correctly).

0 replies

2026-10-01T03:26:45Z

github-actions[bot]
Bot Oct 1, 2026

[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):

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

0 replies

2026-10-01T04:56:10Z

github-actions[bot]
Bot Oct 1, 2026

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

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.
-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.
scan -g --mode hosted and --global-prefix … --mode hosted: pass (exit 2, loud message, nothing written), on all 9 CI cells too.
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.
--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.
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.

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.
macOS system Ruby / Homebrew Ruby and rbenv / chruby / asdf global layouts for -g, plus a unicode or space-containing --global-prefix.
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).
Windows hosted cells: a CRLF Gemfile / lock, a BUNDLE_PATH with a drive letter or spaces, and x64-mingw-ucrt platform gems.
Git- and path-sourced gems in hosted mode (do the redirect and the stale-install guard ignore GIT / PATH sections cleanly?).

0 replies

2026-10-01T07:18:02Z

github-actions[bot]
Bot Oct 1, 2026

[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

0 replies

2026-10-01T10:38:33Z

github-actions[bot]
Bot Oct 1, 2026

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

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).
A vendor/cache (bundle package) project in hosted mode: the stale-install guard's committed-cache warning, and rollback.
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).
Windows hosted cells: a CRLF lock, BUNDLE_PATH with a drive letter or spaces, x64-mingw-ucrt platform gems (probe branch).
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).

0 replies

2026-10-01T16:32:48Z

github-actions[bot]
Bot Oct 1, 2026

[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

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

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.

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.
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).
Windows hosted cells (probe branch): CRLF lock, BUNDLE_PATH with a drive letter or spaces, x64-mingw-ucrt platform gems.
BUNDLE_CACHE_PATH given through the environment (not .bundle/config), and vendor/cache with rollback.
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.

0 replies

2026-10-01T22:28:47Z

github-actions[bot]
Bot Oct 1, 2026

[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

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.

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.
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).
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.
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.
Windows hosted cells (probe branch): CRLF lock, BUNDLE_PATH with a drive letter, x64-mingw-ucrt platform gems.

0 replies

2026-10-02T04:32:23Z

github-actions[bot]
Bot Oct 2, 2026

[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

False positives ruled out

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

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.
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).
Windows hosted and vendored cells (probe branch): CRLF lock, BUNDLE_PATH with a drive letter or spaces, x64-mingw-ucrt platform gems.
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.
Vendored transitive dep of a gemspec project (PATH section); vendored on a multi-platform CHECKSUMS lock.

0 replies

2026-10-02T10:44:46Z

github-actions[bot]
Bot Oct 2, 2026

[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

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

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.
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).
Windows hosted and vendored cells (probe branch): CRLF lock, BUNDLE_PATH with a drive letter or spaces, x64-mingw-ucrt platform gems.
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.
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.

0 replies

2026-10-02T16:35:21Z

github-actions[bot]
Bot Oct 2, 2026

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

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.
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.
Windows hosted and vendored cells (probe branch): CRLF lock, BUNDLE_PATH with a drive letter or spaces, x64-mingw-ucrt gems.
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.
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).

0 replies

2026-10-02T17:22:13Z

github-actions[bot]
Bot Oct 2, 2026

[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

0 replies

2026-10-02T19:20:50Z

github-actions[bot]
Bot Oct 2, 2026

[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

0 replies

2026-10-02T22:42:18Z

github-actions[bot]
Bot Oct 2, 2026

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

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.
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.
Windows hosted and vendored cells: CRLF lock, a BUNDLE_PATH with a drive letter, x64-mingw-ucrt platform gems, vendor/bundle deployment mode.
macOS system and Homebrew Ruby global mode; a symlinked env BUNDLE_GEMFILE next to a config gemfile (/var vs /private/var).
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.

0 replies

2026-10-03T04:24:18Z

github-actions[bot]
Bot Oct 3, 2026

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

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.
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?
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.
Windows hosted and vendored cells: CRLF lock, a BUNDLE_PATH with a drive letter, x64-mingw-ucrt platform gems.
macOS: a symlinked env BUNDLE_GEMFILE next to a config gemfile; Homebrew / system Ruby global mode.

0 replies

2026-10-09T04:29:50Z

github-actions[bot]
Bot Oct 9, 2026

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

Tested: main f3c6313. Since run 34 (cb16bdd), main took #1190 (the fix for #1186), #1058 (hosted "is it pinned" decided through lockfile discovery alone), #1108 (line terminators, touches formats/gem/hosted.rs), #1160 / #1191 (BOM), #1163 and others. Latest release is v4.0.0 (npm). Linux sandbox, Ruby 3.3.6, Bundler 2.5.22 / 4.0.22 / 4.1.0.beta2 (released 2026-10-08). No probe branches: the finding is OS-independent lock / Gemfile text.

Re-triage

Cells

Cell	4.1.0.beta2	4.0.22	2.5.22
Repo gem e2e suites (redirect 35 / stale 37 / vendor 41 / multi-platform 7, no SKIPs)	pass	—	—
Hosted single gem, no-CHECKSUMS lock, re-scan `--max-new-patches 0`	—	fail #1224 (`rollout_deferred` for the wired gem)	fail #1224
Hosted two gems, no-CHECKSUMS lock, `--max-new-patches 1` ×4 from pristine	—	fail #1224 (the 2nd gem is never added)	fail #1224 (×2)
Same, CHECKSUMS lock (control)	—	pass (run 2 adds it, then `already: 2`)	n/a
Same, `ef48495` (parent of #1058), no-CHECKSUMS	—	—	pass (bisect: first bad is `4d06019`)
Hosted superseding patch, `--max-new-patches 0`, no-CHECKSUMS	—	—	fail (#1224 comment; also on `ef48495`, so it predates #1058)
Same, CHECKSUMS lock	—	pass (`upgrade: 1`)	—

Bundler 4.1.0.beta2 vs beta1 (lib diff): the lock OPTIONS regex now allows _ (sparse_checkout: on GIT sources), there's a new override "x", from:, to: dependency-rewrite DSL, and an empty CHECKSUMS entry only forces a re-resolve when a remote fetch is coming (frozen mode still refuses). None of these touch the shapes socket-patch writes. The suites pass.

Issues

False positives ruled out

The capped re-scan leaves the existing Gemfile wiring in place (deferral never un-wires), so Capped hosted gem re-scan counts a Gemfile-only (no-CHECKSUMS) pin as NEW, so --max-new-patches N spends its budget on gems it already wired and starves the next one forever (regression from #1058) #1224 is a stuck rollout, not silent unpatching.
ZZ_CK="" still reads as set (env::var(..).is_ok()), so my first "no-CHECKSUMS" 4.0.22 upgrade run was really the CHECKSUMS arm. Use a non-empty or unset variable.

Capped hosted gem re-scan counts a Gemfile-only (no-CHECKSUMS) pin as NEW, so --max-new-patches N spends its budget on gems it already wired and starves the next one forever (regression from #1058) #1224 neighbours: gems.rb spelling; the lockless Gemfile (Hosted gem scan of a Gemfile with no lock still pins shared-gem-home versions: gem "x", "~> 2.0" becomes the older patched "1.0.0", and a gem the project never declared is appended as a new dependency #1125 shape) under a cap; --max-new-patches via SOCKET_MAX_NEW_PATCHES / socket.yml.
Hosted gem re-scan refreshes a patch-registry GEM remote in place without re-sorting the lock's GEM sections, so after a superseding patch on a two-gem project every Bundler 4.0.19+ frozen install fails #1186 neighbours: rollback / remove of one of 3 hosted gems on a CHECKSUMS lock (section order of the rest).
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 DSL gap (vendored DSL lockfile, lockfile false).
Bundler 4.1 override "x", from:, to: vs a hosted transitive redirect (does vex attest a gem the override dropped?).
Re-run 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 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 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 / Hosted gem rollback / remove strips the DEPENDENCIES ! of a gem the user declared inside a source "https://rubygems.org" do block, so every frozen install fails after the unwind #1056 / Gem agent apply patches only the ruby-platform x-1.0/ dir when a x-1.0-x86_64-linux-gnu/ sibling is also installed, so Bundler loads the unpatched platform gem while vex attests not_affected #1092 / Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109 / Hosted gem scan of a Gemfile with no lock still pins shared-gem-home versions: gem "x", "~> 2.0" becomes the older patched "1.0.0", and a gem the project never declared is appended as a new dependency #1125 / Capped hosted gem re-scan counts a Gemfile-only (no-CHECKSUMS) pin as NEW, so --max-new-patches N spends its budget on gems it already wired and starves the next one forever (regression from #1058) #1224 when fixes merge; check PR Converge hosted Gemfile.lock sources through the formats::gem reader (#780) #1221 once it lands.

0 replies

2026-10-09T10:28:35Z

github-actions[bot]
Bot Oct 9, 2026

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

Tested: main a80b89e. Since run 35 (f3c6313), main took #1221 (hosted Gemfile.lock sources read through formats::gem, the hosted slice of #780), #1228 (the fix for #1224), #1227 (vendored line terminators; it doesn't touch gem) and others. Latest release is v4.0.0 (npm). Linux sandbox, Ruby 3.3.6, Bundler 2.5.22 / 2.6.9 / 4.0.22 / 4.1.0.beta2 in an isolated GEM_HOME. No probe branches: the finding is OS-independent.

New harness: a Python mock serving 3–4 gems (colorize / paint / rainbow / rack-test, each its own uuid, so the patch-registry GEM sections sort in a known order), plus the patch-registry compact index with a deps field, against the real rubygems.org upstream. It's derived from the run-13 mock, and cycle.sh runs scan → fresh frozen install → rollback/remove → fresh frozen install.

Re-triage

Cells

Cell	4.1.0.beta2	4.0.22	2.6.9	2.5.22
Hosted 3 gems, CHECKSUMS: scan → fresh frozen install	pass	pass	pass	—
`rollback` first / middle / last of 3 sorted sections → frozen install	—	pass (all 3 orders)	—	—
`rollback` all 3 one by one	—	pass (lock byte-identical; Gemfile +2 blank lines, known cosmetic)	—	—
Unfrozen `bundle install` between scan and `rollback` (lock re-render)	pass (unchanged)	—	pass	—
`remove` middle of 3	—	pass	—	—
Post-rollback `vex`: one statement, subcomponents = only the still-patched gems	—	pass	—	—
Hosted `rack-test` (patched gem with deps) + direct `rack`: cycle + `rollback`	—	pass (lock byte-restored)	—	—
In-run `--vex`, one of 3 refused (multi-line decl)	—	pass (refused gem not attested; frozen install patches the other 2)	—	—
#1224 fix: capped re-scan, `gems.rb` / `Gemfile`	—	—	—	pass
Capped re-scan, lockless Gemfile	—	—	—	pass (`already` counts; the extra appended gem was a mock artifact)
Bundler 4.1.0.beta2 default install path (no config)	system gems (unchanged)	—	—	—
`bundle cache` after scan, then `rollback` / `remove`	fail #1260	fail #1260 (×2 + `remove` + `cache_path`)	fail #1260	fail #1260 (frozen keeps the patched gem)

Issues

Filed Hosted gem rollback / remove leave the patched .gem in the project's committed vendor/cache, so every later bundle install fails with mismatched checksums (exit 37) while the unwind reports success #1260: Hosted gem rollback / remove leave the patched .gem in the project's committed vendor/cache, so every later bundle install fails with mismatched checksums (exit 37) while the unwind reports success #1260. Hosted gem rollback / remove leave the patched .gem in vendor/cache (or cache_path), so every later bundle install exits 37 (mismatched checksums) while the unwind reports success with only reinstall_required. On Bundler 2.5, frozen installs keep the patched gem. Control: deleting the archive makes the install pass.

False positives ruled out

The lockless capped scan appended rainbow, which the project never declared. My mock's /patches/batch offers every gem regardless of the query. Not filed. The real behaviour is Hosted gem scan of a Gemfile with no lock still pins shared-gem-home versions: gem "x", "~> 2.0" becomes the older patched "1.0.0", and a gem the project never declared is appended as a new dependency #1125's shared-home crawl.
The first in-run --vex probe exited 1 with redirect_gem_stale_install, because the project had pre-installed unpatched copies in vendor/bundle. That's the documented guard. Lock-only it passes.
Harness pitfall hit again: ps … | grep "[m]ock.py" + kill in the same command killed the shell (exit 144). Kill the PID in a separate command.

Vendored mode with a committed vendor/cache (does bundle cache --all copy the .socket/vendor path gem; does vendor --revert leave a stale cache?).
H→V takeover when the hosted gem's patched archive sits in vendor/cache (Hosted gem rollback / remove leave the patched .gem in the project's committed vendor/cache, so every later bundle install fails with mismatched checksums (exit 37) while the unwind reports success #1260 neighbour).
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 DSL gap: vendored DSL lockfile, and lockfile false.
Gem agent apply patches only the ruby-platform x-1.0/ dir when a x-1.0-x86_64-linux-gnu/ sibling is also installed, so Bundler loads the unpatched platform gem while vex attests not_affected #1092 neighbours: Windows x64-mingw-ucrt + x64-mingw32 pairs (probe). Hosted gem rollback / remove strips the DEPENDENCIES ! of a gem the user declared inside a source "https://rubygems.org" do block, so every frozen install fails after the unwind #1056 neighbours: CRLF Gemfile and gems.rb.
Re-run 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 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 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 / Hosted gem rollback / remove strips the DEPENDENCIES ! of a gem the user declared inside a source "https://rubygems.org" do block, so every frozen install fails after the unwind #1056 / Gem agent apply patches only the ruby-platform x-1.0/ dir when a x-1.0-x86_64-linux-gnu/ sibling is also installed, so Bundler loads the unpatched platform gem while vex attests not_affected #1092 / Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109 / Hosted gem scan of a Gemfile with no lock still pins shared-gem-home versions: gem "x", "~> 2.0" becomes the older patched "1.0.0", and a gem the project never declared is appended as a new dependency #1125 / Hosted gem rollback / remove leave the patched .gem in the project's committed vendor/cache, so every later bundle install fails with mismatched checksums (exit 37) while the unwind reports success #1260 when fixes merge.

0 replies

2026-10-09T13:26:07Z

github-actions[bot]
Bot Oct 9, 2026

[agent] Janitor: drift. #1224 was closed as completed on 2026-10-09 08:01Z by #1228 (e03a666d). The matrix still has fail #1224 cells. Please re-verify on main a80b89e0 and update the cells.

Generated by Claude Code

0 replies

2026-10-09T16:27:15Z

github-actions[bot]
Bot Oct 9, 2026

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

Tested: main a8e9397. Since run 36 (a80b89e), main took #1263 (the fix for #1260), the v5.0.0 release (#1194), #1034 (one target grammar for get / remove / rollback), #1245 (shared vendored-revert finish), #1262 (VEX stage + rename writer) and #1277 (BOM handling). Latest release is v5.0.0 (npm). Linux sandbox, Ruby 3.3.6, Bundler 2.3.27 / 2.4.22 / 2.5.22 / 2.6.9 / 4.0.18 in an isolated GEM_HOME. No probe branches: the new finding is in Bundler's own plugin loader, so it doesn't depend on the OS.

Re-triage

Hosted gem rollback / remove leave the patched .gem in the project's committed vendor/cache, so every later bundle install fails with mismatched checksums (exit 37) while the unwind reports success #1260 was closed by Fix gem unwind leaving patched archive in vendor/cache (#1260) #1263 before this run. Verified on a8e9397 with a scratch copy of e2e_redirect_gem_build.rs (Bundler 4.0.18, no-CHECKSUMS lock). bundle cache → rollback vuln-gem, remove pkg:gem/vuln-gem (versionless), rollback VULN-GEM, bare rollback, and rollback <purl> with cache_path vendor/gems all exit 0, restore the lock to upstream, and warn upstream_gem_stale_cache naming the right archive. Pass. No comment was added to the closed issue.
Open pm:bundler issues: none has a merged fix. Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109 and Gem VEX judges an unused system gem-home copy when the project sets a Bundler path, so standalone vex never attests #1098 have draft PR Fix gem checks judging unused system gem homes (#1098, #1109) #1290, which the maintainers say covers only the deployment part, so they weren't re-run.

Cells

Cell	Result
#1260 fix: unwind by bare name / versionless purl / uppercase / bare `rollback` (4.0.18)	pass
#1260 fix with config `cache_path vendor/gems` (4.0.18)	pass
#1260 CHECKSUMS branch	blocked: the harness's mock upstream isn't rubygems.org, so the unwind is refused (documented)
v4 `setup` plugin registered, then the v5 cleanup commit (block + `.socket/bundler-plugin/` removed)	fail #1295: `bundle install` exits 1 with `LoadError` on 2.3.27 / 2.4.22 / 2.5.22 (2 runs each); on 2.6.9 / 4.0.18 it warns on every install
Migrator's checkout following migrating-to-v5.md, incl. `bundle plugin uninstall` (4.0.18)	pass
v4.0.0 hosted scan → v5 re-scan → v5 `rollback` (2.5.22)	pass (re-scan leaves the lock byte-identical; rollback gives the documented exact pin)

Issues

Filed v5 Bundler plugin cleanup leaves .bundle/plugin registered in every other checkout, so bundle install crashes with LoadError on Bundler 2.3–2.5 #1295: v5 Bundler plugin cleanup leaves .bundle/plugin registered in every other checkout, so bundle install crashes with LoadError on Bundler 2.3–2.5 #1295. v5 dropped setup --remove, which since fix(gem): setup --remove clears bundler's machine-local .bundle/plugin registration #210 cleared .bundle/plugin/index. The migration guide's bundle plugin uninstall only fixes the migrator's own checkout, and CLI_CONTRACT.md and the setup removal error don't mention it at all. On Bundler ≤ 2.5, every teammate or runner checkout that registered the v4 plugin crashes on bundle install once the cleanup commit lands. First bad release: v5.0.0.

False positives ruled out

The scratch CHECKSUMS unwind refusal ("not rubygems.org") is the documented non-rubygems.org upstream rule, not a Hosted gem rollback / remove leave the patched .gem in the project's committed vendor/cache, so every later bundle install fails with mismatched checksums (exit 37) while the unwind reports success #1260 regression.
Vendored + bundle cache --all: Bundler never caches a path gem inside the project root (Source::Path#cache), so .socket/vendor gems can't be shadowed by vendor/cache/<name>/. Not a bug.
vex exit 2 in the scratch run was my own duplicated --org argument.

Windows / macOS checks for Hosted gem rollback / remove leave the patched .gem in the project's committed vendor/cache, so every later bundle install fails with mismatched checksums (exit 37) while the unwind reports success #1260 and v5 Bundler plugin cleanup leaves .bundle/plugin registered in every other checkout, so bundle install crashes with LoadError on Bundler 2.3–2.5 #1295 (scripted probe; the capstones can't spawn bundle.bat).
H→V takeover with the patched archive in vendor/cache, then vendored revert (no stale-cache check on that path).
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 DSL gap: vendored DSL lockfile, and lockfile false.
Gem agent apply patches only the ruby-platform x-1.0/ dir when a x-1.0-x86_64-linux-gnu/ sibling is also installed, so Bundler loads the unpatched platform gem while vex attests not_affected #1092 Windows platform pairs; Hosted gem rollback / remove strips the DEPENDENCIES ! of a gem the user declared inside a source "https://rubygems.org" do block, so every frozen install fails after the unwind #1056 CRLF / gems.rb.
Re-run open issues when fixes merge (Fix gem checks judging unused system gem homes (#1098, #1109) #1290 for Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109 / Gem VEX judges an unused system gem-home copy when the project sets a Bundler path, so standalone vex never attests #1098).

0 replies

2026-10-11T13:27:31Z

github-actions[bot]
Bot Oct 11, 2026

[agent] Janitor: ledger drift. These issues are now closed but this ledger still lists them as fail or open: #1056 (completed 2026-10-10), #1125 (completed 2026-10-09), #1295 (completed 2026-10-09). Please re-verify them on current main and update the matrix.

Generated by Claude Code

0 replies

2026-10-12T13:23:36Z

github-actions[bot]
Bot Oct 12, 2026

[agent] Janitor: ledger drift. These issues are now closed but this ledger still lists them as fail or open: #896 (completed 2026-10-11 by #1401 17c54411), #1092 (completed 2026-10-11 by #1395 ff4ced83). Please re-verify them on current main and update the matrix.

Generated by Claude Code

0 replies

2026-10-12T22:52:14Z

github-actions[bot]
Bot Oct 12, 2026

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

Tested: main 6ad6add (latest release v5.0.0). Since run 37, main took these gem fixes: #1290 (#1098 / part of #1109), #1304 (#1125), #1303 (#1056), #1367 (#1295), #1395 (#1092), #1401 (#896), #1406 (#988) and #1430 (#952). Linux sandbox, Ruby 3.3.6, Bundler 2.3.27 / 2.5.22 / 2.6.9 / 4.0.18 / 4.0.22 in an isolated GEM_HOME.

Re-triage

Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109: the open part (the .bundle default under simulate_version 5 / default_install_uses_path) waits on a maintainer decision (agent:needs-human). Unchanged, so I didn't re-run it.
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: no fix has landed. Unchanged.

Cells

Cell	Result
#952 fix, original shape (4.0.18, 2.5.22) and 8 neighbours (root-config `gemfile`, env `BUNDLE_PATH`, deployment, absolute path, `gems.rb`, leftover root store)	pass
#1092 fix: ffi ruby + `x86_64-linux-gnu` builds side by side: apply / runtime / vex / rollback (4.0.22)	pass
#1295 fix: real stale index from Bundler 2.3.27 / 2.5.22 / 4.0.18 → `gem_bundler_plugin_stale` on `apply`	pass
#1056 fix: plain and CRLF source-block unwind (4.0.18 / 4.0.22 / 2.6.9)	pass
#1056 gap: `v = if … end` / `v = case … end` inside the user's `source … do` block	fail (×2 on 4.0.18, also 4.0.22 / 2.6.9): `rollback` / `remove` drop the `!`. With a real CHECKSUMS lock, 4.0.22 frozen install exits 16
macOS / Windows probe	blocked: pushed `bughunt/bundler/20261012-win-mac-recheck`, but no Actions run triggered within ~30 min. I couldn't delete the branch (the remote hung up)

Issues

Commented on closed Hosted gem rollback / remove strips the DEPENDENCIES ! of a gem the user declared inside a source "https://rubygems.org" do block, so every frozen install fails after the unwind #1056 with the assignment-form gap (Hosted gem rollback / remove strips the DEPENDENCIES ! of a gem the user declared inside a source "https://rubygems.org" do block, so every frozen install fails after the unwind #1056 (comment)). in_source_block pushes a frame only for line-leading keywords, but every end pops one. The shape is uncommon, so I followed the 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 DSL-gap precedent and didn't open a new issue.
No new issues filed.

False positives ruled out

The first 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 attempt loaded the system copy because I ran bundle config set --local from gemfiles/ with a relative BUNDLE_GEMFILE already exported, which wrote gemfiles/gemfiles/.bundle/config. It was a harness error; the corrected cell passes.
scan against an unreachable API drops run warnings (status: error). Expected.

Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109 and 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: no fix commit has landed on main since run 38, so I didn't re-run them. They stay open (agent:needs-human / p2).
Hosted gem rollback / remove strips the DEPENDENCIES ! of a gem the user declared inside a source "https://rubygems.org" do block, so every frozen install fails after the unwind #1056 (closed): run 38's assignment-form gap still reproduces, and nothing tracked it apart from a comment on the closed issue, so I filed Hosted gem rollback / remove still strip the DEPENDENCIES ! when the user's source … do block holds an assignment-form v = if/case/begin … end, so frozen installs fail on Bundler 4.0.19+ #1476.
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 (closed): the Gemfile lockfile DSL gap from the 2026-10-08 comment still reproduces, so I filed Hosted gem scan ignores a Gemfile lockfile "custom.lock" DSL call (Bundler 4), so it pins the unused Gemfile.lock, leaves the real lock untouched, and every frozen install fails #1477.

Cells

Cell	4.0.22	4.0.18
`v = if … end` in the user's `source … do` block → `rollback` lock `!` kept	fail #1476 (×2)	fail #1476 (×3)
Same → frozen install of the restored pair	fail #1476 (exit 16, ×2)	pass (warning only)
Bundler alone: a source-block lock with only the `!` deleted, frozen install (rubygems.org `colorize 0.8.1`, with and without CHECKSUMS)	fail, exit 16 (Bundler's behaviour, the premise of #1476)	warns, exit 0
Gemfile `lockfile "custom.lock"` DSL → hosted scan refused	fail #1477 (×2)	fail #1477
macOS / Windows probe	not attempted (run 38's probe never triggered, and probe branches can't be deleted from the sandbox)

Filed: #1476 (#1476), #1477 (#1477).

Ruled out

A rollback CHECKSUMS variant of Hosted gem rollback / remove still strip the DEPENDENCIES ! when the user's source … do block holds an assignment-form v = if/case/begin … end, so frozen installs fail on Bundler 4.0.19+ #1476 against the loopback upstream is refused with hosted_restore_refused (the upstream isn't rubygems.org). That refusal is already documented, so it isn't a bug.
The bundle_env / bundle helpers in e2e_redirect_gem_build.rs strip GEM_*, so a Bundler installed into a scratch GEM_HOME is silently not used. Install the wanted Bundler into the system gems instead.

Next

Hosted gem scan ignores a Gemfile lockfile "custom.lock" DSL call (Bundler 4), so it pins the unused Gemfile.lock, leaves the real lock untouched, and every frozen install fails #1477 neighbour: vendored mode with the Gemfile lockfile DSL, and lockfile false.
Hosted gem rollback / remove still strip the DEPENDENCIES ! when the user's source … do block holds an assignment-form v = if/case/begin … end, so frozen installs fail on Bundler 4.0.19+ #1476 neighbours: x = while/until/unless … end, endless def x = 1, one-line x = if c then 1 else 2 end inside the source block.
H→V takeover with the hosted patched archive in vendor/cache, then vendor --revert / remove.
Windows / macOS probe: retry only if a maintainer can delete the leftover probe branches.
Re-run 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 / Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109 when fixes merge.

0 replies

2026-10-13T22:31:14Z

github-actions[bot]
Bot Oct 13, 2026

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

Tested: main aa85c6c, latest release v5.0.1 (npm, cut in #1485). Linux, Ruby 3.3.6, Bundler 4.0.22 and 2.6.9. I used a scratch copy of gem_hosted_unwind_keeps_a_source_block_bang in e2e_redirect_gem_build.rs with real bundle install runs, plus a scratch unit probe of in_source_block.

Re-triage

Hosted gem rollback / remove still strip the DEPENDENCIES ! when the user's source … do block holds an assignment-form v = if/case/begin … end, so frozen installs fail on Bundler 4.0.19+ #1476 and Hosted gem scan ignores a Gemfile lockfile "custom.lock" DSL call (Bundler 4), so it pins the unused Gemfile.lock, leaves the real lock untouched, and every frozen install fails #1477 were closed by Fix gem source-block bang lost after x = if … end (#1476) #1478 and Fix gem lockfile DSL call ignored (#1477) #1479. The backlog's Hosted gem rollback / remove still strip the DEPENDENCIES ! when the user's source … do block holds an assignment-form v = if/case/begin … end, so frozen installs fail on Bundler 4.0.19+ #1476 neighbours all pass a unit probe of in_source_block on main: x = while … do … end, x = until … end, x = unless … end, endless def x = 1, one-line x = if c then 1 else 2 end, begin … end while, plus about 40 modifier and literal shapes.
Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109 and 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 (agent:needs-human) have no fix on main, so I didn't re-run them.

Cells

Cell	4.0.22	2.6.9
Paren multi-line opener `source(\n "…"\n) do` → `rollback` / `remove` keeps the `!`	fail #1509 (frozen exit 16, ×2)	fail #1509 (frozen install only warns)
Brace block `source("…") { … }` → `rollback` / `remove`	fail #1509 (exit 16, Gemfile also not byte-restored, ×3)	fail #1509
#1476 neighbours (unit probe of `in_source_block`)	pass	—
A Gemfile `lockfile` DSL reader read-through (#1479): a multi-line call, `if` modifier and `lockfile nil` all refuse	pass (fail-closed, by reading the code)	—

Filed: #1509 (#1509).

Ruled out

source "…",\n type: "rubygems" do isn't a bug: Bundler itself rejects it ("Could not find gem 'bundler-source-rubygems'"), because type: selects a plugin source.
The scanner misses match? /end/ (a regex after a predicate method with no parentheses) and foo %w[end] (a %w argument with no parentheses). Both are contrived, so I didn't file them.

Next

Hosted gem rollback / remove strip the DEPENDENCIES ! when the user's source block opener spans lines or uses braces, so frozen installs fail on Bundler 4.0.19+ #1509 neighbours once it's fixed: brace blocks nested in group … do, a do on the line after the source(...) call, a source called after ;.
Hosted gem scan ignores a Gemfile lockfile "custom.lock" DSL call (Bundler 4), so it pins the unused Gemfile.lock, leaves the real lock untouched, and every frozen install fails #1477 neighbour, vendored mode with the Gemfile lockfile DSL (an e2e check of the Fix gem lockfile DSL call ignored (#1477) #1479 refusal).
H→V takeover with the hosted patched archive in vendor/cache, then vendor --revert / remove.
A Windows / macOS probe, only if a maintainer deletes the leftover probe branches.
Re-run 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 / Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109 when fixes merge.

0 replies

2026-10-14T11:00:59Z

github-actions[bot]
Bot Oct 14, 2026

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

Tested: main a8da202, latest release v5.0.1 (npm; no git tags). Linux, Ruby 3.3.6, Bundler 4.0.23 (released today) plus 4.0.18. I used scratch copies of gem_hosted_unwind_keeps_a_source_block_bang and a vendored lockfile DSL test with real bundle install runs, plus a scratch unit probe of in_source_block. All scratch edits were reverted.

Re-triage

Hosted gem rollback / remove strip the DEPENDENCIES ! when the user's source block opener spans lines or uses braces, so frozen installs fail on Bundler 4.0.19+ #1509 was closed by Fix gem source-block detection for multi-line and brace openers (#1509) #1520 before this run. The fixed shapes (multi-line source( opener, brace block) restore the ! and pass a frozen install on 4.0.23.
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 and Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109 (agent:needs-human) have no fix on main, so I didn't re-run them.

Cells

Cell	4.0.23
Repo gem e2e suites (redirect 51 / stale 42 / vendor 43 / multi-platform 27)	pass
`in_source_block` unit probe, 53 shapes (`\`-continued `do`, brace block nested in `group`, heredoc / `%w(end)` / `:"end"` / `?}`, `for … do end`, CRLF, `=begin`, …)	52 pass, 1 fail
`zz = 1; source "…" do` → `rollback` / `remove`	fail #1531 (`!` dropped, frozen exit 16, ×2)
Vendored + Gemfile `lockfile "custom.lock"` / `lockfile false`	pass (refused `gemfile_not_loaded`, nothing written)
Vendored + `lockfile "Gemfile.lock"` (names the default lock)	pass (vendors normally)

Filed: #1531 (#1531).

Ruled out / notes

Bundler 4.0.23 changes only bundle lock (it now honours the Gemfile lockfile DSL; #9661). gemfile(5) documents BUNDLE_LOCKFILE env over the DSL, but Dsl#to_definition lets the DSL win for install. socket-patch follows the install behaviour and refuses any non-default DSL lock anyway, so there's nothing to file.
The vendored refusal for lockfile false reads "bundler reads the lockfile lockfile false". That's an odd wording, but it's cosmetic.

Next

Re-verify Hosted gem rollback / remove strip the DEPENDENCIES ! when the user's source … do block opens after a ; on the same line, so frozen installs fail on Bundler 4.0.19+ #1531 once it's fixed, plus its neighbours: source after ; inside a group … do block, and two ;-joined source … do … end one-liners.
H→V takeover with the hosted patched archive in vendor/cache, then vendor --revert / remove.
Bundler 2.6.9 / 2.4.22 coverage of the newer unwind shapes (needs gem install bundler into the system gems).
Re-run 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 / Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109 when fixes merge.
A Windows / macOS probe, only if a maintainer deletes the leftover probe branches.

0 replies

2026-10-14T13:22:23Z

github-actions[bot]
Bot Oct 14, 2026

[agent] Janitor: ledger drift for the bug-hunt routine to pick up. These issues are now closed as completed, but this ledger's body still lists them as fail:

Hosted gem rollback / remove still strip the DEPENDENCIES ! when the user's source … do block holds an assignment-form v = if/case/begin … end, so frozen installs fail on Bundler 4.0.19+ #1476 (closed 2026-10-13 14:15Z by Fix gem source-block bang lost after x = if … end (#1476) #1478): v = if … end rows
Hosted gem scan ignores a Gemfile lockfile "custom.lock" DSL call (Bundler 4), so it pins the unused Gemfile.lock, leaves the real lock untouched, and every frozen install fails #1477 (closed 2026-10-13 14:15Z by Fix gem lockfile DSL call ignored (#1477) #1479): Gemfile lockfile "custom.lock" row
Hosted gem rollback / remove strip the DEPENDENCIES ! when the user's source block opener spans lines or uses braces, so frozen installs fail on Bundler 4.0.19+ #1509 (closed 2026-10-14 06:57Z by Fix gem source-block detection for multi-line and brace openers (#1509) #1520): paren multi-line and brace opener rows (a later row already says the Hosted gem rollback / remove strip the DEPENDENCIES ! when the user's source block opener spans lines or uses braces, so frozen installs fail on Bundler 4.0.19+ #1509 fix passes). Its open neighbour is Hosted gem rollback / remove strip the DEPENDENCIES ! when the user's source … do block opens after a ; on the same line, so frozen installs fail on Bundler 4.0.19+ #1531.

Generated by Claude Code

0 replies

2026-10-14T22:37:36Z

github-actions[bot]
Bot Oct 14, 2026

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

Tested: main 015e871, latest release v5.0.1 (npm; no git tags). Linux, Ruby 3.3.6, Bundler 4.1.0.beta2 / 4.0.23 / 2.6.9 / 2.4.22. No newer Bundler has shipped since 4.0.23 / 4.1.0.beta2. I used scratch copies of gem_hosted_unwind_keeps_a_source_block_bang (real bundle install, frozen install of the restored pair) and a scratch unit probe of in_source_block. All scratch edits were reverted.

Re-triage

Hosted gem rollback / remove strip the DEPENDENCIES ! when the user's source … do block opens after a ; on the same line, so frozen installs fail on Bundler 4.0.19+ #1531 was closed by Fix gem source block after a ; on the line (#1531) #1537 (140ee15) before this run. The zz = 1; source "…" do shape now restores the ! and passes a frozen install with rollback and remove on 4.0.23, 4.1.0.beta2, 2.6.9 and 2.4.22.
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 and Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109 (agent:needs-human) have no fix on main, so I didn't re-run them.

Cells

Cell	4.1.0.beta2	4.0.23	2.6.9	2.4.22
Repo gem e2e suites (redirect 51 / stale 42 / vendor 43)	—	pass	—	—
Source-block unwind test, all 10 shapes (#1056 / #1476 / #1509 / #1531), `rollback` + `remove` → frozen install	pass	pass	pass	pass
#1531 neighbours (real Bundler): `zz = 1; source … do` inside a `group … do` block; `source "…" do end; source "…" do`; `if true; source "…" do … end; end`	—	pass	—	—
`in_source_block` unit probe, 64 more shapes (`;` in strings / `%w[]` / regexps / symbols / `?;`, heredoc after `;`, `def … end;`, `while … end;`, `then`, `\`-continued `do`, closed one-line blocks before the gem, …)	63 pass, 1 miss (`self.source`, see below)

Filed: nothing.

Ruled out / notes

zz = 1; self.source "…" do isn't seen as a source block. The fix deliberately excludes receiver calls (x.source), and an explicit self. receiver on a Gemfile DSL call is contrived, so it's not filed.
Hosted→vendored takeover with a cached patched archive in vendor/cache: both takeover paths (vendor.rs:1958 eject and vendor.rs:3270 per-pin) forward restore_upstream's upstream_gem_stale_cache warning into the envelope. I didn't run it end to end (the takeover harness needs the heavy run-18 mocks); it stays in the backlog at a lower priority.
No macOS / Windows probe: the 8 leftover bughunt/bundler/* probe branches still exist and can't be deleted from the sandbox.

Next

H→V takeover with a hosted patched archive in vendor/cache, end to end: check that the warning appears, then run vendor --revert / remove.
Re-run 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 / Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109 when fixes merge.
Docker-style BUNDLE_APP_CONFIG=/usr/local/bundle + GEM_HOME=/usr/local/bundle (the official ruby images) with a committed project .bundle/config: agent apply / vex and the hosted stale guard.
The gemspec product probe (vex/product.rs parse_gemspec) on real-world gemspec shapes (.freeze, commented-out name = lines, Gem::Specification.new "name", "1.0" constructor arguments).
A Windows / macOS probe, only if a maintainer deletes the leftover probe branches.

0 replies

2026-10-15T10:19:31Z

github-actions[bot]
Bot Oct 15, 2026

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

Tested: main e76cb9b, latest release v5.0.1 (npm; no git tags). No gem code changed since run 42 (015e871); only a vendored lockfile-only test moved. Linux, Ruby 3.3.6, Bundler 2.5.22 (4.0.18 also present). Agent cells used a hand-written manifest + apply --offline + vex, with a real bundle install into an isolated GEM_HOME.

Re-triage

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 and Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109 (agent:needs-human) have no fix on main. Not re-run.

Cells

Cell	Result
Docker-style `GEM_HOME` = `BUNDLE_APP_CONFIG` = one dir, committed project `.bundle/config` `BUNDLE_PATH: vendor/bundle` (Bundler ignores it and installs into `GEM_HOME`) → agent `apply` patches the `GEM_HOME` copy, `vex` attests `not_affected`	pass
Same, `$BUNDLE_APP_CONFIG/config` sets a `BUNDLE_PATH` with nothing installed there → `vex` refuses ("No applied patches")	pass
Gemspec product (`parse_gemspec`): commented `# spec.version = "0.0.1"` above `spec.version = Acme::VERSION`	fail → `pkg:gem/acme@0.0.1` (Ruby says 2.3.4)
Gemspec product: commented `# spec.name = "acme-legacy"` above `spec.name = "acme"`	fail → `pkg:gem/acme-legacy`

Filed: #1573 (#1573): VEX gemspec product detection reads commented-out # spec.name = / # spec.version = lines.

Ruled out / notes

.freeze literals ("acme".freeze, as gem spec --ruby writes them) parse correctly.
vex --json needs --output; that's json_requires_output and documented.
No macOS / Windows probe: the parser is pure text, and the leftover bughunt/bundler/* branches still can't be deleted from the sandbox.

Next

H→V takeover with a hosted patched archive in vendor/cache, end to end.
Re-run 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 / Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109 / VEX gemspec product detection reads commented-out # spec.name = / # spec.version = lines, so the document names the wrong product or version #1573 when fixes merge.
Docker layout, hosted half: the stale-install guard with GEM_HOME=BUNDLE_APP_CONFIG.
Gemspec constructor-argument shape (Gem::Specification.new "name", "1.0") with a mismatched file stem; =begin blocks.

0 replies

2026-10-15T22:32:27Z

github-actions[bot]
Bot Oct 15, 2026

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

Tested: main 657fce2, latest release v5.0.1 (npm; no git tags). Linux, Ruby 3.3.6, Bundler 4.0.18 and 2.5.22. Hosted and vendored cells used scratch copies of e2e_redirect_gem_stale_install.rs / e2e_redirect_gem_build.rs, with a real gem build / bundle install / bundle cache.

Re-triage

VEX gemspec product detection reads commented-out # spec.name = / # spec.version = lines, so the document names the wrong product or version #1573 was fixed by Fix VEX gemspec reading commented-out name/version (#1573) #1582 and is already closed. I read the new parse_gemspec: it skips comments, =begin blocks and heredocs, and the last assignment wins. Nothing new to file.
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 and Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109 (agent:needs-human) have no fix on main. Not re-run.

Cells

Cell	Result
Docker layout (`GEM_HOME` = `BUNDLE_APP_CONFIG`), hosted stale guard: project `.bundle/config` `BUNDLE_PATH` / `BUNDLE_DEPLOYMENT` / both (ignored by Bundler) → shared-home warning, not attested	pass
Same, `BUNDLE_PATH` / `BUNDLE_DEPLOYMENT` in `$BUNDLE_APP_CONFIG/config` → quiet, attested; app config without a path key → warns	pass
H→V takeover (`get <uuid> --mode vendored`) over a patched `vendor/cache` archive → `upstream_gem_stale_cache` advisory, `path:` wiring	pass (4.0.18, 2.5.22)
Same, then `vendor --revert` / `remove` / `rollback` → no warning; fresh frozen install of the restored upstream lock installs the patched bytes from the cache	fail #1594 (4.0.18 ×2, 2.5.22)
Non-frozen `bundle install` while vendored doesn't prune the stale archive	confirmed (scenario premise)
H→V takeover, CHECKSUMS lock, mock (non-rubygems.org) upstream	refused `redirect_revert_failed` (documented fail-closed)

Filed: #1594 (#1594): vendored unwind after a hosted→vendored takeover leaves the patched .gem in vendor/cache with no warning.

Ruled out / notes

The first takeover attempts failed vendor_prebuilt_required. That's a fixture gap: the redirect fixture serves no sha512 tarball or stub gemspec. Recorded under Known non-bugs.
No macOS / Windows probe this run. Both findings are pure file logic.

Next

0 replies

2026-10-16T10:35:15Z

github-actions[bot]
Bot Oct 16, 2026

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

Tested: main 657fce2 (unchanged since run 44), latest release v5.0.1 (npm; no git tags). Linux, Ruby 3.3.6, with Bundler 4.0.23 (newest stable, released 2026-10-14) and 2.7.2 (last 2.x). Both were run through the repo's real-Bundler suites with SOCKET_PATCH_BUNDLER_E2E_REQUIRED=1, which asserts the version under test.

Re-triage

Main hasn't changed, so Gem vendored remove / rollback / vendor --revert after a hosted→vendored takeover leave the patched .gem in vendor/cache with no warning, so fresh installs of the restored upstream lock keep installing patched bytes #1594, Hosted gem stale-install guard still flags an unused system gem-home copy under Bundler deployment or the .bundle default path, so scan --mode hosted --vex fails with no_applicable_patches on fresh checkouts #1109 and 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 are still open with no fix to verify. Nothing has changed on them (no new comments), so I didn't re-run them.

Cells

Suite	4.0.23	2.7.2
`e2e_redirect_gem_build` (hosted, 51 tests)	pass	pass
`e2e_redirect_gem_stale_install` (42 tests)	pass	pass
`e2e_vendor_gem_build` (vendored, 43 tests)	pass	pass
`e2e_gem` (agent, real public API)	blocked (sandbox blocks `patches-api.socket.dev`)	—

I read the 4.0.23 changelog: a lockfile-DSL fix in bundle lock (#9661), a 416 retry change and vendored-gem bumps. None of them touch a shape socket-patch writes.

Filed / commented / closed: none.

Ruled out

The e2e_gem failures are sandbox network artifacts ("tunnel error"), not bugs.
A gemspec that sets its name and version through Gem::Specification.new "name", "1.0" constructor arguments falls back to the file stem with no version. It's rare and only affects the VEX product id, so it's not filed.

Next

0 replies

Bug hunt ledger: Bundler (RubyGems) #316

Uh oh!

Uh oh!

Mikola Lysenko (mikolalysenko) Sep 30, 2026 Maintainer

Coverage matrix

Project modes

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

Other hosted shapes (run 4)

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

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

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

Run 8 (Linux, Ruby 3.3.6)

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

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

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

Run 12 (Linux, Ruby 3.3.6)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Run 28 (main 9c43dfc; Linux Ruby 3.3.6; hosted mock + real rubygems.org upstream)

Run 29 (main d47eab3; Linux Ruby 3.3.6; hosted mock + real rubygems.org upstream, agent hand-written manifest)

Run 30 (main 05ecc6e; Linux; agent hand-written manifest + apply --offline; real bundle install / bundle exec)

Run 31 (main 05fd82b; Linux Ruby 3.3.6; hosted stale guard via the e2e_redirect_gem_stale_install.rs harness, ×2 incl. real gem env; real bundle install for Bundler's own behaviour)

Run 32 (main b96a785; Linux Ruby 3.3.6; agent hand-written manifest + apply --offline / apply --check; hosted via a scratch copy of e2e_redirect_gem_build.rs with real bundle install)

Run 33 (main 823810a; Linux Ruby 3.3.6; scratch copy of e2e_redirect_gem_build.rs, real bundle install)

Run 34 (main cb16bdd; Linux Ruby 3.3.6; scratch copies of e2e_redirect_gem_build.rs, real bundle install, CHECKSUMS lock)

Run 35 (main f3c6313; Linux Ruby 3.3.6; scratch copies of e2e_redirect_gem_build.rs; rollout cap)

Run 36 (main a80b89e; Linux Ruby 3.3.6; 3–4 gem hosted mock + real rubygems.org upstream)

Run 37 (main a8e9397, v5.0.0; Linux Ruby 3.3.6)

Run 38 (main 6ad6add, v5.0.0; Linux Ruby 3.3.6; agent hand-written manifest + apply --offline / vex / rollback, real bundle install / bundle exec; hosted via a scratch copy of e2e_redirect_gem_build.rs)

Run 39 (main 15c2c83, v5.0.0; Linux Ruby 3.3.6; scratch copies of e2e_redirect_gem_build.rs, real bundle install)

Run 40 (main aa85c6c, v5.0.1; Linux Ruby 3.3.6; scratch copy of gem_hosted_unwind_keeps_a_source_block_bang, real bundle install)

Run 41 (main a8da202, v5.0.1; Linux Ruby 3.3.6; scratch copies of e2e_redirect_gem_build.rs / e2e_vendor_gem_build.rs, real bundle install)

Run 42 (main 015e871, v5.0.1; Linux Ruby 3.3.6; scratch copies of gem_hosted_unwind_keeps_a_source_block_bang, real bundle install)

Run 43 (main e76cb9b, v5.0.1; Linux Ruby 3.3.6, Bundler 2.5.22; agent hand-written manifest + apply --offline / vex, real bundle install)

Run 44 (main 657fce2, v5.0.1; Linux Ruby 3.3.6; scratch copies of e2e_redirect_gem_stale_install.rs / e2e_redirect_gem_build.rs, real bundle install / bundle cache)

Run 45 (main 657fce2, v5.0.1; Linux Ruby 3.3.6; the repo's real-Bundler suites with SOCKET_PATCH_BUNDLER_E2E_REQUIRED=1)

Global mode (-g)

Backlog

Known non-bugs

Replies: 57 comments

Uh oh!

github-actions[bot] Bot Sep 30, 2026

Cells

Issues

False positives ruled out

Next

Uh oh!

github-actions[bot] Bot Sep 30, 2026

Cells

Issues

False positives ruled out

Next

Uh oh!

github-actions[bot] Bot Oct 1, 2026

Uh oh!

github-actions[bot] Bot Oct 1, 2026

Re-triage

Cells (global mode, maintainer checklist)

Other cells

Issues

False positives ruled out

Blocked

Next

Uh oh!

github-actions[bot] Bot Oct 1, 2026

Uh oh!

github-actions[bot] Bot Oct 1, 2026

Mikola Lysenko (mikolalysenko)
Sep 30, 2026
Maintainer

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

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

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

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

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

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

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

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

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

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

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

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

Run 28 (main `9c43dfc`; Linux Ruby 3.3.6; hosted mock + real rubygems.org upstream)

Run 29 (main `d47eab3`; Linux Ruby 3.3.6; hosted mock + real rubygems.org upstream, agent hand-written manifest)

Run 30 (main `05ecc6e`; Linux; agent hand-written manifest + `apply --offline`; real `bundle install` / `bundle exec`)

Run 31 (main `05fd82b`; Linux Ruby 3.3.6; hosted stale guard via the `e2e_redirect_gem_stale_install.rs` harness, ×2 incl. real `gem env`; real `bundle install` for Bundler's own behaviour)

Run 32 (main `b96a785`; Linux Ruby 3.3.6; agent hand-written manifest + `apply --offline` / `apply --check`; hosted via a scratch copy of `e2e_redirect_gem_build.rs` with real `bundle install`)

Run 33 (main `823810a`; Linux Ruby 3.3.6; scratch copy of `e2e_redirect_gem_build.rs`, real `bundle install`)

Run 34 (main `cb16bdd`; Linux Ruby 3.3.6; scratch copies of `e2e_redirect_gem_build.rs`, real `bundle install`, CHECKSUMS lock)

Run 35 (main `f3c6313`; Linux Ruby 3.3.6; scratch copies of `e2e_redirect_gem_build.rs`; rollout cap)

Run 36 (main `a80b89e`; Linux Ruby 3.3.6; 3–4 gem hosted mock + real rubygems.org upstream)

Run 37 (main `a8e9397`, v5.0.0; Linux Ruby 3.3.6)

Run 38 (main `6ad6add`, v5.0.0; Linux Ruby 3.3.6; agent hand-written manifest + `apply --offline` / `vex` / `rollback`, real `bundle install` / `bundle exec`; hosted via a scratch copy of `e2e_redirect_gem_build.rs`)

Run 39 (main `15c2c83`, v5.0.0; Linux Ruby 3.3.6; scratch copies of `e2e_redirect_gem_build.rs`, real `bundle install`)

Run 40 (main `aa85c6c`, v5.0.1; Linux Ruby 3.3.6; scratch copy of `gem_hosted_unwind_keeps_a_source_block_bang`, real `bundle install`)

Run 41 (main `a8da202`, v5.0.1; Linux Ruby 3.3.6; scratch copies of `e2e_redirect_gem_build.rs` / `e2e_vendor_gem_build.rs`, real `bundle install`)

Run 42 (main `015e871`, v5.0.1; Linux Ruby 3.3.6; scratch copies of `gem_hosted_unwind_keeps_a_source_block_bang`, real `bundle install`)

Run 43 (main `e76cb9b`, v5.0.1; Linux Ruby 3.3.6, Bundler 2.5.22; agent hand-written manifest + `apply --offline` / `vex`, real `bundle install`)

Run 44 (main `657fce2`, v5.0.1; Linux Ruby 3.3.6; scratch copies of `e2e_redirect_gem_stale_install.rs` / `e2e_redirect_gem_build.rs`, real `bundle install` / `bundle cache`)

Run 45 (main `657fce2`, v5.0.1; Linux Ruby 3.3.6; the repo's real-Bundler suites with `SOCKET_PATCH_BUNDLER_E2E_REQUIRED=1`)

Global mode (`-g`)

github-actions[bot]
Bot Sep 30, 2026

github-actions[bot]
Bot Sep 30, 2026

github-actions[bot]
Bot Oct 1, 2026

github-actions[bot]
Bot Oct 1, 2026

github-actions[bot]
Bot Oct 1, 2026

github-actions[bot]
Bot Oct 1, 2026

github-actions[bot]
Bot Oct 1, 2026

github-actions[bot]
Bot Oct 1, 2026

github-actions[bot]
Bot Oct 2, 2026

github-actions[bot]
Bot Oct 2, 2026

github-actions[bot]
Bot Oct 2, 2026