You schedule an agent to inspect a repository every morning. Before it edits a file, a hook checks your policy service. One day that service stops responding. If the callback fails and the edit still runs, the guard only worked when everything else worked. Anthropic released Claude Agent SDK for TypeScript 0.3.317 on November 3, 2026 with a concrete choice for this failure mode: onFailure: "block" on a hook matcher.
What 0.3.317 changes
The official release notes say that, with this setting, an action is blocked if a hook callback throws or returns invalid output. The release also emits a warning in the message stream when a callback fails. Claude Code 2.1.317, released the same day, notes the corresponding Agent SDK callback behavior. This matters to builders of agents that edit files, call tools, or run unattended jobs. It does not mean Claude can infer your organization's security policy on its own.
Keep two cases separate. A callback may deliberately deny an action because policy says no. Or the callback may fail technically due to an exception, a timeout, or malformed output. The new setting makes that second case block the action when you choose it. It does not silently change every existing hook, replace tool permissions, or make a sandbox unnecessary.

Apply it to a coding agent
Start by checking the installed package and upgrading on a test branch. Anthropic's release notes give this command:
npm install @anthropic-ai/claude-agent-sdk@0.3.317
Find the PreToolUse hooks that protect meaningful actions. The Agent SDK documentation explains that this event runs before a tool call and can allow, modify, or deny the operation. In a TypeScript matcher, put the failure policy next to the callback:
hooks: {
PreToolUse: [{
matcher: "Write|Edit",
hooks: [checkWritePolicy],
onFailure: "block"
}]
}
This fragment shows where the option belongs, not a complete runnable agent: checkWritePolicy must be a real callback and your application must pass the options to query(). The callback still needs an explicit denial result for forbidden paths or files. If its policy lookup crashes, the new setting prevents the matching Write or Edit call from proceeding silently.
Before enabling a production schedule, run a controlled test against a disposable file in a test repository. Make the callback throw, then check that the file was not changed. Repeat with invalid callback output and with a valid allow decision. Inspect the warning in the stream so an outage is distinguishable from an ordinary policy denial. This is a recommended test; we did not execute a live Claude Agent SDK session using Joseph's credentials.
Two boundaries to keep in mind
The Write|Edit matcher only covers those named tools. Anthropic's documentation notes that writing through Bash does not trigger that matcher; use Bash-specific guards, permissions, or sandboxing as appropriate. Also, failing closed can pause legitimate work when the policy service is down. Make the failure visible and recoverable: an operator should know which callback broke and be able to retry after fixing it, without switching off the guard.
For an agent that can touch customer data, deployments, or sensitive files, I would enable onFailure: "block" on hooks that are genuine boundaries and rehearse a policy outage before the next scheduled run. For telemetry-only hooks, decide separately whether an outage should stop work. The useful change here is the explicit choice of what happens when the control itself fails.
