Claude Code 2.1.299 to 2.1.301 changes hook behavior: seven things to recheck

Three releases, seven behavioral changes

Three Claude Code releases — 2.1.299, 2.1.300 and 2.1.301 — landed on October 14 and 15, 2026, and according to a dev.to write-up by Gabriel Anhaia, seven entries in their changelog's "Changed" sections affect hooks that are already installed. Nothing in a hooks file needs to be edited for the new behavior to apply; it starts the moment the CLI is updated. The post's first suggestion is to run claude --version to see whether any of this applies yet.

Prompt hooks now run before skills expand

From 2.1.299, UserPromptSubmit hooks execute before a skill or custom slash command expands. Skill bodies can embed shell commands, and a hook that blocks the prompt now also prevents those embedded commands from running, where previously it did not. A second consequence: a hook that searches the prompt for text that only appears in a skill's expanded body will no longer match, because the expansion happens after the hook. Claude Code offers a separate UserPromptExpansion event, matched on the command's name, for logic that needs to see expansions.

A skill's own hook skips the invoking prompt

Also in 2.1.299, hooks declared in a skill's frontmatter register when the skill is invoked and keep running for the session — and the skill's UserPromptSubmit hook now fires for the first time on the prompt after the one that invoked the skill. A hook written to inspect its own invocation, such as a /deploy prod call, no longer sees that prompt. The recommended move is to relocate such checks to UserPromptExpansion in settings, for example a matcher on the deploy command that blocks it unless an approval file is present.

Rewritten tool input is now validated

From 2.1.300, the updatedInput object returned by PreToolUse and PermissionRequest hooks is validated the same way Claude validates its own input: unknown keys are stripped out, and input the tool rejects causes the call to be denied. Because updatedInput replaces the entire input object rather than patching it, a hook that returns only the field it changed — or misspells a field name — will now produce rejected calls. The safe pattern, the post notes, is to start from the input Claude sent and modify a single field, keeping every required key intact.

Cowork cloud sessions ignore setMode

From 2.1.300, in Cowork cloud sessions a setMode entry inside a PermissionRequest hook's allow response is ignored, while the rest of the approval still applies. A hook that approved an edit and switched the session into acceptEdits will keep receiving permission requests, since the mode never actually changes. A related change in 2.1.299 goes further for auto mode in cloud sessions: PermissionRequest hooks there can no longer approve shell commands or subagents at all, and those prompts either wait or are denied. Neither changelog line, the post points out, covers local terminal sessions.

Agent tool lists narrowed to named servers

From 2.1.299, an agent's tools: list picks up only the tools of the MCP server it explicitly names. Previously an entry like mcp__a could also reach servers such as a__b or a_ through a shared-prefix overlap — the same leak flagged for allow rules in that release. Agents that silently gained a second server's tools through such a prefix lose them, and servers whose names contain a double underscore must be listed with the full name and a wildcard.

What the post leaves out

The write-up covers two further items — among them how a plugin hook behaves when it cannot answer — and closes with three fixes, one of which dates back to 2.1.294. Two hook changes from the same week are deliberately excluded for space: the onFailure "block" option from 2.1.295 and the narrower MCP allow rules from 2.1.299.

Why it matters

Hooks are the guardrail layer of Claude Code: they block unsafe prompts, rewrite tool input and automate permissions. When the runtime redefines hook semantics without touching configuration, reviewed setups can change behavior overnight — blocking hooks start suppressing skill shell commands, partial input rewrites start denying calls, and permission automation in cloud sessions quietly stops doing half its job. Teams that depend on hooks should check which version they run, search their settings and hook scripts for UserPromptSubmit, updatedInput and setMode, and re-test their critical paths after updating.