What
A session running as a Remote Control bridge child now drops dynamically supplied MCP servers unless the entry is the Remote Control meta server, and rebuilds even that one from the approved startup address and session id instead of trusting the file. There is no flag: this applies whenever the process is a bridge carrier child.
Details
- Five reasons are reported per rejected server, surfaced as warnings with a skip reason: the entry is foreign, the meta entry is not of type
http, its URL does not match, no approved startup address exists, or no session id exists. - A startup notice tells you MCP servers come only from the verified startup config.
Evidence
was not loaded: the Remote Control meta server entry must be type "http"
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Names in the bundle--mcp-config
The entry above is what we published on the day. These lines were added later, as Anthropic's own pages caught up, and they sit beside the original rather than replacing it.
Added since
A small documentation edit on All settings touched a line naming --mcp-config after this was published.
In cloud sessions, Claude Code also ignores server-delivered mid-session MCP updates, the path behind cloud session configuration and SDK `setMcpServers()` calls that reach those sessions. In-process `type: "sdk"` entries stay exempt there…settings-reference see the edit
Confirmed since
Anthropic's documentation has since written up --mcp-config, on CLI reference.
| `claude agents` | Open [agent view](/docs/en/agent-view) to monitor and dispatch parallel background sessions. Use `--cwd <path>` to show only sessions started under that directory, or `--json` to print active sessions as a JSON array fo…cli-reference see the edit
One source agreesOne thing we can check says the same as this entry.
Anthropic's documentation agrees
Anthropic's documentation has since written up --mcp-config, on CLI reference.