MCP plugin tools skip permission prompt when not in allow or deny list

Bug

MCP plugin tools that are not listed in settings.json's permissions.allow or permissions.deny execute without a permission prompt. The expected behavior is a permission prompt (the "ask-first" default for tools in neither list).

The deny list works correctly — denied tools are filtered out of the deferred tool set and the model never sees them. But the three-state permission model (allow / deny / ask-first) collapses to two states for MCP plugin tools: deny or auto-allow.

Repro

1. Install an MCP plugin (e.g. slack@claude-plugins-official)
2. In settings.json, do not add any of its read tools to the permissions.allow list
3. Start a session. The plugin tools appear as deferred tools
4. Load a tool via ToolSearch and call it
5. Actual: tool executes without a permission prompt
6. Expected: permission prompt shown (tool is in neither allow nor deny)

Minimal settings excerpt

{
  "permissions": {
    "allow": [
      // ... no Slack tools listed ...
    ],
    "deny": [
      "mcp__plugin_slack_slack__slack_send_message"
      // ... other write tools denied ...
    ]
  },
  "enabledPlugins": {
    "slack@claude-plugins-official": true
  }
}

Calling mcp__plugin_slack_slack__slack_search_users (not in allow or deny) executes without prompting. The permission_prompt notification hook does not fire, and the audit log has no entry for the call.

Impact

• Users cannot achieve "ask-first" for MCP plugin tools — the only options are auto-allow (not denied) or auto-deny (in deny list)
• Removing a tool from deny to make it ask-first (e.g. slack_send_message_draft) silently auto-allows it instead
• permissions.allow entries for MCP plugin tools are redundant (all non-denied tools are already auto-allowed)
• Breaks the security model for users restricting plugin tool access

Environment

• Claude Code CLI (latest)
• macOS 15 (Darwin 25.5.0)
• Plugins: slack@claude-plugins-official, notion@claude-plugins-official