Open question

Guardrails checked once, at the wrong moment

Anthropic's release notes for Claude Code 2.1.294 and 2.1.295 closed a set of gaps where a guardrail could be bypassed rather than enforced: hooks that were meant to block an action could let it through, tools registered after startup escaped the tool restrictions, and a site-deny rule written with port 80 missed plain http pages. A vendor changelog, with no CVE attached.

Logged 9 Oct 2026

Hooks that could fail open

Claude Code, Anthropic's command-line coding agent, runs hooks — small programs the user configures to run at set points in the agent's loop. Release notes for versions 2.1.294 and 2.1.295, both published 8 October 2026, describe a class of bug in `prompt` and `agent` hooks written as instructions: a hook told to block an action could instead allow it. The notes never say "fail closed", but that is what the change does — when something goes wrong in the check, the safe outcome is to stop rather than proceed. A separate addition, `onFailure: "block"` for command and HTTP hooks, makes the same default explicit: a hook that can't start, times out or exits with an unexpected code blocks the action instead of letting it through.

The distinction is the one that separates a lock from a sign. A guardrail that fails open is one that, when it cannot decide, lets the action continue — which is fine until the failure mode is exactly the moment it was needed.

What registered after the check

The same notes describe two more places where the check and the thing being checked fell out of step. A plugin hook — the notes call it a mod — inspecting a tool call could be handed deeply nested tool input cut short with no error, so the guard could pass content it never saw. Separately, the `--tools` and `--restricted` flags, which constrain which tools the agent may use, did not apply to built-in tools registered after startup, so a restriction set at launch could be quietly widened by a tool that arrived later.

A third item concerns Claude in Chrome, the browser integration: a site-deny rule written with an explicit port — the notes use `host:80` — was not applied to plain `http://` pages on that host, where the port is the same 80 but left implicit, so the denied site could slip past the deny list. Each is a timing or matching gap rather than a broken primitive: the guardrail existed, and it looked at the wrong instant or the wrong string.

A changelog, not an incident

These are vendor release notes, not a disclosure report. No CVE was assigned, no researcher is credited, and the notes do not describe anyone exploiting the gaps. The entry sits here because of what it says about where guardrails live: in a harness that is assembled and extended at runtime, a check is only as good as its agreement with the object it is checking, and that agreement is easy to lose as new tools and channels are added after the check was written.

Sources

Research