{"version":"2.1.273","anchor":"bash-too-complex-command-handling-reworked-with-a-per-reas","canonical_anchor":"bash-too-complex-command-handling-reworked-with-a-per-reas","heading":"Bash 'too complex' command handling reworked with a per-reason-kind table gating the outside-working-directory read block","tier":"notice","area":"Bash Safety","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.273\/e\/bash-too-complex-command-handling-reworked-with-a-per-reas","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.273","markdown":"### Bash 'too complex' command handling reworked with a per-reason-kind table gating the outside-working-directory read block\n\nBash's 'too complex to check' read-block guard now applies via a general table covering more refusal reasons, not just one hardcoded case\n\n**Unclear.** Whether this behavior is active for this site's account is not established; the related gate is unread.\n\n**What**\n\nWhen `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.\n\n**Why**\n\nThis 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.\"\n\n- Area: Bash Safety\n- Names: `blockReadsOutsideWorkingDirectories`\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}