CONFIRMED: a failed check can stop the action
Claude Code 2.1.295 adds an option to prevent an action from continuing when the checking mechanism itself fails. Anthropic published the release on October 8 at 19:48 UTC, or 16:48 in Brasília. With onFailure: "block", command hooks and HTTP hooks, using the web communication protocol, can block an action if they cannot start, exceed their timeout or finish with an unexpected exit code. Hooks are automatic checks triggered during agent execution. The important consequence is that an unavailable safety barrier need not become silent authorization.
An unavailable rule is not an approval
There is a difference between rejecting an action and being unable to evaluate it. Imagine an agency requiring an authorization service check before its agent changes files. If that service is offline, the safer choice may be to stop work rather than assume permission. The new option makes that behavior explicit. It does not mean every hook automatically blocks failures: the announcement describes a particular configuration for command and HTTP checks, not a universal security guarantee. Teams still need to decide where this policy belongs and validate the actual behavior.
Connections must also return after an outage
The update fixes remote Model Context Protocol, or MCP, servers that stayed disconnected in headless sessions and software development kit, or SDK, integrations after outages longer than 15 seconds. MCP is a standard for connecting agents to tools and data. It also fixes repeated reconnections when a server immediately drops each connection. Those retries now become progressively more spaced out, up to 30 seconds. For businesses connecting an agent to management systems or internal databases, this could reduce manual intervention. It does not prove that every connector, credential or interrupted operation will recover.
Less invisible work in automated runs
In claude -p mode, used for noninteractive runs, each response now prints when its turn ends. That prevents earlier responses from disappearing when background work starts another turn. When diagnostic output is attached to a terminal, a notice explains why the run remains open. There is also a configurable limit on how long unattended retry mode waits through usage-limit or availability errors. The potential benefit is better visibility into failures and waiting, not measured savings. A clearer transcript helps an operator inspect what actually happened rather than infer success from a process that remains alive.
Safety moves forward in layers
This article updates our canonical coverage of Claude Code controls. Version 2.1.294 had already fixed prompt and agent hook evaluations that allowed commands they were supposed to block, and improved checks for incomplete work. Version 2.1.295 addresses a different layer: what happens when a command or HTTP check cannot finish at all. Independent catalog Core Directive records the release and analyzes changes in the shipped code. That analysis adds context, but it is not an independent effectiveness test and does not validate every installation. Correct interpretation and reliable execution remain separate concerns.
Stopping safely is also a result
For Brazilian small and medium businesses, the priority is to test the update on a bounded task: check an allowed action, a prohibited one and a situation where the authorization service is unavailable. Only then does wider autonomy make sense. Blocking a run can increase interruptions, particularly when the checking service is unstable. That is the real tradeoff. MaxAssistant’s assessment is that reliability does not mean continuing at any cost. It means stopping when authorization is missing and restoring connections without confusing a successful reconnection with a completed business task.
Sources
Anthropic: Claude Code 2.1.295; Core Directive: Claude Code 2.1.295; Anthropic: Hooks reference; Anthropic: Claude Code 2.1.294.