[Bug] Plugin-sourced MCP servers silently ignored under `allowManagedMcpServersOnly` enterprise policy despite `serverName` allowlist match
Bug Description
Title
Plugin-sourced MCP servers (--plugin-dir / .mcp.json inside a plugin) never load under enterprise allowManagedMcpServersOnly, even when serverName is on the allowlist — and no warning is shown
Environment
- Claude Code version: 2.1.220 (also reproduced on 2.1.234)
- Platform: darwin-arm64
- Auth: Claude Enterprise account, via server-managed (remote) settings
- Install method: Nix / home-manager (
nix-community/home-manager,programs.claude-code), wrapper invokesclaude --plugin-dir <nix-store-path>
Summary
A plugin supplying MCP servers via its .mcp.json (loaded through --plugin-dir) worked correctly before our org migrated from a Bedrock-backed deployment to Claude Enterprise. After the migration — same Claude Code version, same Nix-built plugin, same .mcp.json content — none of the plugin's MCP servers load. They do not appear in /mcp, claude mcp list, or as connected tools, and no blocked/denied message is shown for them (contrast with claude.ai connectors, which do print an explicit "blocked by enterprise policy" warning naming each one).
The only change between working and broken states was the backend/policy management layer (Bedrock → Claude Enterprise with server-managed settings). Enterprise-managed settings set:
{
"allowManagedMcpServersOnly": true,
"allowedMcpServers": [
{ "serverName": "splunk" },
{ "serverName": "splunk-observability" },
{ "serverName": "splunk-oncall" },
{ "serverName": "atlassian" },
... (serverName-only entries, no serverCommand/serverUrl entries at all)
]
}
Per the docs (code.claude.com/docs/en/managed-mcp#how-a-server-is-evaluated):
Stdio: Allowed when it matches aserverCommandentry. AserverNamematch counts only when the allowlist contains noserverCommandentries.
Since the allowlist has zero serverCommand entries, serverName matching should be active, and the plugin's stdio servers are named exactly splunk, splunk-observability, splunk-oncall — literal exact matches to the allowlist. Per the docs, this should load. It doesn't.
Reproduction
- Minimal plugin,
serverNamedeliberately chosen to be on our org'sallowedMcpServers:
````
testplugin/.claude-plugin/plugin.json: { "name": "test-plugin-probe2" }
testplugin/.mcp.json:
{
"mcpServers": {
"splunk": { "type": "stdio", "command": "echo", "args": ["hello-splunk-probe"] }
}
}
claude --plugin-dir ./testplugin mcp list→No MCP servers configured.- Same result with a name NOT on the allowlist (
probe-echo) — no distinguishing error/warning between the two cases. - Same result against the real, production home-manager-built plugin (5 real stdio/http servers, all with
serverNames present verbatim in the org allowlist). /mcpinside an interactive session shows only built-in servers (e.g.claude-in-chrome) — the plugin's servers don't appear at all, not even as blocked/disabled entries.--debug/-poutput only ever prints the claude.ai-connector block warning; nothing about plugin-provided MCP servers, allowed or blocked.
Expected
Either:
- The plugin's
serverName-allowlisted stdio servers load and appear in/mcpas connected, matching pre-Enterprise (Bedrock) behavior, OR - If plugin-sourced servers are intentionally excluded from
--plugin-dir, or intentionally excluded from theserverName-match path documented above,/mcpandclaude mcp listshould say so explicitly (as they do for claude.ai connectors), rather than silently reporting zero servers with no indication that policy (or something else) blocked them.
Impact
--plugin-dir-based MCP provisioning (the mechanism home-manager/nix-community's programs.claude-code.mcpServers option uses) is silently non-functional for any user under allowManagedMcpServersOnly enterprise policy, with no error surfaced to the user or admin. This affects reproducible, declaratively-managed dev environments (Nix/home-manager) specifically, since that's the primary consumer of --plugin-dir for MCP delivery outside the plugin marketplace flow.
Environment Info
- Platform: darwin
- Terminal: intellij
- Version: 2.1.220
- Feedback ID: 834e058e-3000-4f40-92bc-ec4b88303de2
Errors
[]