{"version":"2.1.269","anchor":"closed-a-loophole-letting-a-glob-before-escape-the-read","canonical_anchor":"closed-a-loophole-letting-a-glob-before-escape-the-read","heading":"Closed a loophole letting a glob before '..' escape the read-directory block","tier":"notice","area":"Permissions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.269\/e\/closed-a-loophole-letting-a-glob-before-escape-the-read","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.269","markdown":"### Closed a loophole letting a glob before '..' escape the read-directory block\n\nClaude Code now blocks a glob-before-'..' trick that could have escaped read-directory restrictions\n\n**What**\n\nClaude 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.\n\n**Why**\n\nThis 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.\n\n- Area: Permissions\n- Names: `blockReadsOutsideWorkingDirectories`\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}