You edit the project's shared MCP configuration to fix a server's URL while a session is open, then ask Claude to use that server. It still reaches the old address. You edit again, more carefully, with the same result, and a colleague suggests the file must be being ignored. What explains it?

The principle — Configuration read at startup becomes state, and editing the source of that state does not reach back into a process already holding it.

Why the key is correct — Claude Code reads the project's MCP configuration at session start. The running session is therefore working from the copy it loaded when it launched, which still names the old address, and it will go on doing so however many times the file is corrected. Exiting and starting a new session is what makes the edit take effect, and it is the documented remedy for exactly this symptom. The second, more careful edit produced the same result for the same reason, which is the clue that the file was never the problem.

Why the others are wrong — Nothing watches the file at all, so the absence of an effect is not in itself evidence that it is being ignored — the colleague's conclusion is the trap this question is built around. Sending another prompt re-runs a turn rather than re-reading configuration. And re-approval is a real requirement for servers from this file, but it governs whether the server may be used, not which definition of it the session holds.

Remember this — Edit the file, then restart the session. Until you do you are debugging a copy the session took before your change existed, and every further edit will look just as ineffective as the first one did.

Sources — Anthropic's Claude Code MCP quickstart, on when the file is read.