MCP connection uses stale cached settings (host/port) instead of current config, even after full app restart

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

An MCP server connection configured via claude_desktop_config.json continues using outdated connection settings from when the session/connection was first established, even after the underlying config file is updated and Claude Desktop is fully restarted. Only starting a brand-new conversation resolves it

What Should Happen?

Environment:

Platform: Windows 11
MCP server: mcp-obsidian (uvx-launched), connecting to the Obsidian "Local REST API with MCP" plugin (v4.1.3)
Steps to reproduce:

Configure an MCP server in claude_desktop_config.json with connection details in env (in this case OBSIDIAN_HOST, OBSIDIAN_PORT, OBSIDIAN_API_KEY).
Establish an MCP connection in a conversation and successfully use it (read operations worked fine).
Attempt a write operation through the same connection — it fails with an authorization error (40101), despite the API key being verified byte-for-byte identical between the config file and the target server's actual settings.
Fully quit and restart the desktop app, then retry the write in the same conversation — it now fails differently, with a connection error trying to reach port 27124, even though the config file has always correctly specified port 27125.
The config file was independently verified correct at every step (confirmed via direct file inspection, not just UI).
Expected behavior: After restarting the app, the MCP connection should re-read the current config file and connect using its current values (correct port, correct key).

Actual behavior: The existing conversation's MCP connection continued using a different, incorrect port than what was in the config file, even after a full app restart. The issue only resolved by starting an entirely new conversation, which established a fresh connection using the correct current config.

Additional notes: Read operations through the same connection worked throughout, while only write operations failed — suggesting the stale/incorrect connection state may only affect certain request types, or that read and write operations resolve their connection settings differently within the MCP client.

Error Messages/Logs

Steps to Reproduce

Configure an MCP server in claude_desktop_config.json with connection details in env (in this case OBSIDIAN_HOST, OBSIDIAN_PORT, OBSIDIAN_API_KEY).
Establish an MCP connection in a conversation and successfully use it — read operations worked fine.
Attempt a write operation through the same connection — it fails with an authorization error (40101), despite the API key being verified byte-for-byte identical between the config file and the target server's actual settings.
Fully quit and restart Claude Desktop, then retry the write in the same conversation — it now fails differently, with a connection error trying to reach port 27124, even though the config file has always correctly specified port 27125.
The config file was independently verified correct at every step (confirmed via direct file inspection, not just the UI).
Start a brand-new conversation and retry the same write — it succeeds immediately, using the correct current config

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

latest version

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_