Bundler "frozen mode, but the dependencies in your Gemfile changed"
By Daniel Zoghalchali·Latchkey
In frozen (or --deployment) mode Bundler refuses to modify Gemfile.lock. When the Gemfile no longer matches the committed lockfile, Bundler reports the exact gems that were added, removed, or changed and stops rather than silently updating the lock.
What this error means
bundle install fails with "Your bundle is locked, but the dependencies in your Gemfile changed" (or "frozen mode"), listing the gems you added or removed. It only happens in CI because frozen mode is on there but not locally.
bundler
The dependencies in your gemfile changed, but the lockfile can't be
updated because frozen mode is set
You have added to the Gemfile:
* rspec-rails
Run `bundle install` elsewhere and add the updated Gemfile.lock to
version control.
Diagnose it: Ruby version and platform
Bundler resolves against the Ruby version and the platform recorded in the lockfile. A runner on a different Ruby or a Linux platform missing from Gemfile.lock fails in a way that names a gem rather than the cause.
Terminal
ruby -v && bundle -v
cat .ruby-version 2>/dev/null
bundle platform
# the usual CI-only failure: Linux platform absent from the lockfile
bundle lock --add-platform x86_64-linux
bundle install --jobs 4 --retry 3
Common causes
Gemfile edited without committing Gemfile.lock
You added or removed a gem and committed the Gemfile but not the regenerated lockfile, so CI sees a mismatch in frozen mode.
Lockfile changes not staged in the commit
bundle install updated Gemfile.lock locally but the change was never staged, so the repo carries the old lock.
How to fix it
Regenerate and commit Gemfile.lock
Run bundle install locally and commit the updated lockfile alongside the Gemfile change.
Terminal
bundle install
git add Gemfile Gemfile.lock
# commit both together
Verify the lock matches in CI
Confirm frozen/deployment mode is intentional in CI (bundle config get frozen).
Keep it on so an out-of-date lockfile fails fast instead of drifting.
Add a pre-commit or CI step that runs bundle install --frozen and fails on a lockfile diff.
How to prevent it
Always commit Gemfile and Gemfile.lock in the same change.
Keep frozen/deployment mode on in CI so lockfile drift fails fast.
Run bundle lock --check (or bundle install --frozen) in a pre-merge job.
Frequently asked questions
What causes Bundler "frozen mode, but the dependencies in your gemfile changed"?
There are 2 common causes: gemfile edited without committing gemfile.lock and lockfile changes not staged in the commit. You added or removed a gem and committed the Gemfile but not the regenerated lockfile, so CI sees a mismatch in frozen mode.
How do I fix Bundler "frozen mode, but the dependencies in your gemfile changed"?
There are 2 fixes depending on which cause you have: regenerate and commit gemfile.lock and verify the lock matches in ci. Work through them in order, since the first is the most common.
What does Bundler "frozen mode, but the dependencies in your gemfile changed" actually mean?
bundle install fails with "Your bundle is locked, but the dependencies in your Gemfile changed" (or "frozen mode"), listing the gems you added or removed.
How do I stop Bundler "frozen mode, but the dependencies in your gemfile changed" happening again?
Always commit Gemfile and Gemfile.lock in the same change. The prevention section lists 3 changes that keep it from recurring.
