sec-default

sec-default is the security default for organizations. Function hooks give every plugin a say on every event, in chain order, and the plugins a person installs sit in the user tier, beneath the organization's prepend tier and above its append tier. Some of what an organization sets today (its classic hooks, its managed CLAUDE.md and rules, its settings, its MCP allowlist) was never within a person's reach before function hooks. Seated outermost, this plugin keeps exactly those out of the user tier's reach and adds no policy of its own. Everything else passes through untouched.

It has three moves and nothing else: continue past the user tier (next.to(e, "append")), refuse a user-tier caller by name ({ deny } when next.origin.tier is user), or pass (next(e)).

A subject's provenance is the event's pinned e.provider. Policy is read through $.settings.read({ source: "policy" }), one read serving a burst. Both fail closed, so an unreadable policy counts as a policy in force.

The module is hooks/register.ts, and hooks/policy/ reads the managed settings it decides by. Each event group below is handled from the outermost seat.

classic.*: continues past the user tier, so the organization's settings hooks see the engine's input and their answer stands.

prompt.section, prompt.context, skill.prompt, attribution.text: continue past the user tier, so managed CLAUDE.md, rules and policy skills reach the model as written. A person's plugins keep prompt.submit and its additive context.

settings.read: continues past the user tier, so no user hook rewrites what any caller reads as settings, this plugin's own policy reads included.

tool.describe, command.describe, agent.offer, agent.spawn: when the subject's pinned e.provider.tier is prepend or append (a policy-installed plugin, the managed folder, a policy MCP server), the event continues past the user tier. A subject provided by user, builtin or core passes.

tool.register: a caller in prepend or append continues past the user tier. A user-tier caller is refused by name while managed settings hold allowedMcpServers (set at all, empty included). Otherwise it passes.

tool.list: the tools of the organization's managed MCP servers are listed as the organization's tiers listed them, and every other tool as the user tier left it. With no policy to read, or a refusal from either listing, the organization's listing stands whole.

Everything else passes: prompt.submit, turn.*, tool.call, tool.check, command.run, command.register, session.*, ui.*, fs.*, http.fetch, process.run, store.*, clock.*, model.*, mcp.call, audio.*, agent.list and engine.create.

The only thing it calls on $ is settings.read. It continues to the append tier with next.to, which only a plugin in a managed tier may do.

This mod ships inside Claude Code and is seated by the CLI, so there is no install step. It has no configuration options: its plugin.json declares no userConfig.

To read it running from source, run the command below from the root of a clone of the repository. The README gives a caution for this: it is a plugin folder like any other, but its one move that matters, next.to, is refused outside a managed tier, so loading it with --plugin-dir seats a plugin that can only pass.

The source does not document how to enable function hooks. The author of the announcement issue (anthropics/claude-code #91870) wrote in its Sep 9, 2026 update that anyone who wants to test can start Claude Code with CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1. That is a note in an issue, not documentation, and it may change without notice.

The source lives in the mods/sec-default folder of the anthropics/claude-code repository. To fetch only that folder and the mods/types declarations it is typed against, clone the repository sparsely, enter it, and check out those two folders. The clone also brings the files at the top level of the repository.

The repository's LICENSE.md reads: "© Anthropic PBC. All rights reserved. Use is subject to Anthropic's Commercial Terms of Service." The mods README says this folder is the source of the mods, published as it is built into the binary, so that it can be read. This listing does not call it open source.

Run the command below from the root of a clone of the repository. Tests live in the mod's tests/ folder, which holds 2 test files (tests/register.test.ts and tests/policy/create-policy-memo.test.ts) and a fixtures folder as of the source read for this listing. The register tests are set to the prepend tier and include cases such as a plugin the person installed being refused a tool registration under an MCP allowlist.

Per the mods README, a test gets the engine's own $ and a plugin's on. Each call on $ is one the engine makes, through every hook of the mod loaded as it ships. The hooks a test registers with on sit beneath the mod, where the rest of the world would be, and a call they leave unanswered throws, naming its event. A test file is named for what it covers under hooks/, and the kit's mock answers the world beneath the mod from memory (mock.env, mock.store, mock.clock).

The mods README also says that tsc -p mods/tsconfig.json typechecks every mod's hooks and tests against types/ and each mod's own types contract.

The CLI seats it first in the prepend tier wherever hooks modules load, on a machine with managed settings or for a Team or Enterprise organization. If managed settings define prependPlugins, that list is the whole prepend tier, and the organization names sec-default@builtin in it at the position it wants, or leaves it out.

Three tiers matter to it: the prepend tier (the organization's, above the user tier), the user tier (plugins a person installs) and the append tier (the organization's, below the user tier). Continuing past the user tier to the append tier is the move that only a plugin in a managed tier may make.