Follow Discord
Sweep 03 Nov 2026 · 22:27Z Build v2.1.318 536 read Stable v2.1.311 Latest v2.1.318 Next v2.1.318 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.317 ·

SDK hook callbacks can block an action when they fail, using onFailure

SDK hook callbacks can set onFailure to block so a failed check stops the action, and the SDK refuses to start if Claude Code cannot honour it

Group of 6 Use it now Notable New Features
JSON All of v2.1.317
Use it nowTier: how much it should matter to you
5Useful: my rating, 1 to 5
2Signal: worth watching, 1 to 5
HooksArea: what it touches
New FeaturesKind: in v2.1.317,
What probably matters to youSection of the release

What

Hooks are actions you set up to run automatically at set points while Claude Code works. Programs built on the Claude Agent SDK (the toolkit for running Claude Code from your own code) can register hook callbacks: functions in their own program that Claude Code calls. A hook matcher, the rule that decides which events a callback handles, now accepts an onFailure setting. It says what happens when the callback itself fails:

  • onFailure: "continue" is the default: a failed callback is ignored and the action goes ahead.
  • onFailure: "block" makes a failed callback count as a block, so the action does not run.
  • Any other value logs a warning and is treated as "block". The value is passed to each callback.
  • The setting is ignored on the Stop, SubagentStop, TaskCompleted and TeammateIdle events.
  • callback hooks are now checked for this the same way as http hooks. Before, only command and http hook types were handled, and other types never blocked.
  • createHookCallback takes the onFailure value and sends it on as hookOnFailure. In block mode, a failed callback, or an answer that names a different hook event ('The answer names another hook event'), now raises an error, and waiting callbacks can be rejected. Before, failures were logged and swallowed, and the action carried on.

The SDK and Claude Code also check that they agree on this before any work starts:

  • Claude Code's reply to the opening initialize request now includes hook_on_failure_supported, which is true when that version honours onFailure. Older versions ignored the setting, so a failing callback set to block still let the action run.
  • The SDK sends each matcher's onFailure in the initialize request. If any hook uses a value other than "continue", your first prompt is held until initialize succeeds. The SDK stops with an error if Claude Code does not report hook_on_failure_supported, or if hooks_applied is false on a session that is already running. If initialize is never answered, a timeout cleans up the query and the prompt is not sent.
  • Over a remote connection, when a pending hook callback is set to block, an error reply coming from a different client is ignored, and Claude Code keeps waiting for the program that registered the hook. A matching log line records this.

Why

If you use SDK hooks as safety checks, you can now make them fail closed: a crashed or broken check stops the action instead of silently letting it through. The SDK refuses to send your prompt to a Claude Code version that cannot honour the setting, rather than running without the protection you asked for.

Read from
Names in the bundleonFailure

See this entry in the whole of v2.1.317 →

Feedback