Bug hunt ledger: Bundler (RubyGems)

[Mikola Lysenko (mikolalysenko)]

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

Last run: 2026-11-15, main 63f791d, release 5.1.0, newest Bundler 4.0.24 stable and 4.1.0.beta3 prerelease (tested so far: 2.3.27, 2.4.19, 2.5.22/23, 2.6.9, 4.0.18, 4.0.24, 4.1.0.beta3). Ruby 3.1.6, 3.2.6 and 3.3.6.

The ledger was reset on 2026-11-13. The old 97 KB ledger is in this branch's history (git show ec2d4516f:state/bundler.md); search it with git grep, don't copy it back.

Harness notes: the sandbox reaches rubygems.org but not the Socket patch API. A standalone mock of the patch API and patch registry works for all three modes (endpoints: POST …/patches/batch, GET …/patches/by-package/<purl>, POST …/patches/package, GET …/patches/view/<uuid> with blobContent, and a compact index under /patch-registry/gem/<token>/<uuid>/; copy the /info line from rubygems.org and swap the checksum). Build the patched gem by repacking the upstream .gem with its metadata.gz unchanged, and pass --api-url <mock> --proxy-url <mock> --patch-server-url <mock> to every command (without a token the CLI calls the proxy URL). For vendored mode the grant's tarball artifact needs integrity.sha512 (SRI) and a second artifact {"kind":"gem-stub-gemspec"} serving gem spec <patched.gem> --ruby. Give test repos a **/vendor/bundle/ ignore line. --api-token fake --org test works in place of the proxy route. For a gem with precompiled builds, nokogiri 1.16.0 compiles from source in under a minute here. rbenv Rubies are in /opt/ruby-3.1.6 (Bundler 2.3.27, 2.6.9), /opt/ruby-3.2.6 (2.4.19, 4.0.18), /opt/ruby-3.3.6 (2.5.22, 4.0.18); gem install bundler -v 4.0.24 / 4.1.0.beta3 works there.

Coverage matrix

Linux only. A cell is pass with the Bundler versions and the date, fail #N, n/a, or untested.

Workflow	Agent	Vendored	Hosted
Common path: scan, patch, fresh bundle install, app loads patched code, vex, rollback, bundle install again	pass 2.5.22, 2.6.9, 4.0.18 (11-15)	pass 2.5.22, 2.6.9, 4.0.18, 4.1.0.beta3, CRLF pair too (11-15); vex warning fail #2076	pass 2.3.27 to 4.0.24, 4.1.0.beta3 (11-14)
System or user gem home (no BUNDLE_PATH)	pass 4.0.18, 2.5.22 with GEM_HOME (11-15)	fail #2075 (2.6.9, 4.0.18)	pass 4.0.18: warning, scan and rollback with --gem-refresh-shared (11-15); the remedy after a plain rollback / remove fail #2086
bundle config set path vendor/bundle	pass 2.6.9 (11-13)	pass 4.0.18 (11-14)	pass 2.3.27 to 4.0.18 (11-14)
Deployment and frozen installs (BUNDLE_DEPLOYMENT, BUNDLE_FROZEN, .bundle/config)	pass frozen 2.6.9, 4.0.18 (11-13)	pass frozen and deployment clone, with BUNDLE_WITHOUT too, 4.0.18 (11-14)	pass frozen on all, deployment clone 2.5.22, 2.6.9, 4.0.18 (11-14)
Multi-platform lock, platform gem (-x86_64-linux)	pass 4.0.18: Ruby-file patch applied, C patch refused as documented (11-15)	pass 4.0.18: 7-platform lock, precompiled gem beside vendored ones (11-15)	pass 4.0.18: nokogiri refused, rest installs (11-14); moved to the ruby platform it installs patched, standalone vex fail #2087
Gem with a native extension (rebuild after patching, rollback restores the build)	pass 2.5.22, 2.6.9, 4.0.18, build failure restored too (11-15); scan --no-gem-native-rebuild fail #2069	refused as documented, exit 1, other gems vendored, 4.0.24 (11-14)	pass 4.0.18, 4.0.24 (11-14)
Patched gem that is only a transitive dependency	pass 2.6.9, 4.0.18 (11-14)	installs and reverts 4.0.18; Bundler.require loads it fail #2084	pass 2.5.23 to 4.0.24 (11-14)
Git and path sources next to a patched gem	pass 4.0.18 (11-14)	pass 4.0.24, 4.1.0.beta3 (11-14)	pass 4.0.18, 4.0.24, incl. a gem transitive through a path gem (11-14)
bundle update / bundle add / bundle remove / bundle outdated after patching	pass 4.0.18: add, remove, clean, outdated, --redownload then apply (11-14)	pass 4.0.18: add, remove, update, outdated, lock --add-platform, cache (11-14)	add / remove pass 2.6.9 (11-13); lock --add-platform, update <other gem>, clean, doctor, binstubs pass 4.0.18 (11-14); outdated / update fail #2070
Rollback and remove restore Gemfile and Gemfile.lock byte for byte	pass (pair never touched) (11-14)	rollback, remove, vendor --revert pass 4.0.18 (11-14)	rollback and remove pass on all, CRLF and vendor/cache archives too (11-14)
vex reports only what is really applied	pass 2.6.9, 4.0.18, after bundle pristine too (11-13)	attests correctly 4.0.18; false vendored_tree_out_of_sync fail #2076	pass 2.6.9, 4.0.18, stale shared-home copy omitted (11-15); orphan platform dir fail #2087
gems.rb / gems.locked spelling	pass 2.5.22 (11-15)	refused as documented (gemfile_not_loaded), not re-run	pass 4.0.18 (11-14)
Lock with a CHECKSUMS section (Bundler 2.6+)	n/a	pass 4.0.18; without the section 2.5.22, 2.6.9 (11-15)	pass 4.0.18 (11-13)
Monorepo: several Gemfiles, nested projects, scan from the repo root	untested (agent scans one project by design)	untested	pass 4.0.18: scan, list, rollback from the root (11-14)
setup and the Bundler plugin it installs	n/a: setup and the plugin were removed in v5 (CLI_CONTRACT "…no longer published"); only gem_bundler_plugin_stale detection is left, untested	n/a	n/a
Re-runs (idempotency) and --json output	pass 4.0.18 (11-14)	re-scan pass 2.6.9, 4.0.18 (apart from #2075)	pass 4.0.18 (11-14)
Switching modes on one project	untested	hosted to vendored: pair and mixed state pass 4.0.24; rollback afterwards leaves patched installs, fail #2083	vendored to hosted refused by design (not re-run)
Bundler 4.1 prerelease	untested	pass 4.1.0.beta3 (11-14); OVERRIDES / CONTENT ADDRESSES sections not produced, untested	pass 4.1.0.beta3 (11-14); same sections untested
Bundler 1.x refused where the docs say so	untested	untested	untested

Backlog

1. Friction pass as a first-time user following only the CLI's messages and docs/usage.md. Known candidates: redirect_gem_no_checksums_section says "bundler < 2.6 does not write one" on a 2.6.9 lock (its remedy works); vendored mode refuses every gem inside a group do block, which is most Rails Gemfiles (by design, Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340: is the message's remedy clear?); scan --mode vendored exits 1 whenever one patched gem is native (is the hint to use hosted for it clear?); remove <gem> from a monorepo root doesn't name the sub-projects that pin it; apply --check says "Run socket-patch apply to regenerate them" for a gem apply refuses (native_extensions_unsupported); the hosted next step says "a plain bundle install keeps the gems it already has" when the stale copy is a platform build the lock no longer names.
2. A realistic Rails-sized project (a Rails 7 or 8 Gemfile with groups, bootsnap, a Bundler.require boot) through hosted mode end to end, on Bundler 2.5, 2.6 and 4.0.
3. Vendored mode, the rest: remove / vendor --revert after a hosted to vendored takeover (Rolling back a gem that went from hosted to vendored leaves the patched installed copy in vendor/bundle: the app keeps loading patched code and bundle pristine / --redownload fail on the restored checksum #2083 covers rollback only), scan --prune.
4. Agent mode, the rest: Bundler 2.4, the system gem home under /opt/ruby-* itself, switching agent to hosted and back, apply --dry-run starts no Ruby, a relative crawl root (Rebuild gem native extensions from a relative crawl root #2048), an interrupted rebuild, a monorepo.
5. Other flags the nested apply of scan --mode agent may drop (same cause as scan --mode agent --no-gem-native-rebuild (and SOCKET_NO_GEM_NATIVE_REBUILD=1) still rebuilds the gem native extension and vex attests it; only apply and get honor the opt-out #2069: nested_apply_args_from_params fills GlobalArgs from defaults).
6. Hosted shared gem home, the rest: --gem-refresh-shared with two projects pinning the same gem version (the documented cost), remove of one gem out of several, SOCKET_GEM_REFRESH_SHARED=1.
7. Bundler 4.1 lock sections OVERRIDES and CONTENT ADDRESSES: find which Gemfile or setting makes 4.1.0.beta3 write them, then hosted and vendored. Ruby 3.4 is not in the sandbox.
8. Deployment mode and .bundle/config shapes around the stale-install guard. 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 is open and waiting on a maintainer decision; don't re-file it.
9. Bundler 1.x refused where the docs say so (needs a Ruby that still runs Bundler 1.17; none in the sandbox).
10. Re-check scan --mode agent --no-gem-native-rebuild (and SOCKET_NO_GEM_NATIVE_REBUILD=1) still rebuilds the gem native extension and vex attests it; only apply and get honor the opt-out #2069, A hosted-patched gem disappears from bundle outdated and bundle update can no longer move it, and nothing in the scan output or docs says so #2070, Vendored gem scan exits 1 with "Gemfile.lock GEM specs has no entry" for a gem in the shared gem home that the project does not lock, where hosted mode skips it with a warning #2075, vex warns vendored_tree_out_of_sync for every vendored gem after bundle install, and the remedy it names never clears it because Bundler keeps the unused registry copy #2076, Rolling back a gem that went from hosted to vendored leaves the patched installed copy in vendor/bundle: the app keeps loading patched code and bundle pristine / --redownload fail on the restored checksum #2083, Vendored mode declares a transitive gem without require: false, so Bundler.require starts loading it at boot (hosted mode adds the option) #2084, Hosted gem rollback / remove tell the user to re-run with --gem-refresh-shared, but the re-run exits 1 with "nothing to roll back" and the patched gem stays in the shared gem home #2086 and Standalone vex refuses a hosted gem as not_applied because of a leftover <gem>-<version>-x86_64-linux directory that has no gemspec, after the scan's own rm -f … && bundle install remedy #2087 once fixed.

Known non-bugs

The full list is in known-non-bugs/bundler.md on this branch. Search it with git grep before filing, and append one line when you rule something out. Don't read it whole. Most likely to be re-filed:

• "the patched gem's gemspec differs from the installed one" after a hosted scan: a mock gem rebuilt with gem build has a different gemspec. Repack with the original metadata.gz.
• vex / list report no patches on a hosted project whose patch URLs are on loopback: pass --patch-server-url.
• vex exits 2 asking for a product when the project has no git origin, gemspec or other manifest: pass --product.
• Hosted scan leaves gems in a shared gem home unpatched and warns: documented ("Ruby gems: gems already installed").

[github-actions[bot]]

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

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

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

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

Cells

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

Issues

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

False positives ruled out

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

Next

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

[github-actions[bot]]

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

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

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

Cells

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

Issues

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

False positives ruled out

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

Next

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

[github-actions[bot]]

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

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

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

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

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

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

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

[github-actions[bot]]

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

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

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

Re-triage

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

Cells (global mode, maintainer checklist)

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

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

Other cells

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

Issues

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

False positives ruled out

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

Blocked

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

Next

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

[github-actions[bot]]

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

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

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

[github-actions[bot]]

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

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

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

Re-triage

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

Cells

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

Issues

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

False positives ruled out

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

Blocked

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

Next

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

[github-actions[bot]]

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

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

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

Re-triage

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

Cells

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

Issues

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

False positives ruled out

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

Next

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

[github-actions[bot]]

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

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

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

Re-triage

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

Cells

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

Issues

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

False positives ruled out

• None this run.

Next

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

[github-actions[bot]]

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

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

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

Re-triage

• Main hasn't moved since 61cfb9b, so Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340, Gem vex checks the gem env gemdir copy instead of the Gem.path copy Ruby loads, so it attests not_affected while an unpatched --user-install / GEM_PATH copy runs #420, On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421, Hosted gem redirect appends a second declaration when the gem is declared through eval_gemfile or a loop, so every bundle install fails with "You cannot specify the same gem twice" #482, Gem hosted stale-install guard only checks vendor/cache, so a committed cache at a configured cache_path gets no warning, the in-run VEX attests it, and Bundler 2.4 installs the unpatched gem #483 and Gem manifest resolution lets the BUNDLE_GEMFILE env var override .bundle/config, but Bundler does the reverse, so hosted mode wires Gemfile while bundler installs Gemfile.next unpatched and VEX attests it #507 all stand. I didn't re-run them.

Cells

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

Issues

• Commented on Gem manifest resolution lets the BUNDLE_GEMFILE env var override .bundle/config, but Bundler does the reverse, so hosted mode wires Gemfile while bundler installs Gemfile.next unpatched and VEX attests it #507: Gem manifest resolution lets the BUNDLE_GEMFILE env var override .bundle/config, but Bundler does the reverse, so hosted mode wires Gemfile while bundler installs Gemfile.next unpatched and VEX attests it #507 (comment)
• Commented on Hosted gem redirect appends a second declaration when the gem is declared through eval_gemfile or a loop, so every bundle install fails with "You cannot specify the same gem twice" #482: Hosted gem redirect appends a second declaration when the gem is declared through eval_gemfile or a loop, so every bundle install fails with "You cannot specify the same gem twice" #482 (comment)
• No new issues filed: both failures share a root cause with an existing issue.

False positives ruled out

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

Next

1. BUNDLE_CACHE_PATH given through the environment (Gem hosted stale-install guard only checks vendor/cache, so a committed cache at a configured cache_path gets no warning, the in-run VEX attests it, and Bundler 2.4 installs the unpatched gem #483's variant); vendor/cache with rollback.
2. Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 on Bundler 2.2–2.5 (hosted, Linux).
3. Windows hosted and vendored cells (probe branch): CRLF lock, BUNDLE_PATH with a drive letter or spaces, x64-mingw-ucrt platform gems.
4. Global mode on macOS system and Homebrew Ruby; re-check On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421 once Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 merges.
5. Vendored transitive dep of a gemspec project (PATH section); vendored on a multi-platform CHECKSUMS lock.

[github-actions[bot]]

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

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

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

Re-triage

• Main hasn't moved, so Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340, Gem vex checks the gem env gemdir copy instead of the Gem.path copy Ruby loads, so it attests not_affected while an unpatched --user-install / GEM_PATH copy runs #420, On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421, Hosted gem redirect appends a second declaration when the gem is declared through eval_gemfile or a loop, so every bundle install fails with "You cannot specify the same gem twice" #482, Gem hosted stale-install guard only checks vendor/cache, so a committed cache at a configured cache_path gets no warning, the in-run VEX attests it, and Bundler 2.4 installs the unpatched gem #483 and Gem manifest resolution lets the BUNDLE_GEMFILE env var override .bundle/config, but Bundler does the reverse, so hosted mode wires Gemfile while bundler installs Gemfile.next unpatched and VEX attests it #507 all stand.
• Gem hosted stale-install guard only checks vendor/cache, so a committed cache at a configured cache_path gets no warning, the in-run VEX attests it, and Bundler 2.4 installs the unpatched gem #483: draft PR Fix Bundler settings resolution order (#483, #507) #532 fixes both the BUNDLE_CACHE_PATH env arm and the .bundle/config cache_path arm. On main, the env arm gives no warning; on 4.0.17 the next install exits 37 (checksum mismatch), and on 2.4.22 it silently installs unpatched. Comment: Gem hosted stale-install guard only checks vendor/cache, so a committed cache at a configured cache_path gets no warning, the in-run VEX attests it, and Bundler 2.4 installs the unpatched gem #483 (comment)

Cells

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

Issues

• Filed Hosted gem redirect rewrites only the first of a gem's declarations, so a gem listed in two group blocks makes every bundle install fail with "You cannot specify the same gem twice" #548: Hosted gem redirect rewrites only the first of a gem's declarations, so a gem listed in two group blocks makes every bundle install fail with "You cannot specify the same gem twice" #548
• Commented on Gem hosted stale-install guard only checks vendor/cache, so a committed cache at a configured cache_path gets no warning, the in-run VEX attests it, and Bundler 2.4 installs the unpatched gem #483 (PR Fix Bundler settings resolution order (#483, #507) #532 verified).

False positives ruled out

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

Next

1. Hosted gem redirect rewrites only the first of a gem's declarations, so a gem listed in two group blocks makes every bundle install fail with "You cannot specify the same gem twice" #548 on macOS and Windows isn't needed (text layer). Re-run once the rewriter changes; also check that rollback restores both declarations.
2. Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 on Bundler 2.2–2.5 (hosted, Linux).
3. Windows hosted and vendored cells (probe branch): CRLF lock, BUNDLE_PATH with a drive letter or spaces, x64-mingw-ucrt platform gems.
4. Global mode on macOS system and Homebrew Ruby; re-check On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421 once Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 merges.
5. Re-verify Gem hosted stale-install guard only checks vendor/cache, so a committed cache at a configured cache_path gets no warning, the in-run VEX attests it, and Bundler 2.4 installs the unpatched gem #483 and Gem manifest resolution lets the BUNDLE_GEMFILE env var override .bundle/config, but Bundler does the reverse, so hosted mode wires Gemfile while bundler installs Gemfile.next unpatched and VEX attests it #507 when Fix Bundler settings resolution order (#483, #507) #532 merges.

[github-actions[bot]]

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

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

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

Re-triage

• Gem hosted stale-install guard only checks vendor/cache, so a committed cache at a configured cache_path gets no warning, the in-run VEX attests it, and Bundler 2.4 installs the unpatched gem #483 and Gem manifest resolution lets the BUNDLE_GEMFILE env var override .bundle/config, but Bundler does the reverse, so hosted mode wires Gemfile while bundler installs Gemfile.next unpatched and VEX attests it #507 were closed by Fix Bundler settings resolution order (#483, #507) #532's merge. The new e2e cases (local cache_path, env BUNDLE_CACHE_PATH, BUNDLE_IGNORE_CONFIG, config gemfile Gemfile.next vs env BUNDLE_GEMFILE) pass on main. I left no comment because they're already closed.
• Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340, Gem vex checks the gem env gemdir copy instead of the Gem.path copy Ruby loads, so it attests not_affected while an unpatched --user-install / GEM_PATH copy runs #420, On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421, Hosted gem redirect appends a second declaration when the gem is declared through eval_gemfile or a loop, so every bundle install fails with "You cannot specify the same gem twice" #482 and Hosted gem redirect rewrites only the first of a gem's declarations, so a gem listed in two group blocks makes every bundle install fail with "You cannot specify the same gem twice" #548 stand. Nothing on main touched the gem rewriter, the vex gem-home lookup or the Windows gem spawn, so I didn't re-run them.

Cells

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

Issues

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

False positives ruled out

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

Next

1. Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577's agent arm: bundle config set --global path vendor/gems → does agent scan / apply miss the install? Also the agent BUNDLE_PATH read under BUNDLE_IGNORE_CONFIG.
2. A symlinked env BUNDLE_GEMFILE (/link/Gemfile → the project) next to a config gemfile Gemfile.next: env_keeps_root compares lexically, so it may follow the env var while Bundler reads the config (macOS /var vs /private/var). This needs a macOS probe.
3. Windows hosted and vendored cells (probe branch): CRLF lock, BUNDLE_PATH with a drive letter or spaces, x64-mingw-ucrt gems.
4. Global mode on macOS system and Homebrew Ruby; re-check On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421 once Fix global PM probes spawning bare names from the project (#421, #434, #438, #440) #442 merges.
5. Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 on Bundler 2.2–2.5 (2.2.33 is now installed).

[github-actions[bot]]

[agent] Janitor: ledger drift. The coverage matrix still lists these issues as fail, but they are now closed on GitHub. Please re-check those cells on main 6cd37540 on the next run:

• On Windows (RubyInstaller), scan -g / get -g / vex -g find no global gems because gem env is spawned as bare gem, which never resolves to gem.cmd #421: closed 2026-10-02 17:07 UTC

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

---

Generated by Claude Code

[github-actions[bot]]

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

• Hosted gem redirect appends a second declaration when the gem is declared through eval_gemfile or a loop, so every bundle install fails with "You cannot specify the same gem twice" #482 and Hosted gem redirect rewrites only the first of a gem's declarations, so a gem listed in two group blocks makes every bundle install fail with "You cannot specify the same gem twice" #548 (Gemfile rewrites duplicating gem declarations): closed as completed by PR Fix Gemfile rewrites duplicating gem declarations (#482, #548) #552, merge b1f9818a on main. Your plan item 4 re-run is due

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

---

Generated by Claude Code

[github-actions[bot]]

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

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

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

Re-triage

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

Cells

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

Issues

• Closed Gem vex checks the gem env gemdir copy instead of the Gem.path copy Ruby loads, so it attests not_affected while an unpatched --user-install / GEM_PATH copy runs #420 (fixed by Fix agent vex checking only one installed copy (#516) #517).
• Commented on Hosted gem redirect breaks a multi-line gem declaration (the Gemfile stops parsing) and drops a trailing if/unless modifier #340 (still reproduces) and Gem settings resolution skips Bundler's global config (~/.bundle/config / BUNDLE_USER_CONFIG), so a global cache_path or gemfile gets no warning or refusal and VEX attests an unpatched install #577 (agent arm verified end to end).
• No new issues.

False positives ruled out

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

Probe branches

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

Next

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

[github-actions[bot]]

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

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

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

Re-triage

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

Cells

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

Issues

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

False positives ruled out

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

Next

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

[github-actions[bot]]

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

Tested: main 5ca5623, release v5.0.1. No gem code has changed since b291caa; the only new commit is a Gradle vendoring fix. Linux only: Bundler 2.2.33 / 2.3.27 / 2.4.22 / 2.6.9 on Ruby 3.1.6, and 2.5.22 / 4.0.23 on Ruby 3.3.6. I used a scratch platform-gem variant of e2e_redirect_gem_build.rs (the mock upstream serves both vuln-gem-1.0.0.gem and vuln-gem-1.0.0-x86_64-linux.gem) with a real bundle install / bundle exec, and reverted it afterwards.

Re-triage

• Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831 is still open, and draft PR Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 isn't merged yet, so I didn't comment. I'll re-check it once the PR lands.
• 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 is still open (agent:needs-human), with no gem code changes, so I didn't comment.
• There are no human replies on Bug hunt ledger: Bundler (RubyGems) #316.

Cells (backlog item: platform-gem eject on 2.2–2.5)

Cell	2.2.33	2.3.27	2.4.22	2.5.22	2.6.9	4.0.23
Hosted platform-gem redirect → converge → bundle exec loads the patched copy	pass	pass	pass	pass	pass	pass (run 57)
vendor eject dry/wet → frozen fresh install loads the patched copy	pass	pass	pass	pass	pass	pass (run 57)
Ejected → vendor --revert / rollback / remove → frozen fresh install	pass	pass	pass	pass	pass	pass (run 57)
Stale-install guard, pristine -x86_64-linux dir left installed	over-warns (Bundler fetches the patched gem)	—	over-warns	over-warns	true positive (stale copy loads)	true positive (stale copy loads, phantom platform entry locked under the patch registry)

Bundler 2.2–2.4 lock only the x86_64-linux variant (PLATFORMS x86_64-linux). Bundler 2.5.22 on Ruby 3.3 already locks both variants, like 2.6+.

Filed: nothing new.

Ruled out

• The stale-install guard flags a platform-suffixed install dir after a hosted redirect to the ruby-platform patched gem, and same-run --vex exits 1. On 2.6.9 and 4.0.23 the guard is right: bundle install keeps the installed platform copy and bundle exec prints VULNERABLE. On 2.2–2.5 Bundler fetches the patched ruby gem, so the warning is only conservative there. The guard can't know which Bundler will run, so I added this to Known non-bugs rather than filing it.
• vendor re-run after a wet eject reports noManifest (exit 0). That's the documented manifest-less no-op; the ledger keeps the entry.

Probes: none. macOS / Windows probe branches are still blocked (push-triggered runs haven't started since 2026-10-05).

Next

1. Re-check Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831 when Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 merges.
2. On Bundler 4.x, if a platform project converges before applying the stale-guard remedy, the lock records a phantom x (V-x86_64-linux) under the patch registry (a fresh frozen install exits 16). Check that the remedy plus bundle install re-converges, and that rollback / remove restore a frozen-installable pair.
3. 4.1.0 final when it ships; 2.2 / 2.4 legs on the next main that touches gem code.

[github-actions[bot]]

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

Tested: main 5ca5623 (unchanged since run 58), release v5.0.1. Linux only: Bundler 4.0.23 and 2.6.9 on Ruby 3.3.6. I used a standalone harness this time: a Python mock (an upstream compact index serving vuln-gem both as ruby and as x86_64-linux, the patch registry, and the patches API) with real gem build fixtures and real bundle install / bundle exec / frozen fresh installs.

Re-triage

• Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831: still open. PR Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 is ready for review but not merged, so I didn't comment.
• 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: still open (agent:needs-human). There are no gem code changes, so I didn't comment.
• There are no human replies on Bug hunt ledger: Bundler (RubyGems) #316.

Cells

Cell	Result
4.0.23 platform lock with CHECKSUMS, hosted scan	refused redirect_gem_platform_unsupported (documented)
4.0.23 platform lock without CHECKSUMS: redirect, stale-install warning naming the -x86_64-linux paths	pass
…bundle install before the remedy: phantom vuln-gem (1.0.0-x86_64-linux) under the patch registry, VULNERABLE loads, fresh frozen install exits 16	Bundler behaviour; the guard had warned
…re-scan --vex and standalone vex over phantom lock + stale install	pass (exit 1 no_applicable_patches, no attestation)
…remedy + bundle install: phantom dropped, PATCHED, frozen fresh install passes, vex attests	pass
…non-frozen fresh install from the phantom lock	pass (Bundler self-heals to the patched ruby gem)
…rollback / remove from the phantom lock	pass (fail-closed refusal, nothing written, git checkout remedy)
…rollback / remove after re-converging	pass (frozen fresh install of the restored pair)
2.6.9 hosted unwind, direct ~> 1.0 dep (no CHECKSUMS)	pass (restored as exact pin, documented #457)
2.6.9 hosted unwind, group :development, :test + require: false # keep	pass (options and comment kept)
4.0.23 hosted unwind with a non-rubygems.org upstream + CHECKSUMS	pass (documented refusal)

Filed: nothing. Commented / closed: nothing.

Ruled out

• rollback / remove refuse a CHECKSUMS lock whose upstream remote equals SOCKET_RUBYGEMS_URL but isn't rubygems.org. That variable only sets where rubygems.org's sha comes from; the e2e suites spell the upstream as rubygems.org on purpose. rubygems_locked (upstream/gem.rs:1480) accepts the stand-in, but it only gates the stale-cache warning. Added to Known non-bugs.
• manifest_not_found from rollback / remove on a hosted-only project: this was my harness. Without --patch-server-url, a 127.0.0.1 pin isn't a hosted pin (documented, "Patch hosts").

Probes: none. macOS / Windows probes are still blocked (no push-triggered runs since 2026-10-05).

Next

1. Re-check Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831 when Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 merges.
2. 2.6.9 unwind: transitive with a trailing blank line, and a CRLF Gemfile (after Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841).
3. 4.0.23 direct / group unwind with the upstream spelled https://rubygems.org + SOCKET_RUBYGEMS_URL.
4. 4.1.0 final when it ships; 2.2 / 2.4 legs on the next main that touches gem code.

[github-actions[bot]]

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

Tested: main cbbbdb9 (one pip-only commit since 5ca5623; no gem code changes since b291caa), release v5.0.1. Linux only: Ruby 3.3.6 with Bundler 2.6.9, 4.0.23 and 4.1.0.beta3 (still the newest on rubygems.org). Harness: a scratch test in e2e_redirect_gem_build.rs (not committed). After the hosted scan it respells the mock upstream as https://rubygems.org in the pair, serves it to Bundler through BUNDLE_MIRROR__HTTPS://RUBYGEMS__ORG/ and to socket-patch through SOCKET_RUBYGEMS_URL, and then runs real bundle install, bundle lock --add-checksums and frozen fresh installs.

Re-triage

• Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831: still open. PR Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 is still ready for review and not merged, so I didn't comment.
• 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: still open (agent:needs-human). There are no gem code changes, so I didn't comment.
• There are no human replies on Bug hunt ledger: Bundler (RubyGems) #316.

Cells: CHECKSUMS added by the user after a converged hosted redirect

Cell	2.6.9	4.0.23	4.1.0.beta3
Direct single-line decl: redirect (no-CHECKSUMS lock) → converge → bundle lock --add-checksums → frozen fresh install	pass	pass	pass
Re-scan --mode hosted over that lock (byte-identical)	pass	pass	pass
Manifest-less vex matrix over the fresh install	pass	pass	pass
rollback, then frozen fresh + in-place install (upstream sha re-derived, VULNERABLE bytes)	pass	pass	pass
remove, same checks	pass	pass	pass
Same cycle, decl in a group :development block (rollback and remove)	pass	pass	untested

This also closes backlog item 4's "4.0.23 direct / group unwind with the upstream spelled https://rubygems.org + SOCKET_RUBYGEMS_URL": pass.

Filed: nothing. Commented / closed: nothing.

Ruled out: nothing new.

Probes: none. A git push --delete of a leftover bughunt/bundler/* branch was denied by this session's permission policy. Nine leftover branches (2026-10-01 → 2026-10-28) still need a maintainer to delete them.

Next

1. Re-check Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831 when Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 merges.
2. 2.6.9 transitive unwind with a trailing blank line. It needs a transitive fixture; a standalone Python mock is cheaper than extending the Rust fixture.
3. CHECKSUMS added after a redirect: a superseding patch generation, and --add-checksums on an unconverged pair.
4. 4.1.0 final when it ships; 2.2 / 2.4 legs on the next main that touches gem code.

[github-actions[bot]]

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

Tested: main cbbbdb9 (unchanged since run 60; no gem code changes since b291caa), release v5.0.1. Linux only: Ruby 3.3.6 with Bundler 2.6.9, 4.0.23 and 4.1.0.beta3 (still the newest on rubygems.org). Harness: scratch tests in e2e_redirect_gem_build.rs (not committed), mock upstream on 127.0.0.1, real gem build fixtures, real bundle install / bundle lock --add-checksums / frozen fresh installs.

Re-triage

• Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831: still open; PR Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 still open and unmerged, so no comment.
• 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: still open (agent:needs-human); no gem code changes, so no comment.
• No human replies on Bug hunt ledger: Bundler (RubyGems) #316.

Cells

Cell	2.6.9	4.0.23	4.1.0.beta3
bundle lock --add-checksums on an unconverged pair (CHECKSUMS-less redirect, no install): Bundler moves the gem to the Socket GEM section, pins the patched sha, writes (= 1.0.0)!	pass	pass	pass
Re-scan --mode hosted over that lock (byte-identical, exit 0)	pass	pass	pass
Frozen fresh install from it (PATCHED bytes) + manifest-less vex matrix	pass	pass	pass
rollback from it (127.0.0.1 upstream with CHECKSUMS)	refused hosted_restore_refused, documented non-bug	same	same
Superseding patch generation on a converged lock the user then --add-checksums'd: section remote + CHECKSUMS sha swapped to gen 2, bundle lock byte-identical, frozen fresh install loads gen-2 bytes	pass	pass	untested
Same: vex in the project with the gen-1 install still materialized refuses (no_applicable_patches, stale warning on the scan); vex on the fresh install attests the gen-2 uuid	untested	pass	untested
Transitive hosted unwind, Gemfile ending in a blank line (no-CHECKSUMS lock, converged): rollback drops the appended tiny-dep source block, keeps the trailing blank line, frozen fresh install gets upstream tiny-ok	pass	pass	pass

Side observation (not a bug, already documented): rollback on an unconverged CHECKSUMS-less pair (Gemfile-only pin) reports manifest_not_found; that's the "Gemfile-only pin is out of reach" row.

Filed: nothing. Commented / closed: nothing.

Ruled out: nothing new.

Probes: none (leftover bughunt/bundler/* branches still block; see backlog).

Next

1. Re-check Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831 when Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 merges.
2. 4.1.0 final when it ships; 2.2 / 2.4 legs on the next main that touches gem code.
3. Superseding generation + user CHECKSUMS on 4.1.0.beta3; 2.6.9 vex leg.
4. 2.6.9 / 4.0.23 CRLF Gemfile hosted unwind (after Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 lands).

[github-actions[bot]]

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

Tested: main cbbbdb9 (unchanged since run 60; no gem code changes since b291caa), release v5.0.1. Linux only: Ruby 3.3.6 with Bundler 2.6.9, 4.0.23 and 4.1.0.beta3 (still the newest on rubygems.org). Harness: scratch tests in e2e_redirect_gem_build.rs (not committed), mock upstream + patch registry on 127.0.0.1, real gem build fixtures, real bundle install / bundle lock / frozen fresh installs.

Re-triage

• Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831: still open; PR Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 still open and unmerged, so no comment.
• 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: still open (agent:needs-human); no gem code changes, so no comment.
• No human replies on Bug hunt ledger: Bundler (RubyGems) #316.

Cells

Cell	2.6.9	4.0.23	4.1.0.beta3
Converged CHECKSUMS redirect → bundle lock --add-platform arm64-darwin x86_64-darwin java → re-scan --mode hosted byte-identical → frozen fresh install PATCHED → vex attests	pass	pass	pass
…then a superseding generation: section + CHECKSUMS swapped to gen 2, bundle lock byte-identical, frozen fresh install gets gen-2 bytes, vex attests the gen-2 uuid	pass	pass	pass
User-checksummed lock (CHECKSUMS-less redirect → bundle install → bundle lock --add-checksums) → superseding generation → bundle lock identical, frozen install gen 2, vex attests gen 2 (backlog item 5)	pass	pass (run 61)	pass
Hosted decl in group :development, converged; fresh checkout installed with BUNDLE_WITHOUT=development (env, and bundle config set --local without) + frozen: gem not installed; re-scan exit 0, lock unchanged, notInstalled: true	pass	pass	untested
Same: vex attests not_affected (redirected) from the lock pin	documented (see below)	documented	untested

Filed: nothing. Commented / closed: nothing.

Ruled out: vex attesting a hosted gem whose group is excluded by BUNDLE_WITHOUT (nothing installed) is the documented "With nothing installed, a discovered reference whose lock pins the artifact attests from that pin" rule (CLI_CONTRACT.md, VEX evidence table, hosted row). Not a bug.

Probes: none (leftover bughunt/bundler/* branches still block; see backlog).

Next

1. Re-check Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831 when Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 merges, then the 2.6.9 / 4.0.23 CRLF Gemfile hosted unwind.
2. 4.1.0 final when it ships; 2.2 / 2.4 legs (Ruby 3.1.6) on the next main that touches gem code.
3. BUNDLE_ONLY (Bundler 2.5+) and BUNDLE_WITHOUT on 4.1.0.beta3; the stale-install guard with an excluded group plus an unpatched system-gem copy.
4. bundle lock --remove-platform / --normalize-platforms over a hosted lock, and bundle remove vuln-gem followed by rollback / remove.

[github-actions[bot]]

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

Tested: main cbbbdb9 (unchanged since run 60; no gem code changes since b291caa), release v5.0.1. Linux only: Ruby 3.3.6 with Bundler 2.6.9, 4.0.23 and 4.1.0.beta3 (still the newest). Harness: scratch tests in e2e_redirect_gem_build.rs (not committed), mock upstream + patch registry on 127.0.0.1, real gem build fixtures, real bundle commands and frozen fresh installs.

Re-triage

• Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831: still open; PR Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 still open and unmerged, so no comment.
• 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: still open (agent:needs-human); no gem code changes, so no comment.
• No human replies on Bug hunt ledger: Bundler (RubyGems) #316.

Cells

Cell	2.6.9	4.0.23	4.1.0.beta3
Converged CHECKSUMS redirect → bundle lock --remove-platform x86_64-linux → re-scan exit 0, lock byte-identical → frozen fresh install PATCHED	pass	pass	pass
Same with bundle lock --normalize-platforms	pass	pass	pass
Same with --add-platform arm64-darwin then --remove-platform arm64-darwin x86_64-linux	pass	pass	pass
Converged CHECKSUMS-less redirect → bundle remove vuln-gem (Bundler drops the whole Socket source … do block) → rollback / remove: exit 1 manifest_not_found, Gemfile and lock untouched; frozen install passes; re-scan exit 0, skip with redirect_gem_version_not_locked (leftover install in vendor/bundle), nothing rewritten	pass	pass	pass
Hosted decl in group :development, converged CHECKSUMS lock; frozen fresh install with BUNDLE_ONLY=default / BUNDLE_ONLY=development / BUNDLE_WITHOUT=development: excluded → not installed, included → PATCHED; re-scan exit 0, lock byte-identical	pass	pass	pass

Filed: nothing. Commented / closed: nothing.

Ruled out: rollback / remove exiting 1 (manifest_not_found) after the user ran bundle remove on the hosted gem: there's nothing left to unwind and nothing is written. The re-scan warning there comes from the stale vendor/bundle copy that bundle remove leaves behind (documented redirect_gem_version_not_locked wording). Not bugs.

Probes: none (leftover bughunt/bundler/* branches still block; see backlog).

Next

1. Re-check Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831 when Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 merges, then the 2.6.9 / 4.0.23 CRLF Gemfile hosted unwind.
2. 4.1.0 final when it ships; 2.2 / 2.4 legs (Ruby 3.1.6) on the next main that touches gem code.
3. The stale-install guard with an excluded group plus an unpatched system-gem copy.
4. bundle update vuln-gem --conservative and bundle outdated over a converged hosted lock; bundle add of a second gem next to the Socket source block.

[github-actions[bot]]

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

Tested: main cbbbdb9 (unchanged since run 60; no gem code changes since b291caa), release v5.0.1. Linux only: Ruby 3.3.6 with Bundler 2.6.9, 4.0.23 and 4.1.0.beta3 (still the newest per gem search -r --pre). Harness: scratch tests in e2e_redirect_gem_build.rs and e2e_redirect_gem_stale_install.rs (not committed), mock upstream + patch registry on 127.0.0.1, real gem build fixtures, real bundle commands and frozen fresh installs.

Re-triage

• Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831: still open; PR Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 still open and unmerged, so no comment.
• 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: still open (agent:needs-human); no gem code changes, so no comment.
• No human replies on Bug hunt ledger: Bundler (RubyGems) #316.

Cells (backlog item 5)

Cell	2.6.9	4.0.23	4.1.0.beta3
Converged CHECKSUMS-less redirect → bundle outdated exit 0 → bundle update vuln-gem --conservative exit 0, lock byte-identical → frozen fresh install PATCHED → re-scan exit 0, lock byte-identical	pass	pass	pass
Then bundle add tiny-dep --version "~> 1.0" (appended after the Socket source … do block) → re-scan exit 0, Gemfile and lock byte-identical → frozen fresh install PATCHED	pass	pass	pass
Then rollback / remove <purl>: exit 0, Socket block gone, the added gem "tiny-dep" line and its DEPENDENCIES entry kept → frozen fresh install exit 0, lock byte-identical	pass	pass	pass
Same with a CHECKSUMS lock (4.0.23): outdated / update --conservative / add / re-scan / frozen install PATCHED pass; rollback refuses hosted_restore_refused (127.0.0.1 upstream, documented)	n/a	pass	n/a

Cells (backlog item 4, stale-install guard, OS/version-independent unit-level harness with a fake gem env gemdir)

Hosted decl in group :development, unpatched copy in the system gem home	Result
BUNDLE_WITHOUT=development (env)	warns redirect_gem_stale_install (shared-home flavor), purl not attested, exit 1
BUNDLE_WITHOUT: development in .bundle/config	same
BUNDLE_ONLY=default	same
BUNDLE_WITHOUT + BUNDLE_PATH: vendor/bundle	quiet, attests, exit 0 (#1001 rule)
No exclusion (control)	warns, exit 1

All consistent with CLI_CONTRACT.md's Gem stale-install guard: group exclusion isn't part of the judgment, so the guard stays conservative (the shared copy is what bundle install --with development would reuse) and never attests a stale purl. Recorded as a known non-bug.

Filed: nothing. Commented / closed: nothing.

Ruled out: the excluded-group warning above (conservative, no false attestation); rollback refusing on a CHECKSUMS lock with a 127.0.0.1 upstream (documented hosted_restore_refused).

Probes: none (leftover bughunt/bundler/* branches still block; see backlog).

Next

1. Re-check Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831 when Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 merges, then the 2.6.9 / 4.0.23 CRLF Gemfile hosted unwind.
2. 4.1.0 final when it ships; 2.2 / 2.4 legs (Ruby 3.1.6) on the next main that touches gem code.
3. bundle add of a gem that resolves from the patch registry's source (a second gem inside the Socket block), and bundle update --all over a converged hosted lock.
4. bundle lock --update vuln-gem / bundle lock --patch over a converged CHECKSUMS lock with the rubygems.org spelling + mirror (run-60 setup).

[github-actions[bot]]

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

Tested: main cbbbdb9 (unchanged since run 60; no gem code changes since b291caa), release v5.0.1. Linux only: Ruby 3.3.6 with Bundler 2.6.9, 4.0.23 and 4.1.0.beta3 (still the newest per gem search -r --pre). Harness: scratch tests in e2e_redirect_gem_build.rs (not committed), mock upstream + patch registry on 127.0.0.1, real gem build fixtures, real bundle commands and frozen fresh installs. After the hosted lock converged, the mock upstream started serving newer tiny-dep 1.0.1 and vuln-gem 1.0.1 (the original 1.0.0 bytes were served back unchanged).

Re-triage

• Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831: still open; PR Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 still open and unmerged, so no comment.
• 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: still open (agent:needs-human); no gem code changes, so no comment.
• No human replies on Bug hunt ledger: Bundler (RubyGems) #316.

Cells (backlog items 4 and 5). Each cell: the command → Gemfile byte-identical, lock keeps the patch-registry GEM remote → re-scan exit 0, Gemfile unchanged → frozen fresh install PATCHED, lock byte-identical → vex attests (redirected) → rollback → frozen install of the restored pair exit 0, lock byte-identical.

Command over a converged hosted lock	Lock / upstream spelling	2.6.9	4.0.23	4.1.0.beta3
bundle update --all (tiny-dep → 1.0.1, vuln-gem stays 1.0.0 on the exact pin)	no CHECKSUMS, 127.0.0.1	pass	pass	pass
bundle update --all	no CHECKSUMS, rubygems.org + mirror	pass	pass	pass
bundle update --all	CHECKSUMS, rubygems.org + mirror	pass	pass	pass
bundle lock --update vuln-gem	CHECKSUMS, rubygems.org + mirror	pass	pass	pass
bundle lock --patch	CHECKSUMS, rubygems.org + mirror	pass (no-op)	pass (no-op)	pass (no-op)
bundle lock --update tiny-dep	no CHECKSUMS, 127.0.0.1	pass	pass	pass
The three CHECKSUMS commands, 127.0.0.1 upstream	CHECKSUMS, 127.0.0.1	pass up to rollback, which refuses hosted_restore_refused (documented)	same	same

After rollback, the restored CHECKSUMS lines carry the fresh upstream sha for whatever version the update chose (tiny-dep 1.0.1), and a frozen install accepts the pair.

Filed: nothing. Commented / closed: nothing.

Ruled out:

• An exit-37 mismatched-checksums failure in my first attempt. My harness rebuilt tiny-dep 1.0.0 with gem build, which changed its sha. Serving the original bytes fixed it, so it was a harness artifact (now under Known non-bugs).
• bundle lock --patch without --update changes nothing. That's Bundler behavior.
• rollback refusing on a CHECKSUMS lock with a 127.0.0.1 upstream is the documented hosted_restore_refused.

Probes: none (leftover bughunt/bundler/* branches still block; see backlog).

Next

1. Re-check Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831 when Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 merges, then the 2.6.9 / 4.0.23 CRLF Gemfile hosted unwind.
2. 4.1.0 final when it ships; 2.2 / 2.4 legs (Ruby 3.1.6) on the next main that touches gem code.
3. bundle add of a gem that resolves from the patch registry's source (a second gem inside the Socket block).
4. Vendored stub-vs-lock runtime-dependency drift, if the service stub can diverge.

[github-actions[bot]]

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

Tested: main cbbbdb9 (unchanged since run 60; no gem code changes), release v5.0.1. Linux only: Ruby 3.3.6 with Bundler 2.6.9 and 4.1.0.beta3 (still the newest; 4.1.0 final hasn't shipped). Harness: the repo's e2e_vendor_gem_build.rs, plus scratch tests in e2e_redirect_gem_build.rs (not committed): mock upstream + patch registry, real gem build fixtures, real bundle commands and frozen fresh installs.

Re-triage

• Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831: still open; PR Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 still unmerged, so no comment.
• 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: still open (agent:needs-human); no gem code changes, so no comment.
• No human replies on Bug hunt ledger: Bundler (RubyGems) #316.

New in Bundler 4.1.0.beta3 (2026-10-28): override takes with: / in: (was to: / from:), and the lock records overrides in a new OVERRIDES section between DEPENDENCIES and CHECKSUMS. With override "other-dep", with: "vuln-gem", in: "parent", the lock keeps parent's original edge (other-dep), and no spec sub-line names vuln-gem. 4.1 also adds a CONTENT ADDRESSES section, which needs RubyGems 4.1 (Gem::ContentAddress); it's now on the backlog.

Cells

Cell	2.6.9	4.1.0.beta3
Repo vendored suite e2e_vendor_gem_build (--ignored, REQUIRED=1)	pass (11)	pass (11)
Hosted gem reached only through override …, with: "vuln-gem", in: "parent": scan appends the block, converging install, frozen fresh install, OVERRIDES kept intact	n/a	pass
Same, rollback / remove → byte-exact pair	n/a	fail #1989 (×2 each): a new top-level gem "vuln-gem", "1.0.0" plus vuln-gem (= 1.0.0) in DEPENDENCIES; frozen install passes, and bundle lock --update vuln-gem can't move past 1.0.0
Control: parent depends on vuln-gem normally, rollback / remove	n/a	pass (byte-exact)

Filed: #1989 (#1989). Commented / closed: nothing.

Ruled out: nothing new. #457 (closed) had the same symptom but a different cause (a missing blank line), so #1989 isn't a duplicate.

Probes: none (leftover bughunt/bundler/* branches still block them).

Next

1. Re-check Hosted gem rollback / remove turn a gem reached only through a Bundler 4.1 override …, with:, in: into a new top-level exact pin, so the project can no longer update past the vulnerable version #1989 and Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831 (Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841) once fixed.
2. Other OVERRIDES shapes on 4.1: override "vuln-gem", version: / :ignore_upper on the hosted gem, with: nil dropping tiny-dep, CHECKSUMS + rubygems.org spelling, and vendored mode over an override-reached gem.
3. CONTENT ADDRESSES with RubyGems 4.1 (gem update --system 4.1.0.beta3) over a hosted / vendored lock.
4. 4.1.0 final when it ships; 2.2 / 2.4 legs on the next main that touches gem code.

[github-actions[bot]]

[agent] Janitor: ledger drift. These issues are now closed, but this ledger still lists them as failing or awaiting a fix:

• Hosted gem redirect writes the Socket source … do block with LF endings into a CRLF Gemfile, leaving it with mixed line endings #1831 closed 2026-11-02 by Fix hosted gem block mixing CRLF Gemfile endings (#1831) #1841 (3595c583), still fail #1831 in the hosted CRLF row
• Hosted gem rollback / remove turn a gem reached only through a Bundler 4.1 override …, with:, in: into a new top-level exact pin, so the project can no longer update past the vulnerable version #1989 closed by Fix gem restore of Bundler 4.1 override targets (#1989) #1991 (318193c2), still fail #1989 in the rollback/remove row

Please re-verify on current main and update the ledger.

---

Generated by Claude Code

[github-actions[bot]]

[agent] 2026-11-13: Bundler (RubyGems) ledger reset by the maintainer

The ledger had grown to 97 KB of state plus 68 run entries, and every run re-read all of it. It now starts clean for the 5.1.0-era main:

• The discussion body (state/bundler.md) is a short summary again: one coverage row per workflow, a backlog, and a pointer to the known non-bugs. Every cell is marked untested, because main gained about 135 commits since the last run, including native-extension rebuilds (Rebuild gem native extensions in agent-mode apply (#1996) #1998, Rebuild gem native extensions from a relative crawl root #2048) and the Bundler hosted-mode fixes from the 5.1.0 review (Fix the defects found by the 5.1.0 full review: do no harm, Bundler hosted mode, VEX, monorepo scans #2052).
• The 152 known non-bugs moved to known-non-bugs/bundler.md on the bughunt/ledger branch, where runs search them instead of reading them.
• The old matrix and per-run notes are still in the branch history: git show ec2d4516f:state/bundler.md.
• INSTRUCTIONS.md changed for every bug-hunt routine: read only the state file and the two newest entries, keep the state file under 15 KB, use REST (GraphQL is blocked in cloud sessions), Linux only (the probe workflows are switched off), and a 90-minute time box.

The routine now runs twice a day and hunts in this order: the common path in all three modes, the workflows people really have, then friction.

[github-actions[bot]]

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

Tested: main 7c5240e (5.1.0; no git tags). Linux, Ruby 3.3.6, Bundler 2.5.23, 2.6.9 and 4.0.18. First run after the ledger reset.

Harness: the sandbox reaches rubygems.org but not the Socket patch API, so I used a standalone mock (Python) of the patch API and the patch registry next to the real rubygems.org: real rack / rake / puma gems, repacked with one changed file and the original metadata.gz (a gem build rebuild changes the gemspec, and the install refresh then refuses it: a harness artifact, not a bug). Loopback URLs need --patch-server-url on every command. Project: sinatra + puma + rake + a test group, rack transitive.

Re-triage: nothing to do. #1109 is agent:needs-human; #780 isn't a bughunt issue.

Cells

Cell	Result
Hosted common path (vendor/bundle): scan, install refresh, bundle install, frozen install, app loads patched code, list, vex, rollback byte-exact, install again	pass on 2.5.23, 2.6.9, 4.0.18 (4.0 with CHECKSUMS)
Hosted, fresh clone with deployment true	pass on 2.6.9
Hosted, shared rbenv gem home: warning, then the suggested bundle config set --local path vendor/bundle && bundle install	pass on 4.0.18
Hosted, gem with a native extension (puma, ext/*.c patch): compiled on install, vex, rollback restores the upstream build, bundle pristine	pass on 4.0.18
Hosted, transitive-only gem (added line, require: false)	pass on all three
Hosted, bundle add / bundle remove after patching, then rollback	pass on 2.6.9
Hosted, bundle outdated / bundle update after patching	fail #2070 on all three
Agent common path: scan, bundle install, apply --check, vex, bundle pristine (detected, vex refuses), apply, rollback; pair untouched	pass on 2.6.9 (vendor/bundle) and 4.0.18 (shared gem home)
Agent, native extension: rebuild, .so carries the patch, vex, rollback restores the original build	pass on 2.6.9
Agent, --no-gem-native-rebuild	apply and get pass; scan --mode agent fail #2069
Vendored	untested (the vendored archive format needs the Rust test harness; next run)

Filed

• scan --mode agent --no-gem-native-rebuild (and SOCKET_NO_GEM_NATIVE_REBUILD=1) still rebuilds the gem native extension and vex attests it; only apply and get honor the opt-out #2069: scan --mode agent --no-gem-native-rebuild (and the env var) still rebuilds the extension and vex attests it. Suspect agent_download.rs:1364 (..GlobalArgs::default() drops the flag).
• A hosted-patched gem disappears from bundle outdated and bundle update can no longer move it, and nothing in the scan output or docs says so #2070 (ux): a hosted-patched gem vanishes from bundle outdated and bundle update can't move it; no message or doc says so.

Commented / closed: nothing.

Ruled out

• "the patched gem's gemspec differs from the installed one" after a hosted scan: only with a mock gem rebuilt by gem build.
• vex / list say "No patches in this project" on a hosted project: only with loopback patch URLs and no --patch-server-url.
• vex exits 2 asking for a product in a project with no git origin and no gemspec: the message names --product; documented.

Not filed, worth a look later: the redirect_gem_no_checksums_section text says "bundler < 2.6 does not write one" on a lock written by 2.6.9 (2.6 doesn't write the section by default either).

[github-actions[bot]]

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

Tested: main 7c5240e (5.1.0; no git tags; same SHA as the last run, so the run went to the backlog). Linux. Ruby 3.3.6 with Bundler 4.0.18 and 2.5.22, Ruby 3.2.6 with 2.4.19, Ruby 3.1.6 with 2.6.9 and 2.3.27.

Harness: a standalone Python mock of the patch API and registry next to the real rubygems.org, with real rack 2.2.8, rake 13.0.6 and nokogiri 1.16.0 repacked with one changed file. New this run: the same mock serves vendored mode once the tarball artifact carries a sha512 SRI and a gem-stub-gemspec artifact (gem spec <gem> --ruby) is served beside it. The Rust harness is not needed.

Re-triage: #2069 and #2070 are open and claimed; main has not moved, nothing to re-check. #1109 is agent:needs-human.

Cells

Cell	Result
Hosted, multi-platform lock (7 platforms) with a precompiled nokogiri, a git gem and a path gem beside patched rack; rake transitive through the path gem	pass on 4.0.18: nokogiri refused (redirect_gem_platform_unsupported), the rest installs plain, frozen and in a deployment clone; list, vex; remove one gem at a time ends byte-exact
Hosted re-scan and --json	pass on 4.0.18 (pair unchanged, same warning)
Hosted monorepo from the root: root Gemfile, services/api/Gemfile (group block, two requirements), services/web/gems.rb (transitive)	pass on 4.0.18: all three wired, lock stable, frozen install, list and bare rollback cover all three, byte-exact
Hosted vendor/cache (bundle cache)	pass on 2.5.22: archives replaced, --local deployment clone runs patched code, rollback restores the archives byte-exact
Hosted, no CHECKSUMS lock, following the warning's remedy (bundle lock --add-checksums, re-scan)	pass on 2.6.9
Hosted common path on older Bundlers	pass on 2.4.19 (Ruby 3.2.6) and 2.3.27 (Ruby 3.1.6)
Hosted declaration shapes: hash rockets, multi-line, gem(...) if, tab indent, platforms:, install_if, git_source, CRLF pair without a final newline, gemspec project	pass on 4.0.18 (gemspec dev dependency refused with redirect_gem_declaration_not_visible)
Hosted, after patching: bundle check, doctor, info, lock --add-platform, update <other gem>, clean --force, binstubs	pass on 4.0.18
Vendored common path: scan, install, frozen, deployment clone, bundle exec rake / rackup, list, vex, outdated, rollback byte-exact	pass on 4.0.18 (vendor/bundle), with the warning in #2076
Vendored, shared gem home	fail #2075 on 2.6.9 and 4.0.18
Vendored, gem in a group do block or gems.rb	refused as documented

Filed

• Vendored gem scan exits 1 with "Gemfile.lock GEM specs has no entry" for a gem in the shared gem home that the project does not lock, where hosted mode skips it with a warning #2075: scan --mode vendored exits 1 ("Gemfile.lock GEM specs has no entry") for a gem in the shared gem home that the project doesn't lock (a Ruby bundled gem, another project's version). Hosted mode skips the same gem with redirect_gem_version_not_locked (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). The dry run says it would vendor it.
• vex warns vendored_tree_out_of_sync for every vendored gem after bundle install, and the remedy it names never clears it because Bundler keeps the unused registry copy #2076 (ux): vex warns vendored_tree_out_of_sync for every vendored gem after bundle install; the remedy (re-run the install) never clears it, because Bundler keeps the unused registry copy. Only bundle clean --force does.

Commented / closed: nothing.

Ruled out

• vex from a monorepo root attests only the root project while scan, list and rollback cover the directories below: documented ("vex, apply, repair, remove and rollback <target> act on the one project at --cwd").
• remove rack from a monorepo root where only the sub-projects pin rack: "No patch found matching identifier", exit 1. Same rule; the message doesn't name the directories below, which the contract promises only when --cwd holds no patch state at all.
• vex --json without --output is an error (json_requires_output): documented.

Not filed, worth a look later: redirect_gem_no_checksums_section still says "bundler < 2.6 does not write one" on a 2.6.9 lock; the remedy it names works.

[github-actions[bot]]

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

Tested: main 63f791d (5.1.0, tag v5.1.0; one commit since the last run, the experimental hot-patch subcommand). Linux. Ruby 3.3.6 with Bundler 4.0.18, 4.0.24, 4.1.0.beta3 and 2.5.22; Ruby 3.1.6 with 2.6.9.

Harness: the standalone Python mock again (patch API on --api-url / --proxy-url / --patch-server-url, compact index, gem-stub-gemspec), with real rack 2.2.8, rake 13.0.6 and bcrypt 3.1.20 (C source changed) repacked. Without a token the CLI calls the public proxy, so the mock must be passed as --proxy-url too.

Re-triage: #2069 still reproduces on 63f791d (the scan rebuilds bcrypt and vex attests it); #2070 code untouched. Both are claimed, no comment added. #1109 is agent:needs-human.

Cells

Cell	Result
Agent, 10-gem project with a git gem, a path gem (rake transitive through it) and native bcrypt: scan, app, re-scan, --json, apply --check, vex	pass on 4.0.18
Agent after bundle add / remove / clean --force / outdated / frozen install	pass on 4.0.18 (patches stay; Gemfile pair never touched)
Agent after bundle install --redownload	pass: apply --check and vex report not applied, apply restores, bcrypt rebuilt
Agent rollback (native build restored), then pristine	pass on 4.0.18
Vendored common path with a transitive-only gem (managed block): frozen, deployment clone, list, vex, re-scan	pass on 4.0.18 apart from #2076 and #2084
Vendored after bundle add / remove / update / update <gem> / outdated / check / doctor / lock --add-platform / cache	pass on 4.0.18 (lock stable; vendored gems are absent from outdated, as for any path gem)
Vendored remove <gem> then vendor --revert	pass on 4.0.18, byte-exact
Vendored, native gem	refused as documented (native extensions, exit 1), other gems vendored
Hosted common path + deployment clone + vex + rollback, with git and path gems	pass on 4.0.24 and 4.1.0.beta3
Hosted to vendored takeover (bcrypt stays hosted), mixed list / vex, rollback of both	pair byte-exact on 4.0.24; fail #2083 for the installed copies
Vendored common path + rollback	pass on 4.1.0.beta3

Filed

• Rolling back a gem that went from hosted to vendored leaves the patched installed copy in vendor/bundle: the app keeps loading patched code and bundle pristine / --redownload fail on the restored checksum #2083: after hosted, then vendored, then rollback, the patched installed copy and archive stay in vendor/bundle. The app keeps loading patched code; bundle pristine and --redownload exit 37 on 4.0.24 (2.5.22 and 2.6.9 reinstall the patch). Rollback's note says the next install fixes it.
• Vendored mode declares a transitive gem without require: false, so Bundler.require starts loading it at boot (hosted mode adds the option) #2084: the vendored managed block for a transitive gem has no require: false, so Bundler.require loads the gem at boot (rake: DSL and FileUtils on main). Hosted writes the option. 4.0.18, 2.6.9, 2.5.22.

Commented / closed: nothing.

Ruled out

• Agent: after bundle update rack moves the lock off the patched version, the old patched rack-2.2.8 dir stays in vendor/bundle until bundle clean, so apply --check passes and vex still attests rack@2.2.8. The statement names the old version only, and manifest entries are kept by design until --prune.
• Vendored rewrite drops a trailing # comment when the declaration has no keyword option (kept when it has one): already listed as cosmetic; revert restores it.
• Bundler 4.1.0.beta3 writes no OVERRIDES / CONTENT ADDRESSES section for an ordinary project, so those sections are still untested.

[github-actions[bot]]

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

Tested: main 63f791d (5.1.0; same SHA as the last run, so the run went to the backlog). Linux. Ruby 3.3.6 with Bundler 4.0.18 and 2.5.22; Ruby 3.1.6 with 2.6.9.

Harness: the standalone Python mock again, rebuilt from the state file's notes (--api-token fake --org test plus the three URL flags), with real rack 2.2.8, rake 13.0.6, bcrypt 3.1.20 (C source) and nokogiri 1.16.0 (first a C source, then lib/nokogiri/version/constant.rb) repacked.

Re-triage: main has not moved; #2069, #2070, #2075, #2076, #2083 and #2084 are open and unchanged, nothing to re-check. #1109 is agent:needs-human.

Cells

Cell	Result
Vendored common path on a CRLF pair (scan, install, frozen, app, vex, rollback)	pass on 4.0.18, byte-exact, CRLF kept in both files
Vendored common path on locks without CHECKSUMS, with a deployment clone	pass on 2.5.22 and 2.6.9
Vendored on a 7-platform lock with a precompiled nokogiri beside the vendored gems	pass on 4.0.18 (PLATFORMS and the nokogiri variants untouched, frozen install, rollback byte-exact)
Agent on gems.rb / gems.locked, user gem home (GEM_HOME), group block, native bcrypt: scan, app, frozen install, apply --check, vex, fresh gem home then apply --dry-run / apply, rollback, pristine	pass on 2.5.22
Agent, multi-platform lock, precompiled nokogiri-1.16.0-x86_64-linux: a Ruby-file patch	pass on 4.0.18 (applied, vex attests)
Agent, same gem, a C-source patch	refused as documented (native_extensions_unsupported, nothing written, rack still patched)
Agent, native build failure (MAKE=/bin/false)	pass on 4.0.18: native_extension_build_failed, sources and build put back, app works, vex omits it, a later apply succeeds
Hosted, shared gem home: plain scan, then vex	pass on 4.0.18 (warning, vex omits all three as not_applied)
Hosted scan --gem-refresh-shared with native bcrypt: app, vex, pristine, frozen install	pass on 4.0.18
Hosted rollback --gem-refresh-shared	pass on 4.0.18 (upstream copy back, pristine passes)
Hosted rollback / remove without the flag, then the remedy the warning names	fail #2086 on 4.0.18 and 2.6.9
Hosted, precompiled gem moved to the ruby platform (force_ruby_platform, new lock), scan, the rm -f … && bundle install remedy, vex	patched gem installs and loads on 4.0.18 and 2.6.9; fail #2087 for standalone vex

Filed

• Hosted gem rollback / remove tell the user to re-run with --gem-refresh-shared, but the re-run exits 1 with "nothing to roll back" and the patched gem stays in the shared gem home #2086 (ux): hosted rollback / remove on a shared gem home warn "re-run with --gem-refresh-shared", but the re-run exits 1 ("No patches in this project; nothing to roll back."). The patched install and archive stay; on 4.0.18 bundle pristine then exits 37 and leaves the gem uninstalled.
• Standalone vex refuses a hosted gem as not_applied because of a leftover <gem>-<version>-x86_64-linux directory that has no gemspec, after the scan's own rm -f … && bundle install remedy #2087 (ux): after the scan's own stale-copy remedy, the gems/nokogiri-1.16.0-x86_64-linux/ directory is left without a gemspec, and standalone vex still counts it and omits the gem as not_applied (exit 1). A re-scan prints no warning and scan --vex attests. bundle clean --force clears it.

Commented / closed: nothing.

Ruled out

• gem "nokogiri", force_ruby_platform: true in the Gemfile, or bundle config set force_ruby_platform true followed by bundle lock on the existing lock, keep every platform variant in the lock on Bundler 4.0.18, so hosted mode still refuses the gem (redirect_gem_platform_unsupported). Only a new lock (or bundle lock --remove-platform) gives a ruby-only lock. That is Bundler's behavior and the refusal is documented.
• Vendored mode rewrites gem "rack", "~> 2.2.3" to the exact pin "2.2.8"; revert restores the range. Already listed.
• The 2.6.9 hosted scan warns that rake 13.0.6 (a gem Ruby 3.1 bundles in the shared gem home) is "installed on this machine but this project doesn't lock it". Documented skip (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).