Skip to content
Latchkey

Ruby Binstub Runs the Wrong Gem Version vs bundle exec in CI

A committed binstub (bin/rspec, bin/rake) launches a different version than bundle exec does. The binstub was generated by an older Bundler, or it activates a system gem before setting up the bundle.

What this error means

bin/<tool> and bundle exec <tool> behave differently - one uses the locked version, the other a system/default version. Tests or tasks pass under one and fail under the other, which is confusing until you compare versions.

CI log
$ bin/rspec --version
RSpec 3.12.0
$ bundle exec rspec --version
RSpec 3.13.0   # the locked version

# bin/rspec activated an older rspec before Bundler.setup ran

Common causes

Stale binstub from an old Bundler

A binstub committed long ago has an outdated preamble that does not set up the current bundle correctly, so it activates a different version than the lockfile pins.

Binstub bypasses the bundle

A hand-edited or non-Bundler binstub does not require bundler/setup, so RubyGems activates a default/system version ahead of the locked one.

How to fix it

Regenerate the binstubs with the current Bundler

Recreate the binstubs so their preamble matches the installed Bundler and lockfile.

Terminal
bundle binstubs --all --force
git add bin/ && git commit -m "Regenerate binstubs"

Prefer bundle exec for consistency

When in doubt, run through Bundler so the locked versions are always used.

Terminal
bundle exec rspec
bundle exec rake

How to prevent it

  • Regenerate binstubs when you bump Bundler, and commit them.
  • Standardize on bundle exec or freshly generated binstubs, not both ad hoc.
  • Keep the Bundler version consistent across local and CI.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →