Gem::LoadError: is not the version that was activated in CI

Ruby activated one version of a gem, then the bundle required a different version. Once a gem version is activated it cannot be swapped, so Bundler raises a Gem::LoadError about the mismatch.

What this error means

Boot or a test fails saying a gem is not the version Bundler is using, or that a version is already activated. Common with default gems (json, rake, bigdecimal) that ship with Ruby and also appear in the lockfile.

Gem::LoadError: You have already activated rake 13.0.6,
but your Gemfile requires rake 13.1.0. Prepending `bundle exec` to your
command may solve this.

Common causes

Running without bundle exec

Invoking a binary directly loads a system/default gem version before the bundle is set up, then the locked version cannot be activated on top of it.

Default gem vs locked version

A gem bundled with Ruby (a "default gem") is auto-activated, conflicting with the different version pinned in Gemfile.lock.

Binstub not using the bundle

A stale or system binstub loads the wrong version before Bundler.setup runs.

How to fix it

Run through Bundler

1. Prefix the command with bundle exec so the locked version is activated first.
2. Regenerate binstubs with bundle binstubs --all so bin/* load the bundle.
3. Avoid invoking gem binaries directly on the PATH in CI.

bundle exec rake test
# regenerate binstubs that set up Bundler first
bundle binstubs --all --force

Pin a default gem explicitly

List the gem in the Gemfile so the bundle and the default-gem activation agree.

# Gemfile
gem 'rake', '13.1.0'

How to prevent it

• Always run project commands via bundle exec or bundle-aware binstubs.
• Pin default gems you depend on so versions do not diverge.
• Keep binstubs regenerated after Bundler upgrades.

Related guides