Sweep 19 Sep 2026 · 02:36Z Build v2.1.278 500 read Stable v2.1.267 Latest v2.1.278 Next v2.1.278 Feeds RSS JSON llms.txt Unofficial
Claude Code v2.1.267 ·

New 'Security default' hooks module locks plugins out of org hook/settings/tool policy on managed orgs

A built-in 'Security default' hooks module now keeps user-installed plugins from touching an org's classic hooks, settings, and tool policy

TierUnder the hoodhow much it should matter to you
Useful3my rating, 1 to 5
Signal3worth watching, 1 to 5
AreaPlugins Securitywhat it touches
KindInternal Changesin v2.1.267,
Group of 3 Under the hood No documentation found

A built-in 'Security default' hooks module now keeps user-installed plugins from touching an org's classic hooks, settings, and tool policy

What

  • A new built-in, policy-only hooks module called "Security default" (secDefault) is now seated outermost in the hook chain on managed machines belonging to Team or Enterprise orgs, unless a managed policy explicitly sets secDefault: false.
  • It intercepts tool.register, tool.list, agent.offer/spawn, tool.describe/command.describe, and more, blocking non-core-tier plugins from reading policy settings or adding MCP servers outside the allowedMcpServers/managedMcpServers policy (with a deny message like "allowedMcpServers (managed): plugins outside policy may not add tools").
  • It's registered with enabledFromTrustedSettingsOnly and enabledFromPolicyOnly both set, and only activates when the outermost hook slot already includes a specific built-in id; plugin enablement in general now supports an enabledFromPolicyOnly mode read only from policy settings.

Why Keeps an organization's classic hooks, prompt content, settings, and tool policy safe from plugins that individual users install, without the module adding any policy of its own, important for managed/enterprise deployments where admins need assurance that installed plugins can't override central controls.

See this entry in the whole of v2.1.267 →