[DOCS] Permission docs do not distinguish dir/** scope for allow versus deny and ask rules

Documentation Type

Unclear/confusing documentation

Documentation Location

https://code.claude.com/docs/en/permissions

Section/Topic

“Read and Edit” path patterns, especially the mode-dependent scope of a single-segment dir/** rule.

Current Documentation

The page currently says:

Read and Edit rules both follow the gitignore specification with four distinct pattern types.

It gives Read(src/**) as an example of a rule that reads from <current-directory>/src/ and says:

In gitignore patterns, matches within a single path segment and can appear at any position in the pattern, while * matches across directories.

The page also says that a rule only matches files under its anchor, but it does not state that the corrected anchoring applies to allow rules while deny and ask rules retain any-depth matching for this pattern form.

What's Wrong or Missing?

Claude Code 2.1.214 fixes single-segment dir/ allow rules such as Edit(src/) so they auto-approve writes only under <cwd>/src, rather than matching a same-named src directory at arbitrary depth elsewhere in the tree. The release also states that deny and ask permission rules retain their any-depth matching behavior. The current path-pattern section describes anchors generically and does not explain that this pattern has different scope depending on the permission mode.

Without that distinction, users can overestimate the reach of an allow rule, underestimate the reach of a deny or ask rule, or assume the modes use identical matching semantics when they do not.

Suggested Improvement

Add an explicit mode-comparison note and examples under the Read and Edit path-pattern section. For example:

~~~text
For allow rules, a single-segment relative pattern such as Edit(src/) is anchored to <cwd>/src and does not auto-approve matching directories elsewhere in the tree. Deny and ask rules using the same single-segment dir/ form retain any-depth matching. Use an explicit /src/ pattern when an any-depth match is intended on a surface with project-relative semantics, such as a hook if condition.
~~~

Include a small table showing the same nested paths against allow, ask, and deny rules so the security-sensitive difference is unambiguous.

Impact

Medium - Makes feature difficult to understand

Additional Context

The behavior is user-visible because it changes whether a file edit is automatically approved or still prompts for confirmation. The documentation should state the scope of the corrected behavior rather than only describing the general glob syntax.

Affected Pages:

| Page | Context |
|------|---------|
| https://code.claude.com/docs/en/permissions | Read and Edit path patterns and wildcard semantics |

Release: Claude Code 2.1.214.