Diagnosing Claude Code Configuration Scoping Issues Across a Team

What a Claude Code configuration scoping issue looks like

A Claude Code configuration scoping issue is a specific, recognisable failure: two developers work on the same repository, yet one consistently gets correct, convention-following output while the other does not. Nothing about the code differs. The prompts are similar. And still the results split along the line of who is running the session. Learning to diagnose this pattern is an evaluate-level skill, because the exam does not want you to recall a fact, it wants you to judge competing explanations and pick the root cause.

The reason this is worth its own knowledge point is that the obvious explanation is usually wrong. When output is inconsistent, the tempting conclusion is that the model is simply unreliable, or that one developer prompts better than the other. Both feel plausible and both are, in this scenario, almost always a misdiagnosis. The real culprit is structural: the two developers are not actually running the same configuration, even though they share the same repository.

Why developers diverge even on the same repo

To diagnose this, hold the mechanism clearly in mind. Each developer's session is a combination of scopes: their personal user file, plus the committed project and directory files. The committed parts are identical for everyone, because version control distributes them. The user file is not, it is unique to each machine and shared with no one. So two developers on one repo are running configurations that agree on the committed layer and can differ wildly on the personal layer.

Now the divergence makes sense. If a standard the whole team depends on was written into one developer's user file, that developer experiences it as 'the way things work', while everyone else, who never received that file, experiences its absence. The output is not inconsistent at random; it is perfectly consistent with each developer's actual configuration. The illusion of model flakiness comes entirely from assuming everyone has the same inputs when they do not.

This is why the diagnostic question is never 'why is the model inconsistent?' but 'why are the inputs different?' Reframing it that way points straight at scoping, and scoping points straight at version control: which layer carries this instruction, and does that layer reach everyone?

The evaluation method, step by step

Diagnosing the issue is a short, disciplined evaluation rather than a guess. First, confirm the symptom is genuinely per-developer and stable, the same person gets the same result repeatedly, which rules out random variation. Second, compare what each session actually loaded; running /memory in each developer's session reveals which configuration files are present, and a difference there is the smoking gun. Third, locate the specific instruction responsible for the desired behaviour and note its scope. Fourth, ask the decisive question: is that scope version-controlled? If the instruction lives in a user file, you have your root cause, and the remedy writes itself.

The reason this beats rewording or model-tweaking is that it tests the right hypothesis. Rewording assumes the instruction is loaded but weak; lowering temperature assumes the model is the variable. The scoping method instead checks whether the instruction is even present for the developer who lacks the behaviour, which, on a shared repo, is where the truth almost always lies.

Working a real diagnosis

The scenario below is the archetype the exam draws from. The skill on display is not knowing the answer in advance but evaluating the options and converging on the cause.

Common misreadings to avoid

The two misjudgements below are exactly the distractors the exam uses, because they are what practitioners reach for first.

Ruling out the look-alike causes

Part of what makes this an evaluate-level skill is that several explanations look reasonable and you have to actively rule them out rather than simply assert the right one. Model non-determinism is the most seductive: large language models do sample, so 'the model is just inconsistent' sounds technically literate. The reason it fails here is the shape of the evidence. Sampling variation is random and would not align cleanly with which person is at the keyboard; a stable split where one developer always gets the behaviour and another never does is not noise, it is a difference in inputs.

Prompt quality is the second look-alike. It is true that vague prompts produce worse output, but a consistent, rule-shaped absence of the same behaviour, every endpoint missing a test, every review skipping the same convention, is not the signature of occasional sloppy prompting; it is the signature of a rule that one developer's session simply does not contain. A third decoy is environment or tooling, blaming an editor plugin or a version mismatch, which is worth a glance but rarely survives a quick /memory comparison, because that comparison shows the configuration files directly. Eliminating these alternatives is not busywork; demonstrating that you considered and dismissed them on the evidence is exactly the reasoning the question is built to test.

The wider scoping picture: settings precedence and MCP scopes

A misplaced CLAUDE.md instruction is the most common scoping fault, but a complete diagnosis recognises that Claude Code scopes settings and MCP servers by the same logic, and either can produce the identical "works for me, missing for them" symptom. Settings resolve by a fixed precedence: managed policy overrides command-line arguments, which override local settings, which override project settings, which override user settings. When one setting is defined at several levels, the higher-precedence value wins, so a change made at a lower scope can look ignored simply because something above it is quietly taking priority.

MCP servers carry their own three scopes, selected with --scope: local is the default and is private to one developer in one project, project is shared with everyone through a committed .mcp.json, and user is available across all of that developer's projects but private to them. A server registered at local or user scope appears missing to teammates for exactly the same reason a user-level CLAUDE.md rule does, it was never shared. A notorious trap here is naming history: local was once called project and user was once called global, so older guides and rollout scripts can configure the wrong scope while looking correct on the page.

The diagnostic instinct is unchanged across all three layers. Whether the divergence rides on an instruction, a setting, or an MCP server, ask which scope carries it and whether that scope actually reaches everyone, then relocate it up to a shared, committed scope if the whole team is meant to have it.

Preventing the issue, not just fixing it

A strong answer does more than repair the current divergence; it removes the conditions that let it happen. The durable prevention is a team norm: anything the team relies on lives in the committed project configuration, full stop. Personal files are for genuinely personal preferences, never for standards others quietly depend on. When that norm holds, a new joiner inherits the complete working setup from their first clone, and there is no hidden personal layer for the team's behaviour to leak into.

A lightweight, repeatable checklist makes the diagnosis fast every time it recurs. Confirm the symptom is stable and per-developer, not random. Compare loaded files across the affected sessions with /memory. Locate the instruction responsible for the desired behaviour and read off its scope. Ask whether that scope is version-controlled, and if it is not, relocate the instruction into the committed project file and commit it. Following those four steps converts what feels like a mysterious reliability problem into a routine, two-minute fix, and turning mysteries into routines is precisely the mark of architectural maturity the certification is assessing.

Carrying the lesson beyond configuration

The reasoning pattern this knowledge point trains, distrust the explanation that blames randomness, and check whether the inputs actually differ, generalises well beyond CLAUDE.md. The same instinct serves you when an agent works in one environment but not another, when a pipeline passes locally and fails in continuous integration, or when two supposedly identical setups behave differently. In each case the disciplined move is to compare what each side actually received rather than to assume the component in the middle has become unreliable.

For this specific topic the comparison is concrete and fast: list the loaded files, find the rule, read its scope, and the fix is almost always relocation into a shared, committed file. Holding that method confidently is what lets you walk into a vague, finger-pointing situation, where one developer insists the model is broken and another insists they are prompting fine, and walk out a few minutes later with a one-line change that ends the divergence for good. That is the difference between reacting to inconsistency and actually resolving it.

How this shows up on the exam

This is one of Domain 3's evaluate-level knowledge points, and it appears as a judgement question: you are given a believable scenario with several tempting explanations, model inconsistency, bad prompting, a need to re-train, and asked to identify the true root cause and the appropriate fix. The winning move is to recognise the per-developer signature, reason about which scope carries the instruction, and connect it to version control. If your answer relocates a standard from an unshared scope into the committed project configuration, you are demonstrating exactly the architectural judgement the certification is testing for.

Watch and learn

Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.

Mark Kashef

Master ALL 7 Levels of Claude Code Memory

Why watch: Lays out the precedence between user, project, and directory memory, the exact knowledge needed to trace why two developers get different behaviour.

More videos for this concept

Master ALL 7 Levels of Claude Code Memory

Mark Kashef

Claude Code's Memory System: The Full Guide (Most Developers Miss 90% of This)

DIY Smart Code

Claude Code best practices | Code w/ Claude

Anthropic