Your team commits a corrected server definition to the shared configuration. Everyone picks it up except one colleague, whose sessions still reach the old endpoint. They confirm they pulled the change and that the shared file on their disk is correct, and they see no warning of any kind. What is happening, and what fixes it?

The principle — A shared configuration is not the last word. It is one input to a precedence order, and anything a person has configured for themselves at a narrower scope sits above it.

Why the key is correct — When the same server is defined in more than one place, Claude Code connects to it once, using the definition from the highest-precedence source, and local scope is the highest of the three. The colleague added that server for themselves at some point, and their own entry has been winning ever since. Because the three scopes match duplicates by name, the shared entry is recognised as the same server and silently loses. Because the entire winning entry is used and fields are not merged across scopes, none of the corrected values reach them either. Removing their local entry is what lets the shared definition through.

Why the others are wrong — The shared file is demonstrably fine, since every other teammate reads it correctly from the same commit. Pulling and restarting cannot help, because the problem is not staleness. And the panel shows one connection rather than two, which is precisely why nothing looked wrong to them.

Remember this — When one person sees different configuration from everyone else, look for something they added for themselves. The shared file is rarely the culprit when it is shared correctly with everybody else, and precedence is the only mechanism that can make one machine disagree this quietly.

Sources — Anthropic's Claude Code MCP reference.