Inconsistent transitive dependency version when WORKSPACE and MODULE.bazel coexist

Short answer

When both files exist, exactly one of them governs external dependency resolution, and the deciding factor is whether Bzlmod is enabled — not the presence of the files themselves.

• Bzlmod disabled (default on Bazel 6 and earlier): the WORKSPACE file wins. MODULE.bazel is ignored for external dependencies.
• Bzlmod enabled (via --enable_bzlmod, or by default on Bazel 7+): MODULE.bazel and its lockfile win, and WORKSPACE is ignored for module resolution.

So the flag does not merely tweak behavior — it flips precedence entirely. Non-repeatable builds across a team almost always trace back to developers landing on different sides of that switch.

Why versions diverge across machines

Three independent variables decide which graph you get:

1. Bazel version. Bazel 7 turned Bzlmod on by default. A mixed team on 6.x and 7.x silently resolves from different files.
2. Local .bazelrc files. A user-level ~/.bazelrc or an uncommitted .bazelrc can enable or disable Bzlmod for one developer only.
3. Overrides. --override_repository, --override_module, and local path overrides can shift resolved versions even when precedence is consistent.

Forcing consistent resolution

Pin the mode in the project-level .bazelrc (committed to version control), and pin the Bazel version with .bazelversion so Bazelisk enforces it:

# .bazelrc — pick ONE mode for the whole team
common --enable_bzlmod

# .bazelversion
7.4.1

Then commit MODULE.bazel.lock so the resolved transitive graph is shared, and audit for stray overrides:

bazel info release
grep -r "override" .bazelrc ~/.bazelrc 2>/dev/null
bazel mod graph | head -50

bazel mod graph shows the effective resolved module versions and is the quickest way to confirm two machines agree.

Verifying precedence yourself

To confirm which file is authoritative in your setup, declare the same dependency at different versions in each file, then build with and without the flag:

bazel info release
bazel mod graph   # fails or is irrelevant when Bzlmod is off
bazel --enable_bzlmod mod graph   # shows MODULE.bazel's version

If the resolved version changes when you toggle the flag, precedence is working as described, and your team's inconsistency is a configuration drift problem, not a Bazel bug.

Caveats

This describes well-established behavior for Bazel 6.x/7.x; exact flag names (--experimental_bzlmod vs --enable_bzlmod) vary by release, so check bazel help build on your version. If any legacy rules still expect WORKSPACE-defined repositories, removing the WORKSPACE file outright can break the build — migrate dependencies into MODULE.bazel first. One missing detail that would change this advice: your exact Bazel version, since defaults differ across the 6/7 boundary.