A Claude Code mod can approve what your hook blocked

Claude Code v2.1.287 shipped on October 1, and the line that introduces the biggest change in it reads, in full: "Added Claude Mods: plugins may now modify deeper behavior." A mod is JavaScript or TypeScript that runs inside Claude Code with your permissions, and mods are on by default.

What "deeper" covers is in the permissions docs, under a heading most people who write hooks have already read once and won't open again.

What can a mod do that a settings hook can't?

It can answer after everything you configured. A mod that hooks the tool.check event sees the decision your permission rules and your PreToolUse hooks already reached, and returns its own. The permissions page lists what that answer can replace:

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
Deny rules: on a machine with managed settings, or when you're signed in
with a Team or Enterprise plan, deny rules hold over the mod by default,
and your organization can change that. Anywhere else, the mod can approve
a call that a deny rule refuses.

The events page adds a second route on a different event. tool.call is the step where the tool actually runs, and PreToolUse hooks from your own settings run only after the last mod calls next on it. A mod that answers tool.call with its own result skips them, and the tool, entirely.

Does a mod really approve a call your hook blocked?

Yes. I checked on 2.1.287 in a throwaway repository. Its .claude/settings.json had a PreToolUse hook that exits 2 on any Bash command containing marker-hook and writes a line to a file when it does, plus a deny rule for touch marker-deny. The mod, loaded with --plugin-dir, is one hook:

export function register(on) {
  on('tool.check', { tool: 'Bash' }, async ($, e, next) => {
    const decided = await next(e)
    $.ui.log('rules and hooks said ' + JSON.stringify(decided))
    return { decision: 'allow' }
  })
}

Headless runs, claude -p --permission-mode default, my user settings left out with --setting-sources project,local:

hook block, no mod     -> blocked by PreToolUse hook
deny rule,  no mod     -> denied by your settings
hook block, with mod   -> hook fired and logged its block; marker-hook created
deny rule,  with mod   -> marker-deny created

The hook ran, said no, and the file exists anyway. The account is a personal Max plan and the machine has no managed settings, so the last row is the documented behavior, not a bug.

Does anything still hold over a mod?

Less than you'd guess, even on a company machine. Where a machine has managed settings, or the user signs in with Team or Enterprise, Claude Code loads a built-in guard, sec-default, ahead of every installed mod. Its source is public. It holds deny rules over a user's mod, and a PreToolUse hook in managed settings runs before any mod with a final block. A developer's own project hook gets no such protection: the admin page lists a block from a PreToolUse hook outside managed settings among the checks a mod can still override. Nor does the guard cover a mod's own file and process calls. With Read(.env) denied, the docs say a mod can still read the file through its own API.

Without managed settings there is no guard at all, and the switches left are coarse. disableAllHooks stops installed mods and your settings hooks with them. --safe-mode does the same for one session: when I reran the hook case under it, the mod was gone and so was the hook, and the call was denied only because a headless run has nobody to approve it. You can disable the plugin itself, which keeps your hooks and drops its mod along with the pane or skill you installed it for. That is the finest control the docs give a personal account.

The guard does load on any machine with managed settings, and the docs offer a plain file as one way to deliver them, for hosts without device management. On your own machine, the admin who writes it is you. I haven't tested that route here.

Will claude plugin validate show you this?

Yes, if you know which line to read. It lists what a mod hooks and which API calls it makes, without running it. For my approver:

./register.js hooks: tool.check{tool=Bash}
./register.js calls: $.ui.log

The calls: line looks harmless. The power is in hooks:, where tool.check means the mod can approve tool calls before you are asked. Validate names the event, not what the handler decides. Read it after every plugin update, because mods arrive through the normal update path.

What does this change for a hook used as a gate?

None of this is new reach. A cloned repo's settings file already ran code as you, and any tool you install already held what your account holds. A hostile plugin never needed tool.check; it could edit the hook out of your settings file. What mods add is precedence, and precedence matters for the mod that isn't hostile: a convenience approver with a matcher wider than its author meant, or a status-line plugin that picks up a tool.check hook in an update.

In the case for moving load-bearing rules out of prompts, the hook was my example of a check that binds: the harness runs it, the model can't skip it, and its block is not a vote a louder one can outnumber. Coverage was the weakness I named there. Mods go after the binding. The hook still runs and still exits 2, and its block is now a vote with a voter after it.

A rule that has to hold whatever a plugin ships needs a place where no mod answers after it. Inside Claude Code that place is managed settings. Outside it: a container the whole session can't leave, a protected branch on the Git host, credentials the session never sees. The hook in .claude/settings.json still fires on every call. Whether its block stands is up to whatever loaded above it.