Back to rankings

Claude Code Patches Four Permission-Enforcement Gaps

Claude CodeView original changelog

Claude Code 2.1.260 closed four separate ways a permission rule could fail to actually enforce what a user configured. A path containing parentheses could be dropped as invalid, leaving folders that were meant to be read-only writable; certain zsh variable assignments could hide a command substitution past the approval prompt; Glob and Grep probed whether a search path existed on disk before the permission decision was made; and a malformed deny rule with trailing text was silently ignored instead of flagged. Together the fixes continue a pattern of near-weekly, narrow corrections to Claude Code's permission layer through August and into September 2026.

Key Takeaways

  • Parentheses in a file path could cause Edit, Write, and Read permission rules to be dropped entirely, leaving supposedly read-only folders writable.
  • Obscure zsh variable assignments (REPORTTIME, REPORTMEMORY, DIRSTACKSIZE) could hide a command substitution past Bash's approval prompt.
  • Glob and Grep leaked path-existence information by probing the filesystem before the permission decision was made, not after.
  • A malformed deny rule with trailing text was silently ignored rather than flagged, giving users a false sense that a protection was active.
  • This continues a run of permission-enforcement fixes across recent 2.1.x releases rather than being a one-off cleanup.
  • None of the four bugs allowed a dramatic sandbox escape on their own, but each represents a rule silently not doing what a user configured it to do.

Four More Gaps in the Permission Layer

Claude Code 2.1.260 fixed four separate bugs in how the tool enforces the permission and deny rules a user has already configured, continuing a cadence of small, frequent hardening fixes to this layer that Anthropic has kept up for weeks.

Parentheses in a path broke read-only protection

Edit, Write, and Read permission rules whose path contained parentheses were being dropped as invalid, or ignored outright by the Bash sandbox. In practice this meant a folder a user had explicitly marked read-only could be silently writable if its path happened to include a parenthesis, with no warning that the protection had failed to apply.

Hidden command substitutions in zsh variables

Bash permission checks were auto-approving zsh commands that concealed a command substitution inside an assignment to the REPORTTIME, REPORTMEMORY, or DIRSTACKSIZE shell variables, obscure zsh-specific settings that can execute arbitrary code as a side effect of being set. These commands now prompt for approval like any other command that runs code.

Search paths were probed before permission was decided

Glob and Grep were checking whether a search path existed on disk before the permission system had decided whether the search was even allowed. That ordering meant Claude Code could learn whether a path existed on the filesystem before a user approved (or denied) access to it. The check now runs after the permission decision, matching how the Read tool already behaves, and a missing path is only reported once access has been decided.

Deny rules that never matched anything

A permission rule with stray text after its closing parenthesis (for example Bash(ls) x) never actually matched any command, but Claude Code silently ignored the malformed rule rather than surfacing it. A user relying on such a rule for protection had no indication it was not doing anything. These malformed rules are now reported as invalid settings instead.

The pattern

None of these four issues involve a dramatic escape from the sandbox on their own, but each is a case where a rule a user explicitly set was not actually being honored the way they expected. Bundled together, they represent the kind of quiet permission-layer erosion that matters most to security-conscious teams relying on Claude Code's approval prompts and deny rules to do what they say.