Repository navigation
v5 Bundler plugin cleanup leaves .bundle/plugin registered in every other checkout, so bundle install crashes with LoadError on Bundler 2.3–2.5 #1295
Description
[agent] Found by the scheduled Bundler (RubyGems) bug-hunt routine (ledger #316).
Summary
v5 removed setup, including setup --remove, which since #210 also cleared Bundler's machine-local plugin registration (.bundle/plugin/index). The v5 cleanup instructions don't fully replace it:
docs/migrating-to-v5.md:93tells the person migrating to remove the Gemfileplugin "socket-patch"block, runbundle plugin uninstall socket-patch, and delete.socket/bundler-plugin/.CLI_CONTRACT.md("Agent mode in CI (v5.0:setupremoved)") and thesocket-patch setuperror inlib.rs:334only say to remove the block and.socket/bundler-plugin/by hand. Neither mentionsbundle plugin uninstall.
.bundle/ isn't committed, so bundle plugin uninstall only clears the checkout it runs in. Any other checkout that ran bundle install while the v4 plugin was wired still has the registration: other developers' machines, persistent CI runners, and the migrator's own checkout if they followed CLI_CONTRACT.md. Once those checkouts pull the cleanup commit, .bundle/plugin/index points at a plugins.rb that no longer exists:
- Bundler 2.3, 2.4 and 2.5: every
bundle installaborts withLoadError: cannot load such file -- …/.socket/bundler-plugin/plugins.rb(exit 1). Bundler 2.5 is the default on Ruby 3.3. - Bundler 2.6 and 4.0: the install prints "The following plugin paths don't exist … Continuing without installing plugin socket-patch" on every run. That's the residue fix(gem): setup --remove clears bundler's machine-local .bundle/plugin registration #210 fixed for v4.
bundle exec and bundle check still work. Running bundle plugin uninstall socket-patch (or deleting .bundle/plugin) in the affected checkout recovers it, but nothing tells those users to do that.
Impact
After a team migrates to v5 as documented, every teammate and persistent runner on Bundler ≤ 2.5 gets a crashing bundle install. The error doesn't mention socket-patch, and there's no v5 command that cleans it up.
Repro (Linux, Ruby 3.3.6)
npm pack @socketsecurity/socket-patch-linux-x64-gnu@4.0.0 && tar xzf socketsecurity-*.tgz # v4 binary
export BUNDLER_VERSION=2.5.22
mkdir app && cd app
printf 'source "https://rubygems.org"\ngem "colorize", "0.8.1"\n' > Gemfile
bundle config set --local path vendor/bundle
../package/socket-patch setup --yes # v4: managed plugin block + .socket/bundler-plugin/
bundle install # registers the plugin in .bundle/plugin/index
# The migration commit as it arrives in a teammate's checkout (block and dir removed):
printf 'source "https://rubygems.org"\ngem "colorize", "0.8.1"\n' > Gemfile
rm -r .socket/bundler-plugin
bundle install; echo "exit $?"
# LoadError: cannot load such file -- …/app/.socket/bundler-plugin/plugins.rb
# …/bundler/plugin.rb:347:in `load_plugin' … in `block in hook'
# exit 1
bundle plugin uninstall socket-patch && bundle install # recoversExpected vs actual
- Expected: following the v5 cleanup leaves every checkout able to
bundle install, assetup --removedid after fix(gem): setup --remove clears bundler's machine-local .bundle/plugin registration #210 ("clears bundler's machine-local .bundle/plugin registration"). CLI_CONTRACT.md says old hooks "keep working until you delete them; remove them by hand", which implies that removing them by hand is enough. - Actual: removing the block and the plugin dir (the CLI_CONTRACT.md recipe, or the migration-guide recipe as it reaches any other checkout) breaks
bundle installon Bundler 2.3–2.5, and leaves a warning on every run with 2.6 and 4.0.
Matrix (each Bundler cell reproduced twice in a fresh project)
| OS | Ruby | Bundler | Result after the cleanup commit, plugin still registered |
|---|---|---|---|
| Linux | 3.3.6 | 2.3.27 | bundle install exit 1 (LoadError) |
| Linux | 3.3.6 | 2.4.22 | bundle install exit 1 (LoadError) |
| Linux | 3.3.6 | 2.5.22 | bundle install exit 1 (LoadError) |
| Linux | 3.3.6 | 2.6.9 | exit 0, "plugin paths don't exist" on every install |
| Linux | 3.3.6 | 4.0.18 | exit 0, same warning |
| Linux | 3.3.6 | 4.0.18, migrator ran bundle plugin uninstall first |
clean |
The failure is in Bundler's own plugin loader, so it doesn't depend on the OS.
First bad release
v5.0.0: setup and its --remove were dropped (#279). On v4.0.0, setup --remove cleared the registration (#210).
Suspect locations
docs/migrating-to-v5.md:93: the Bundler row listsbundle plugin uninstallas a one-time step. It doesn't say that every existing checkout needs it, orrm -rf .bundle/plugin.crates/socket-patch-cli/CLI_CONTRACT.md:448-456andcrates/socket-patch-cli/src/lib.rs:334: the removal recipe and thesetuperror omit the registration step entirely.
Possible directions: document the per-checkout step in all three places. Alternatively, have v5 (for example apply / scan on a gem project) detect a .bundle/plugin/index that registers socket-patch at a missing .socket/bundler-plugin path and warn with the one-line fix.
Activity
mikolalysenko commentedon Oct 9, 2026
[agent] Triaged as
priority:p1(Bundler). I confirmed it onmaina8e9397:docs/migrating-to-v5.md:93listsbundle plugin uninstall socket-patchas a one-time step. It doesn't say that every checkout that ranbundle installunder v4 needs to run it.CLI_CONTRACT.md:448-456names only the Gemfile block and.socket/bundler-plugin/..bundle/pluginto detect the stale registration.It isn't a duplicate. #1289 covers aligning help and docs with lockfile-first scans, not this cleanup step. No open or merged PR addresses it. It's open for a fix: either a docs fix in all three places, or a warning that names the one-line remedy.
Generated by Claude Code
mikolalysenko commentedon Oct 9, 2026
[agent] Claiming this issue (shared root cause: v5 dropped
setup --remove's Bundler plugin deregistration and nothing replaces it per checkout). Branch: agent/fix-bundler-stale-plugin-registration. Claim-ID: 2026-10-09T19:20:38Z-952924Generated by Claude Code
mikolalysenko commentedon Oct 9, 2026
[agent] Draft PR: #1367
Generated by Claude Code
Warn about stale v4 Bundler plugin registrations