Bash's 'too complex to check' read-block guard now applies via a general table covering more refusal reasons, not just one hardcoded case
When permissions.blockReadsOutsideWorkingDirectories is turned on (which makes file tools refuse reads outside your designated working directories), Bash commands that can't be reliably checked against that rule are refused. Previously this only applied to commands flagged as "too complex." Now a table of refusal reasons decides which ones trigger the same refusal, including: too-complex, semantics, multi-cd, shell-operators, cd-git-compound, and process-substitution. Other reasons, like dangerous-path, flag-validation, net-redirect, and sed-dangerous, are explicitly excluded.
This broadens the read-block safety net to more kinds of Bash commands that are hard to statically verify, closing gaps where a command could previously slip past the outside-working-directory read restriction just because it wasn't classified as "too complex."
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.
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…memory see the edit
Whether this behavior is active for this site's account is not established; the related gate is unread.
A small documentation edit on How Claude remembers your project touched a line naming blockReadsOutsideWorkingDirectories after this was…
Fixed Bash commands the permission checker cannot fully analyze skipping the prompt under permissions.blockReadsOutsideWorkingDirectories…