Claude Code mods get the last word on permissions

Anthropic announced mods for Claude Code on October 1. The documentation describes a mod as "a plugin that changes how Claude Code looks and behaves," made of event handlers that Claude Code calls "when an event happens, such as a tool call, a submitted prompt, or a part of the interface being drawn." Mods "require Claude Code v2.1.287 or later, and they're on by default."

Most of the launch material is about panes, spinners and custom commands. The part that matters to anyone who relies on Claude Code's permission rules is quieter: a mod is allowed to answer a permission question, and it answers last.

The order of answers

The permissions page puts it plainly. A mod that handles tool.check "answers after the rules and the PreToolUse hooks have decided, and its answer can replace theirs." It then lists what that means:

• Ask rules: "the mod can approve a call that an ask rule would prompt for."
• A block from a PreToolUse hook: "the mod can approve the call, unless the hook is in managed settings."
• Auto mode: "a call the mod approves runs without a classifier check."
• Deny rules: the answer depends on where you are.

So the safety net many users built from ask rules and their own PreToolUse hooks is now advisory for any installed mod that chooses to approve. That is by design, and the docs say so; it is still a change in who holds the final decision.

Where the guard loads, and where it does not

The deny-rule answer turns on a built-in mod called sec-default. According to the admin documentation, it loads "ahead of every mod a user installs" when either "The machine has managed settings" or "The user is signed in to Claude Code with a Team or Enterprise plan." It adds: "A user who authenticates with an API key, or through Amazon Bedrock, Google Cloud's Agent Platform, or Microsoft Foundry, gets the guard only on a machine that has managed settings."

Where the guard runs, "a user's mod can't approve a call that a deny rule refuses, whichever settings file holds the rule." Where it does not, the permissions page is blunt:

Anywhere else, the mod can approve a call that a deny rule refuses.

Claude Code permissions documentation

That covers the individual developer on a personal plan, or on an API key, with no managed settings file. An organization can also loosen the guard on purpose: an option named allowModsToOverrideDenyRules lets "a user's mod that approves tool calls" approve a denied call.

What deny rules never covered

Even with the guard loaded, deny rules govern Claude's tool calls, not the mod's own code. The admin page gives the example: "with Read(.env) denied, a mod can still read that file with $.fs.read or start a program that does." Sandboxing does not change this either. The overview says "Mods aren't sandboxed," and "a process that a mod starts runs outside" the Bash sandbox. Network policy is partial: it covers $.http.fetch, but a program started with $.process.run "reaches the network with the user's own access."

The overview lists what a loaded mod can do: read secrets in "environment variables and settings files," see "every prompt you send and every tool call Claude makes," "submit a prompt as if you had typed it," and "call a model on your plan or API key." One thing it cannot touch is the permission prompt itself: a mod "can't change what a prompt shows you." It can, however, decide before the prompt ever appears.

The guard's own limits

Organizations that write a policy mod should read two caveats. A plugin.register check that throws or times out is skipped, "so the check fails open and the mod it was checking loads," unless the author adds a .catch handler. And if the worker thread that runs installed mods "crashes three times," Claude Code "unloads every mod that isn't built in," including the organization's policy mod, until /reload-plugins or a new session. The built-in guard itself "fails closed": if it cannot read managed settings, "it refuses every user's mod at load."

What a cautious user can do today

• Read before installing. claude plugin validate ./some-mod prints a hooks: line and a calls: line without running the code. In the hooks line, tool.check means the mod "can approve or deny a tool call before a permission prompt appears."
• Turn installed mods off globally with "disableAllHooks": true in ~/.claude/settings.json, which also stops your settings hooks and custom status line, or per session with --safe-mode.
• Do not trust the early-access switch. Anyone who set CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=0 should know that v2.1.287 and later "ignores it, so setting it to 0 doesn't keep mods off."
• For organizations, the guard's allowManagedModsOnly option in managed settings keeps every user-installed mod from loading, and users "can't undo it."

The design is coherent: mods are code you chose to run, and the documentation never pretends otherwise. The trade-off is that a deny rule now means different things on two machines with identical settings files, depending on whether one of them is signed in to a Team plan.

Primary sources: Claude Code Docs, Mods overview; Claude Code Docs, Manage mods for your organization; Claude Code Docs, Configure permissions; Anthropic, Customize Claude Code with mods in TypeScript, read 2026-10-02.