You'll noticeTier: how much it should matter to you
2Useful: my rating, 1 to 5
1Signal: worth watching, 1 to 5
PermissionsArea: what it touches
Bug FixesKind: in v2.1.269,
Bug FixesSection of the release
What
Claude Code now detects when a file path being read contains a glob (a wildcard pattern like *) placed before a .. (parent directory) segment. Because the shell would expand that glob before Claude Code gets a chance to check the resulting path against read restrictions like blockReadsOutsideWorkingDirectories or deny rules, such a path is now denied outright with an explicit safety message, instead of being silently evaluated as whatever the shell expanded it to.
Why
This closes a way a crafted path could have let a file read escape the directories it was supposed to be confined to, since the pre-expansion path couldn't otherwise be verified against those restrictions.
The entry above is what we published on the day. These lines were added later, as Anthropic's own pages caught up, and they sit beside the original rather than replacing it.
Added sinceA small documentation edit on How Claude remembers your project touched a line naming blockReadsOutsideWorkingDirectories after this was published.When you set it in a project's `.claude/settings.json` or `.claude/settings.local.json`, Claude Code honors it under the same [workspace trust rule as hooks in settings files](/docs/en/permissions#what-runs-before-you-trust-a-folder). Whil…memorysee the edit
Confirmed sinceAnthropic's documentation has since written up blockReadsOutsideWorkingDirectories, on Claude Code changelog.* Fixed Bash commands with two directory changes, a subshell, or a `cd`+`git` chain skipping the prompt under `permissions.blockReadsOutsideWorkingDirectories` in bypass and auto modechangelogsee the edit
How sure we are
One source agreesOne thing we can check says the same as this entry.
Anthropic's documentation agreesAnthropic's documentation has since written up blockReadsOutsideWorkingDirectories, on Claude Code changelog.
