Claude Code 2.1.214 changed permission behavior across shells and rules

Does Edit(src/**) mean the same thing in allow, deny/ask, and hook if: contexts? In Claude Code 2.1.214, the answer is no. Anthropic says a single-segment dir/** allow rule and the same pattern in a hook if: condition now refer to <cwd>/dir, while deny and ask rules keep any-depth matching.

That distinction matters to engineering managers and platform teams because identical text can produce a different approval decision depending on the client version and the surface that evaluates it. Release 2.1.214, published July 18, 2026, also changed permission analysis for Bash, zsh syntax handled through the Bash tool, Windows PowerShell 5.1, remote sessions, and Docker or Podman daemon flags. This explainer follows one rule from precedence through parsing, then gives a bounded way to decide whether the current patch line matches a team’s written policy.

Deny and ask take precedence before an allow rule can apply

Claude Code’s current permissions documentation defines three outcomes. Allow rules let a specified tool use run without manual approval, ask rules require confirmation, and deny rules block the tool use. Claude Code evaluates matching rules in the order deny, ask, then allow; a more specific allow rule does not override a broader deny or ask rule.

Precedence answers which matching rule wins. A parser answers whether a rule matches in the first place. File tools, shell commands, and hook conditions do not all present the same input: a file rule receives a path, a shell rule is evaluated against command grammar, and a hook if: condition combines a tool name with its arguments using permission-rule syntax.

Reviewing the string stored in settings is therefore insufficient. The practical decision is the combination of rule surface, parsed input, working directory, client version, and any higher-precedence match. Written instructions can guide what a coding agent attempts; the permission engine decides what the client runs, asks about, or blocks. Our runtime-enforcement explainer covers that broader separation.

Edit(src/**) now anchors allow rules at the current working directory

Before 2.1.214, Anthropic says a single-segment allow rule such as Edit(src/**) could auto-approve writes to nested src/ directories anywhere in the tree. A session started at the repository root could therefore treat both <cwd>/src/app.ts and <cwd>/packages/api/src/app.ts as allowed by the same expression. The release changes that allow-rule behavior so Edit(src/**) anchors to <cwd>/src.

Consider a repository with these files:

<cwd>/src/app.ts
<cwd>/packages/api/src/app.ts

Under the 2.1.214 allow semantics, Edit(src/**) can match the first path without manual approval. It no longer supplies an allow match for the second path merely because another src/ directory appears deeper in the tree. Another matching ask or deny rule can still determine the outcome because those rule classes run first.

The same text remains broader in deny and ask rules. Anthropic’s release note explicitly says those rules keep any-depth matching, so a deny rule written as Edit(src/**) can continue to block a matching nested src/ path. An ask rule with that expression can continue to require approval there. This asymmetry favors broader blocking and prompting while narrowing where the client may auto-approve an edit.

Hook if: conditions use permission-rule syntax, according to the current hooks documentation, but 2.1.214 gives the single-segment path form the anchored meaning there too. Edit(src/**) in a hook handler’s if: condition now refers to <cwd>/src; Anthropic directs hook authors to write **/src/** when the hook should match src/ at any depth. A hook match does not itself describe an allow, ask, or deny outcome, so teams should review the condition and the hook’s action together.

Shell permission results depend on the shell grammar the analyzer recognizes

Claude Code analyzes shell structure before it evaluates a shell rule. The documentation says the client recognizes compound-command separators and checks subcommands independently. PowerShell rules also use PowerShell’s parsed command structure, including pipelines and statement separators, while common aliases are canonicalized before matching.

Release 2.1.214 addresses cases where shell grammar and permission analysis did not agree. For Bash, file-descriptor redirect forms that Bash parsed differently from the permission analyzer now fail closed. Here, fail closed means the client asks for approval instead of relying on an automatic decision when its analysis cannot safely establish the allowed form.

The release also makes commands longer than 10,000 characters prompt instead of running automatically. zsh variable subscripts and modifiers inside [[ ]] comparisons now prompt when they reach the Bash permission checks, and some help and man forms now prompt when they can carry unsafe options, command substitutions, or backslash paths. These are separate grammar cases with the same operational result: an existing broad allow pattern may now lead to a confirmation dialog.

Anthropic separately states that 2.1.214 fixes a permission-check bypass affecting commands run in Windows PowerShell 5.1 sessions. The release does not disclose the command syntax, prerequisites, affected-version range, or severity. Teams that support PowerShell 5.1 can verify that the managed client is on the patched line, but the public note does not provide enough detail to reproduce that specific case or claim full coverage of PowerShell permission analysis.

Remote confirmation and daemon-selection flags now reach a prompt

Anthropic says 2.1.214 fixed “permission prompts on remote sessions that could proceed before the local confirmation dialog.” The note does not say that the remote session itself proceeded, and it does not describe timing windows, transport details, or affected remote-session versions. For a managed workflow, verify that any action requiring local approval waits for that decision before the remote side proceeds.

Docker commands now prompt when they carry daemon-redirection flags named by Anthropic: --url, --connection, --identity, and Podman remote mode. The behavior also covers Podman’s docker compatibility shim. A rule that auto-approves ordinary local Docker commands should therefore be expected to stop at a prompt when one of these forms changes the daemon or connection context.

These fixes concern different inputs, but they share one policy consequence. The analyzer considers execution context as well as the apparent command name. docker is not enough information for an automatic decision when the invocation can select another daemon, and a remote-session approval is not complete while the local confirmation is still pending.

The public evidence covers stated changes, with material gaps

The 2.1.214 release note establishes the behaviors Anthropic says it changed. The permission documentation, accessed July 20, establishes rule outcomes, deny-ask-allow precedence, current path examples, and shell-specific matching behavior. The hooks documentation accessed the same day establishes that handler if: conditions use permission-rule syntax.

Those sources do not provide a full affected-version range, implementation diff, test corpus, exploit prerequisites, severity assessment, customer-impact statement, or CVE. They also do not establish that every permission-analysis edge case has been found or corrected. The Windows PowerShell 5.1 item is especially limited because Anthropic discloses no reproducing syntax.

Claude Code 2.1.215 followed on July 19. Its sole release-note item says Claude no longer runs the /verify and /code-review skills on its own and that users should invoke those skills when wanted. The note does not mention the permission changes in 2.1.214. Whether the 2.1.215 build carries those changes needs publisher verification rather than inference from the release note.

Decide against explicit outcomes on the exact managed patch line

Use one disposable repository to check the client version your team plans to manage, such as 2.1.214, against explicit policy outcomes. Keep production credentials, real remote targets, and production daemons out of the exercise. Record four observable results for each case: ran without approval, prompted, blocked, or fired the expected hook.

Start with the expression at the center of the change. Create a root src/ path and a nested packages/api/src/ path, then check Edit(src/**) separately as an allow, ask, deny, and hook if: condition. If the policy intends a root-only allow, any-depth ask or deny, and a root-only hook condition, the candidate client should produce those distinct results; where an any-depth hook is intended, test the explicit **/src/** form.

Next, run safe representatives of the execution surfaces the team actually supports. Include the shell grammar forms present in normal automation, a benign command longer than 10,000 characters, a remote no-op that requires local approval, and disposable Docker or Podman commands carrying each managed daemon-selection form. PowerShell 5.1 belongs in the set when it remains a supported shell, although the undisclosed bypass cannot be reproduced from the release note alone.

Pass or hold the patch based on those named outcomes. A pass means the current client line conforms to the team’s policy for the tested permission path and supported execution surfaces. A mismatch should identify the exact version, shell, working directory, rule class, hook condition, and remote or daemon context before the team changes a rule or pauses rollout.

If those expected outcomes have not been written yet, define them in the AI approval policy and capture the check in the AI workflow security review worksheet. The test remains deliberately narrow: it supports one deployment decision and does not certify Claude Code’s permission system as complete.

BaristaLabs can review one Claude Code permission path across the managed client version, shell mix, rules, hooks, and remote execution. Our process automation work can then turn the accepted cases into a repeatable release check.

Sources

• Claude Code 2.1.214 release
• Claude Code 2.1.215 release
• Claude Code permissions documentation
• Claude Code hooks documentation