{"version":"2.1.268","anchor":"new-bypass-immune-classifier-category-denyrulesunjudged","canonical_anchor":"bash-permission-deny-rules-extended-to-redirects-env-chd","heading":"Bash permission checks now catch unverifiable redirects and arguments","tier":"notice","area":"Permissions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268\/e\/new-bypass-immune-classifier-category-denyrulesunjudged","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.268","markdown":"### Bash permission checks now catch unverifiable redirects and arguments\n\nClaude Code now asks for permission instead of silently allowing bash commands it can't fully verify against deny rules\n\n**Unclear.** Which specific deny rules or actions fall under denyRulesUnjudged is not stated.\n\n**What**\n\nThe permission checker for chained bash commands now also inspects shell redirect targets (like `>`, `>>`, `<`) against Edit deny rules, and detects risky argument rewriting via `env`\/`env --chdir`. It also stops checking individual arguments once a cap is reached.\n\nWhen the checker can't fully verify every argument or redirect target against the configured deny rules, it now falls back to explicitly asking the user for permission rather than silently allowing the command. This new state is called `denyRulesUnjudged`, and it's registered as a new bypass-immune classifier category (alongside existing ones like `isolatePeerMachines`, `restrictedMode`, and `outsideReadsBlocked`), meaning it can't be skipped via normal bypass settings.\n\n**Why**\n\nPreviously, a bash command with a redirect or argument the checker couldn't fully evaluate against deny rules could be let through silently. Now Claude Code errs on the side of asking, closing a gap where a deny rule could be circumvented without the user noticing.\n\n- Area: Permissions\n- Names: `denyRulesUnjudged`\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 3\/5"}