Claude Code Hooks Can Now Fail Closed: What It Means

If you use Claude Code with automatic safety checks, there is a change worth knowing about: a check can now be set to fail closed. That means that if the check cannot start, runs out of time or gives an answer Claude Code cannot read, Claude Code stops the action instead of letting it through. The option arrived in Claude Code 2.1.295 on 8 October 2026, and it is off unless someone turns it on.

What is a Claude Code hook, in plain words?

A hook is a small program (or a web service) that Claude Code runs automatically at set moments. For example: just before the AI runs a command on the computer, or just before it accepts your message. The hook looks at what is about to happen and can say "stop".

Teams use hooks as guardrails. A hook might refuse any command that deletes files, check that a secret is not being pasted into a file, or run a formatter after every edit.

The key point is that a hook is only useful if it actually runs. That is where this change comes in.

What changed on 8 October 2026?

Before this release, a hook that failed did not stop anything on most events. Anthropic's hooks documentation says: "On most events, when a hook fails or times out, Claude Code still carries out the action." Claude Code reported a non-blocking error, and the work carried on.

The changelog entry for version 2.1.295, dated 8 October 2026, adds a setting called onFailure for command hooks and web (HTTP) hooks. It has two values:

• continue: the action goes ahead if the hook fails. This is the default, so nothing changes for anyone who does not touch the setting.
• block: the action is stopped. The documentation says a failure then does what the hook's own "stop" signal (exit code 2) does on that event. For example, a failure on a hook that runs before a tool blocks the tool call, and a failure on a hook that runs when you send a message blocks the message. The one exception is a hook that handles permission requests: there, a failure denies the request.

That is the whole feature. It is small, but it closes a quiet gap.

What counts as a failure?

The documentation lists these cases:

• The check cannot start, for example because the script it points to does not exist.
• A command check ends with an exit code other than 0 or 2. This counts even if it printed an "allow" answer first.
• A web check cannot connect, or the response is not a success (2xx) status.
• The check reaches its time limit. The default limit for command and web hooks is 600 seconds, lowered to 30 seconds for hooks that run when you send a message, and to 10 seconds for some display events.
• The check's JSON output cannot be parsed or does not match the expected format. Plain text from a command check is not counted as a failure.

In plain terms: broken, missing, slow or confused. Each of these used to mean "carry on anyway". With the setting on, each means "stop".

Why does failing closed matter?

Think of a door lock that opens whenever its power fails. It works perfectly until the day the power goes out, and that is exactly when you needed it. Safety checks behave the same way. A check that quietly lets everything through when it breaks gives you a false sense of safety.

Here are three ordinary ways this can happen on a real project:

1. A file gets renamed. Someone tidies the project folder and the check script moves. The hook now cannot start. For weeks the AI runs commands that the hook was meant to review, and nobody notices.
2. A company server is down. A web hook asks an internal service whether an action is allowed. The service is offline on a Saturday. The hook cannot connect and the action proceeds.
3. A slow check times out. A scan that usually takes ten seconds takes far longer on a large change and hits its time limit.

In each case the team believed a rule was enforced when it was not. Fail closed makes the failure visible, because work stops until someone fixes the check.

What does it cost you?

There is a trade-off, and it is worth stating plainly. A check set to block will also block when it breaks for harmless reasons. A flaky internal server can now stop an AI engineer mid-task. For someone waiting on a deadline, that is an irritation.

So the choice is about what the check protects:

• For rules where a miss is costly, such as blocking deletion of data, or keeping secrets out of the code, failing closed is usually the right choice.
• For convenience checks, such as tidying code style, letting work continue is fine.

The documentation also notes where the setting has no effect: on hooks that run when the AI tries to stop or finish a task (including subagent stops, task completion and idle teammates), and on command hooks that run in the background. So it is not a blanket switch for every check. If your team uses those kinds of hooks for important rules, ask how they behave on failure.

What did the permission rules change on 14 October?

Another tightening arrived in version 2.1.299 on 14 October 2026. Rules that allow the AI to use a connected tool (an MCP server, which is a plug-in that gives the AI access to something like a database or a ticket system) now reach only the server they name. The changelog says a rule written for a server called a no longer allows a server named a__b or a_. To cover every tool on a server, the rule must use the server's whole name followed by a wildcard.

In practice: a rule that was a little too loose before may now allow less than it used to. If the AI suddenly asks permission for a connected tool it used freely last week, this is a likely reason. It is worth a quick look if your team writes its own rules. The same release also fixed a bug where deny and ask rules for a server did not apply when its name contained a double underscore.

What should a team do about it?

You do not need to write code to act on this. Put these questions to whoever sets up your AI tooling:

1. Do we use hooks at all? If not, this change does not affect you.
2. Which of them guard something important? List them: secrets, deletion, production access, payments.
3. What happens today if one of them fails? For most setups the answer is "the AI carries on", because that is the default.
4. Should those be set to block? For the important ones, usually yes.
5. Who gets told when a check breaks? A blocked action is only useful if someone sees it and fixes the check promptly.

Also check that the team is on Claude Code 2.1.295 or later, since the setting does not exist in earlier versions.

For a developer, the change is small. Anthropic's own example adds one line, "onFailure": "block", to a hook that screens shell commands, so that a missing script stops the command rather than letting it run.

How does Atlas relate to this?

Atlas is a team of AI engineers built on Claude Code, and it enforces its own rules in a separate way. Completion of a task is refused until the work is on main or queued for the landing train, a screen has its test cases and screenshots, and the product's rules pass. Those checks belong to Atlas itself. Atlas does not today let you set up or manage Claude Code hooks, or choose how they behave on failure, so this particular setting is something your own team would configure. You can read more on the Atlas home page at /atlas/.

Conclusion

This release does not add a new kind of check. It changes an old assumption: that a safety check which cannot run is harmless to skip. With onFailure set to block, a broken guardrail stops the work instead of disappearing silently. If your team has any automatic check that protects something you care about, find out whether it fails open or closed, and decide on purpose.