{"version":"2.1.317","anchor":"standing-allow-rule-composer-and-compose-op-for-permission","canonical_anchor":"standing-allow-rule-composer-and-compose-op-for-permission","heading":"Groundwork for safely offering narrow always-allow permission rules","tier":"internal","area":"Permissions","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.317\/e\/standing-allow-rule-composer-and-compose-op-for-permission","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.317","markdown":"### Groundwork for safely offering narrow always-allow permission rules\n\nNew code can build narrow always-allow rules for a command, host or MCP tool, refusing risky cases and saving to local or project settings\n\n**Unclear.** Whether anything in Claude Code offers these rules to you yet is not stated.\n\n**What**\n\nClaude Code has new code for building standing allow rules, permission rules that let something run without asking each time. A rule can cover a command, a web host or an MCP tool, and is kept narrow. It covers:\n\n- Read-only commands.\n\n- `mkdir`, `touch`, `rm`, `mv` and `cp` with a limited set of flags.\n\n- `npm test` and `make` targets.\n\nIt refuses with a named reason in risky cases, for example when a managed deny rule applies, when you have your own ask rule, when a command is not known to be safe, when a host is not public, or when the path contains a symlink. Rules are saved to your local or project settings with a write that guards against symlinks.\n\n**Why**\n\nIf this is connected to a screen you can use, it changes how you create permanent allow rules, with Claude Code refusing to offer ones that would be unsafe.\n\n- Area: Permissions\n- Tier: Under the hood\n- Useful: 3\/5\n- Signal: 4\/5\n- Scope: individual\n- Heads-up: no"}