Observed

Source-reviewed against the issue tracker: deny non-enforcement is a recurring regression across three major version lines — v1.0.93 (#6699, Aug 2025), v2.0.8 (#8961, Oct 2025), and v2.1.49 (#27040, Feb 2026, where files matching an explicit Read(**/appsettings.Production.json) deny pattern were read and edited with no prompt and no error). A deny rule on a path does not bind MCP tools reading the same path (#28595) or Bash recursive grep/Glob (#28008), and deny rules in parent settings do not apply to Agent-spawned subagents — confirmed across 5+ issues, with #5465 closed not-planned as an architectural limitation. CVE-2026-25724 added a symlink deny bypass. The current docs qualify the claim (a "best-effort" Read-rule statement, a subprocess warning, and explicit symlink deny semantics) — a partial label correction since the finding was published.

1. UPDATE 2026-07-04(v2.1.201, TD-executed): the three deny-bypass issues this row rested on all closed WITHOUT a fix — #27040 closed stale/not-planned (2026-05-23), #28595 auto-closed as a duplicate of #27040 (2026-03-01), and #28008 closed by stale-bot despite a 'has repro' label (2026-03-24). Theory Delta then executed a controlled reproduction on the current release: a scratch project with a Read(secret.txt) deny rule was driven via claude -p. The direct Read tool was blocked; a direct Bash 'cat secret.txt' of the exact denied path was also blocked (an improvement consistent with the v2.1.162–163 path-deny hardening); but 'grep -r' recursing into the denied file printed the secret line verbatim — the #28008 recursive-grep bypass persists and still exfiltrates the denied file's contents. A separate v2.1.162 changelog entry ('Read deny rules not hiding files from Glob/Grep results') hardened the built-in Grep/Glob tools, not shell grep -r. The categorical label ('no other level can allow it') therefore remains contradicted on the current release; status held at not_as_labeled on executed evidence.