Claude Code 2.1.214: The Great Permission Lockdown

Claude Code 2.1.214 shipped today. This is a hardening release: about a dozen fixes touch the permission engine directly. Here is what actually matters.

Your Edit(src/**) rule wasn’t protecting what you thought

Before this release, a single-segment allow rule like Edit(src/**), or a hook if: dir/** condition, matched dir/ anywhere in the tree, not just <cwd>/dir. In practice, a rule meant to apply only to the src/ folder at your project root could also authorize writes to a nested src/ three directories down, without you ever intending that.

That’s fixed now: dir/** matches only <cwd>/dir. If you actually want any-depth matching, you now have to write **/dir/** explicitly.

One nuance to keep in mind: this scope change applies to allow rules and hook if: conditions. deny/ask rules keep matching at any depth, on purpose, staying on the cautious side.

If you have a permissions.json or hooks with single-segment patterns, go reread them. This is the kind of hole you only spot in hindsight.

A wave of fixes to the permission engine itself

This release closes several doors that let commands through without a prompt when they should have triggered one:

• A permission bypass specifically affected commands run in Windows PowerShell 5.1 sessions.
• File-descriptor redirect forms that bash parses differently from the permission analyzer used to slip through unchecked. Behavior is now fail closed: when in doubt, it prompts.
• Commands longer than 10,000 characters used to skip automatic analysis. They now always prompt.
• zsh variable subscripts and modifiers inside [[ ]] comparisons were treated as inert text and ignored. They now require approval.
• Certain help and man commands could be auto-approved even while carrying unsafe options, command substitutions, or backslash paths.
• On remote sessions, the local confirmation prompt could in some cases be raced by execution.

None of these is dramatic on its own. Stacked together, they add up to a real hardening pass on the permission engine. If you run Claude Code unattended, in CI, background agents, or remote sessions, this release alone is worth the update.

Docker and file now require permission

Two commands that used to slip through without a prompt now need one:

• docker commands (including the Podman docker shim) carrying a daemon-redirect flag (--url, --connection, --identity, Podman’s remote mode) now trigger a permission request.
• file commands using -m/--magic-file or -f/--files-from are no longer auto-approved as plain reads.

If your scripts or hooks call these commands unattended, expect a prompt where there wasn’t one before.

EndConversation: Claude can now cut a session short

New tool: Claude can end a session with a highly abusive user or a jailbreak attempt, on the same principle as what has existed on claude.ai since 2025. No impact on normal use, but worth knowing if you build integrations exposed to external users.

Background sessions: several leaks plugged

If you use /background or the agent view, a handful of concrete bugs are fixed: parked background sessions that kept the daemon and a worker process alive indefinitely, completed sessions that couldn’t be removed via claude rm once the background service went idle, and sessions launched from a non-git folder that couldn’t be deleted from the agent view.

Everything else, usefully condensed

• A periodic heartbeat now shows up during long tool calls that used to go silent.
• Hooks returning exit code 2 were supposed to block execution as documented, except when their stdout JSON failed schema validation: fixed.
• Regression fixed: plugins enabled via the --settings CLI flag stopped loading, a bug present since 2.1.181.
• /ultrareview used to refuse to run in repos with no merge base; it now offers to review everything.
• claude update and claude doctor could hang silently when a shell-config path turns out to be a directory.
• Scheduled tasks (routines) used to treat their own configured prompt as untrusted input; it is now delivered as the session’s assigned task.

Should you update

Yes, without hesitation, especially if you use permission rules or hooks with dir/** patterns, run unattended (CI, remote sessions, automation), or have pipelines calling docker or file. The sheer number of security fixes in this release justifies it on its own.

For everything else, remember the dir/** scope change: it’s the one that can silently change what your existing rules actually allow.

Source: official Claude Code changelog.