claude-code - 💡(How to fix) Fix [FEATURE] Trust plugin hooks from strictKnownMarketplaces under allowManagedHooksOnly without force-installing every plugin

Problem

allowManagedHooksOnly: true is binary: it blocks all non-managed hooks, including hooks shipped by plugins from organization-vetted marketplaces listed in strictKnownMarketplaces.

Today, the only way for an admin to make plugin hooks executable under allowManagedHooksOnly is to list each plugin in managed enabledPlugins. But that setting is force-install + force-enable: the plugin shows up to every user with managed scope and cannot be disabled or uninstalled. There is no managed-settings primitive that means "this plugin is allowed (and its hooks are trusted) if the user chooses to install it."

The result is a missing middle in the trust model:

Context

This was previously raised as #42581, which was auto-closed as stale by the github-actions bot on 2026-05-11 with the note "Please open a new issue if this is still relevant." It is — re-filing per that guidance.

Proposed solution

Two equally reasonable shapes; either would close the gap:

Option A — flag on strictKnownMarketplaces: elevate any plugin installed from an allowlisted marketplace to "managed-trust" for hooks (and ideally MCP servers, addressing #46296).

{
  "allowManagedHooksOnly": true,
  "allowPluginHooksFromKnownMarketplaces": true,
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "<owner>/<marketplace-repo>" }
  ]
}

Option B — separate per-plugin allowlist: introduce allowedPlugins (or enabledPlugins accepting a wildcard like "*@<marketplace-name>": true) that whitelists plugins for trusted-hook execution without force-installing them.

{
  "allowManagedHooksOnly": true,
  "allowedPlugins": {
    "<plugin-name>@<marketplace-name>": true
  }
}

Option A is simpler and aligns the trust model with the existing source-level allowlist. Option B preserves per-plugin granularity if marketplaces host a mix of vetted and community plugins.

Use case

Current workaround and why it doesn't scale

• Define every hook in managed settings. Works, but decouples hooks from the plugins they belong to and forces an admin config change for every hook update.
• Force-install via managed enabledPlugins. Works for hook trust, but takes away user choice — every plugin becomes mandatory and unmanageable from the user's side. Optional tooling cannot be offered selectively.
• Drop allowManagedHooksOnly. Restores plugin hooks but also re-enables arbitrary user/project hooks, defeating the security posture.

None of these preserves both user choice and managed hook trust simultaneously, which is the primitive that appears to be missing.

Out of scope / non-goals

• Not asking to relax the trust model for unknown marketplaces — strictKnownMarketplaces remains the source-of-truth gate.
• Not asking for hook-level granularity within a plugin — plugin-level trust is sufficient.

Related

• #42581 — original feature request, auto-closed as stale.
• #46296 — same shape of asymmetry on the allowedMcpServers surface; ideally addressed by the same primitive (Option A naturally extends to MCP servers).