[Bug] Plugin-sourced MCP servers silently ignored under `allowManagedMcpServersOnly` enterprise policy despite `serverName` allowlist match

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Sep 16, 2026

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 invokes claude --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 a serverCommand entry. A serverName match counts only when the allowlist contains no serverCommand entries.

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

  1. Minimal plugin, serverName deliberately chosen to be on our org's allowedMcpServers:

``
testplugin/.claude-plugin/plugin.json: { "name": "test-plugin-probe2" }
testplugin/.mcp.json:
{
"mcpServers": {
"splunk": { "type": "stdio", "command": "echo", "args": ["hello-splunk-probe"] }
}
}
``

  1. claude --plugin-dir ./testplugin mcp list → No MCP servers configured.
  2. Same result with a name NOT on the allowlist (probe-echo) — no distinguishing error/warning between the two cases.
  3. Same result against the real, production home-manager-built plugin (5 real stdio/http servers, all with serverNames present verbatim in the org allowlist).
  4. /mcp inside 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.
  5. --debug / -p output 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 /mcp as connected, matching pre-Enterprise (Bedrock) behavior, OR
  • If plugin-sourced servers are intentionally excluded from --plugin-dir, or intentionally excluded from the serverName-match path documented above, /mcp and claude mcp list should 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

[]

View original on GitHub ↗