Claude Code 2.1.295: hooks finally get a real blocking mode

2.1.295 adds an explicit blocking mode to command and HTTP hooks, fixes a guard hook that could see a truncated input, and changes what Ctrl+C does during a background /loop wakeup.

claude-code changelog permissions digest-dossier

Claude Code 2.1.295, released on October 8, 2026, packs 143 entries across additions, changes, improvements and fixes, most of them aimed at Claude apps gateway admins, mod and plugin authors, or Claude Tag in Slack. Three things affect your day-to-day use: hooks finally get an explicit way to block an action when they fail, a keyboard reflex changes during an attached background session with a pending /loop wakeup, and two invisible caps, one on subagents and one on MCP tool search, shift quietly.

Hooks tighten up, on both the settings side and the mods side

The hooks docs are blunt about it: by default, a failing command or http hook blocks nothing. A timeout "doesn't block the tool call. The call continues through the normal permission flow, so don't count on a stalled hook to act as a gate." And without valid JSON on stdout, "Claude Code treats exit code 1 as a non-blocking error and proceeds with the action, even though 1 is the conventional Unix failure code." A hook meant to enforce policy already had to exit with code 2 to block anything, but a hook that failed to run at all, a missing script, a timed-out call, let the action through without a word.

2.1.295 adds onFailure: "block" for command and HTTP hooks: a hook that can't start, times out, or exits with an unexpected code now blocks the action instead of letting it slide. If you rely on a hook to enforce a rule that has to hold, this is the setting to flip: the default itself stays permissive.

Same release, same family of problem on the mods side. A mod can guard a tool call and "handle the event itself, so the usual behavior doesn't run, such as refusing a command," reading the call's input to decide. 2.1.295 fixes a bug where that input, when deeply nested, got silently cut short before reaching the hook: a guard could judge a tool call it had never fully seen, and let through exactly what a complete read would have blocked. It also closes a second gap of the same kind: calls a mod made while reloading during a plugin hooks worker restart got past another mod's guard hook, even one with a .catch handler. Those calls are now refused.

Ctrl+C no longer does the same thing during a background /loop

Ctrl+C's default behavior is simple: nothing running, first press clears the prompt, second press exits Claude Code. In an attached background session, keys already behave differently: the left arrow detaches and takes you back to agent view without interrupting what's running, and pressing Ctrl+C twice on an empty prompt also detaches instead of exiting.

2.1.295 settles the /loop case: if a wakeup is pending in an attached background session, Ctrl+C at the idle prompt now leaves it alone, so pressing it twice detaches and the loop keeps running. To stop the /loop itself, press Esc. The "Ctrl+C, Ctrl+C" reflex no longer touches the loop here, and only here.

Two caps shifting under the hood

A subagent can preload skills through the skills field in its frontmatter: "The full content of each listed skill is injected into the subagent's context at startup." The field doesn't limit access: without it, "the subagent can still discover and invoke project, user, and plugin skills through the Skill tool during execution." 2.1.295 caps that preloading at 32 skills per subagent, each loaded once. Past that, the remaining skills don't vanish: a subagent with the Skill tool can still call them on demand, it just no longer gets their content injected at startup.

Second cap, on the MCP side. Tool search is the default setting that avoids loading every MCP tool definition at once. 2.1.295 raises the description length it keeps per tool during that search, from 2,048 to 16,384 characters. A tool whose description used to get cut off at the old threshold now has eight times the room.

Everything else, in brief

  • Grep and its flags: a search sent with -l, -c or -r used to fail outright; it now runs normally.
  • Broken plugin settings: claude plugin install, enable, disable and marketplace add now warn when the settings file they write to doesn't load.
  • VS Code: files Claude sends you in chat get their own row, clickable to open the file in the editor.
  • Bash permissions: permission checks on for-loops over glob patterns are more accurate.
  • Everything else in this release, which is most of it, touches the Claude apps gateway on Bedrock, Vertex and Foundry, mod and plugin development, Claude Tag in Slack, and a long tail of display and terminal reliability fixes.

The takeaway

What the first two changes share is that neither one changes the default behavior: a failing hook stays permissive unless you turn on onFailure: "block" yourself, and the truncated-guard bug only hit one specific case of deeply nested input, not every call. If you lean on hooks to enforce a security rule, this release is worth updating for, but the box still needs to be checked explicitly. The Ctrl+C change only touches a narrow case, an attached background session with a pending /loop, but that's exactly the kind of detail you find out about by hitting the key at the wrong moment. Finally, if you write subagents with more than 32 preloaded skills, the extra ones are no longer injected at startup and go through the Skill tool instead; if you run an MCP server with long tool descriptions, the new cap works in your favor.

Pierre Rondeau

Pierre Rondeau

Developer and indie builder. I build products and automations with AI. Creator of Claude Hub.

LinkedIn