Claude Code 2.1.295 Adds onFailure Block for Hooks, and 2.1.294 and 2.1.296 Fix Cases Where Guard Hooks Let Actions Through

Overview

Three consecutive Claude Code releases published between October 8 and October 9, 2026 change how the coding agent’s hooks enforce policy. Version 2.1.295 adds an onFailure: "block" setting for command and HTTP hooks, according to the v2.1.295 release notes, while 2.1.294 and 2.1.296 fix separate cases in which hooks written to block an action did not do so. Hooks are the mechanism teams use to run their own checks before or after Claude Code acts, and the new setting addresses what happens when such a check itself breaks.

What We Know

Fail-closed option in 2.1.295

The v2.1.295 release, published October 8, 2026 (19:48 UTC per the GitHub release timestamp), lists this change: “Added onFailure: \"block\" for command and HTTP hooks: a hook that can’t start, times out, or exits with an unexpected code blocks the action instead of letting it through”.

The hooks documentation describes the default behavior it changes: “On most events, when a hook fails or times out, Claude Code still carries out the action, so a policy hook with a wrong path or a crashing script lets everything through.” The same page says the default value of the field is "continue" and that the setting requires Claude Code v2.1.295 or later, so existing hooks keep their current behavior unless a team opts in.

The documentation lists five conditions that count as a failure: a command hook that cannot start, an exit code other than 0 or 2, an HTTP error, a timeout, and invalid output. With "block" set, it says a failure does what exit code 2 does on that event, except on PermissionRequest, where it denies the request. Its examples are that a PreToolUse failure blocks the tool call and a UserPromptSubmit failure blocks the prompt.

The documentation also states the limits. The field has no effect on Stop, SubagentStop, TaskCompleted and TeammateIdle hooks, where exit code 2 sends Claude back to keep working, nor on background command hooks that set async or asyncRewake, per the hooks documentation.

Instruction-written hooks in 2.1.294

The v2.1.294 release, published October 8, 2026 (05:03 UTC), contains two entries. One reads: “Fixed prompt and agent hooks written as instructions (such as “Block commands that…”) allowing what they should block”. The other changes how prompt hooks on Stop and SubagentStop written as instructions are judged, so that Claude is “less likely to stop early”, per the same release notes.

According to the hooks documentation, a prompt hook sends a prompt to a Claude model for single-turn evaluation and the model returns its decision as JSON, while an agent hook spawns a subagent that can use tools such as Read, Grep and Glob before returning a decision, and is described as experimental.

Managed-settings and mod fixes in 2.1.296 and 2.1.295

The v2.1.296 release, published October 9, 2026 (19:28 UTC), says it fixed “managed-settings PreToolUse hooks that deny a tool call with \"continue\": false, and managed prompt hooks that block one, refusing the call but not ending the turn”. The same release lists a fix for Esc or an interrupt during a UserPromptSubmit hook or a mod’s prompt.submit hook “letting the unchecked prompt through”, among other outcomes the notes name.

The v2.1.295 notes also include a fix for “a mod’s hook being handed a deeply nested tool input cut short with no error, so a guard could pass content it never saw”, according to the release notes. Mods, which Anthropic introduced on October 1, can block tool calls, as previously reported.

What We Don’t Know

• The release notes do not say how many users or organizations were affected by the hook bugs, or whether any of them were exploited. They describe the fixes in a single line each.
• The notes do not say whether Anthropic plans to make "block" the default for any hook type. The documentation currently states the default as "continue".
• The release notes do not specify which versions first contained the instruction-hook and managed-settings behaviors that 2.1.294 and 2.1.296 fix.

Analysis

Taken together, the entries show a pattern in which a guard that fails quietly is treated as a defect. Under the documented default, a policy hook with a wrong path lets the action proceed, which is why the documentation frames onFailure as an explicit opt-in. Teams that rely on hooks for enforcement would need to set the field on each command or HTTP hook to get fail-closed behavior, and the documentation’s own test is to leave the script missing and confirm that Claude Code refuses the call. All claims above rest on Anthropic’s release notes and documentation; no independent reporting or testing was reviewed for this article.