Resolving a Conflict Across the Memory Hierarchy

1. How both end up in context, and in what order:

CLAUDE.md files at different scopes are not mutually exclusive — they are all loaded and concatenated into the same context window, not resolved down to a single winner. The load order goes from broadest to most specific scope: managed policy, then user (~/.claude/CLAUDE.md), then project (./CLAUDE.md), then local (./CLAUDE.local.md). So in this scenario, the user-level "always use tabs" is read first, and the project-level "2-space indentation, don't fight Prettier" is read afterward, later in the same context.

2. Is there a defined winner?

No. Nothing in the loading mechanism resolves the contradiction — both instructions are simply present in context as competing claims. Claude may follow either one, and which one it picks is not guaranteed to be consistent across sessions or even within a long session. This is explicitly called out as a known failure mode: contradictory instructions across layered CLAUDE.md files can cause Claude to "pick one arbitrarily."

3. The correct fix:

The engineer should remove the "always use tabs" line from their personal ~/.claude/CLAUDE.md, or scope it (e.g., "use tabs in personal scripts under ~/scratch/, but defer to each project's own style"). Deleting the project-level instruction is wrong for the opposite reason it feels tempting: the project instruction is the one that's actually correct for this repo — it's enforced by Prettier, shared with the whole team via git, and describes the real formatting contract. The user-level instruction is a personal default that happens to be wrong for this specific project. The general principle: a personal, cross-project preference should almost never be an unconditional rule if it can conflict with a project's actual tooling — it should be phrased narrowly enough that it doesn't collide with more specific, better-informed project-level guidance, or left out of CLAUDE.md and stated only when it's actually true.

4. Does using CLAUDE.local.md change anything?

Putting "always use tabs" in a project-root CLAUDE.local.md changes where the conflict lives but not whether one exists. CLAUDE.local.md loads alongside CLAUDE.md at the same directory level (appended right after it), so both instructions are still concatenated into the same context and the contradiction is unchanged — Claude still sees two conflicting claims. What does change: CLAUDE.local.md is meant to be gitignored, so this conflict becomes purely the engineer's own problem rather than something checked into version control and inflicted on the rest of the team. It's a better place for a genuinely personal, project- specific override to live than the user-global file — but it still needs to actually agree with the project's real conventions to be useful, or it just creates a private, self-inflicted version of the same conflict.