AI governance sounds like policy documents. Sometimes it is a name collision: on October 21, 2026, Claude Code v2.1.305 fixed a bug where a cloud/SDK-set MCP server was silently replaced by a same-named server from user settings — the managed definition lost, and nothing told anyone. Paste up to three config blobs below — user config, project .mcp.json, runtime-set servers — and this page resolves, name by name, which definition actually wins in your setup.
Short answer: the one the precedence rules say — when the client obeys them. The resolution order in this model is managed > runtime > project-local > project > user: the most controlled scope that defines a name wins it. The v2.1.305 bug broke exactly that: with a name defined in both runtime and user scopes, the user copy — the least controlled one — silently took over, so 100% of calls to that server name went to an implementation the operator never approved.
On October 21, 2026, Claude Code v2.1.305 shipped a fix for an MCP configuration bug, per the release notes: a server set by the cloud or SDK layer could be silently replaced by a same-named server defined in the user's own settings. No error, no warning, no log line most users would see — the session simply talked to a different server than the one the deploying layer intended.
Consider what that means in a governed environment. An organization sets an MCP server at the runtime layer precisely so that its implementation — its logging, its restrictions, its data handling — is the one employees' tools use. A stale or hand-edited entry in a user settings file, written months earlier for an experiment, carried the same name. From the fix's description, the user copy won. Every call to that server name went to the unapproved implementation for as long as both definitions existed.
This is a governance failure with no villain: nobody hacked anything, and no prompt was injected. It is configuration physics — multiple scopes, one namespace, and a resolution order that did the opposite of what the scopes' trust levels imply. The checker below implements the intended order (managed > runtime > project-local > project > user) so you can see your own collisions before a client resolves them for you, and it flags the specific trust-inversion shape — user and runtime defining the same name differently — that v2.1.305 was shipped to fix.
MCP server shadowing is what happens when two configuration scopes define a server under the same name with different definitions. The client must pick one; the one it picks is the one that actually runs, and the other becomes a shadow — present in a file someone trusts, describing a server that is not the one answering. Shadowing is dangerous precisely because every individual file looks correct: the user config is a valid definition, the runtime config is a valid definition, and only the resolution across scopes reveals that they have been fighting over one name.
Paste any combination of the three blobs (each is a JSON object with an mcpServers map, or a bare name-to-server map). The resolver applies the precedence model locally and renders the winner per server name, the scopes it shadows, and trust-inversion warnings. Environment values are never displayed — keys only. Leave a scope empty if you do not use it, or load the samples to see the v2.1.305 shape reproduced.
Honest scope note: this resolver implements the stated precedence model — managed > runtime > project-local > project > user — for the three paste-able scopes. Individual clients have historically resolved differently (that is the entire lesson of v2.1.305), project-local files are folded into the project blob here, and managed policy delivered out-of-band cannot be pasted. Treat the table as the intended resolution, then verify your client's actual behaviour. The full tool is the open-source mcp-server-shadow-auditor repo by Ingenious AI, which scans config files on disk across scopes.
| Rank | Scope | Why it ranks there |
|---|---|---|
| 1 (wins) | Managed policy | Set by the organization, not the user or the project. Governance means this layer cannot be overridden by anything below it. |
| 2 | Runtime-set (cloud / SDK) | Injected by the deploying layer for this session — the layer that knows the environment it is running in. |
| 3 | Project-local | Checked into or generated for one workspace; narrower than the project file shared with a team. |
| 4 | Project (.mcp.json) | Shared by the project; should beat personal settings for project work, and lose to anything the deployer set. |
| 5 | User config | Personal defaults. The broadest and least controlled scope — which is why a user entry silently winning over a runtime entry is a trust inversion, not a preference. |
If the winner table shows collisions — and especially a trust-inversion risk — work this list in order:
Per the October 21, 2026 release notes, v2.1.305 fixed a configuration bug in which an MCP server set by the cloud or SDK layer could be silently replaced by a same-named server from the user's own settings. The managed definition stopped being the one that ran, with no visible error — the session simply used the user-configured implementation instead.
The model this page implements is managed policy first, then runtime-set servers, then project-local, then the project .mcp.json, then user config. The principle is that more controlled scopes override less controlled ones. The v2.1.305 incident mattered because the effective order inverted that principle for one name: the least controlled scope won.
Collect every scope that can define servers — user config, project .mcp.json, any runtime or SDK-injected set — and compare the names. A name defined in two scopes with different commands is a collision; the resolver on this page renders the winner per the precedence model and flags user-versus-runtime differences as trust-inversion risks, showing environment key names only, never values.
Because governance is about which definition actually runs. A runtime-set server usually exists to guarantee logging, restrictions or data handling; a stale user entry with the same name can quietly replace it, as in the v2.1.305 case, so the controls everyone believes are active are not the controls in the session. Intent does not matter to the resolution algorithm.
This page resolves the blobs you paste under the stated model. The full mcp-server-shadow-auditor scans the actual config files on a machine — every scope a client reads, including ones you forgot exist — and reports the client's effective resolution per name. Use it to find scopes you did not know were in play.