{"version":"2.1.248","anchor":"wider-corpus-for-judging-whether-a-bash-command-is-safe","canonical_anchor":"wider-corpus-for-judging-whether-a-bash-command-is-safe","heading":"Wider corpus for judging whether a bash command is safe","tier":"notice","area":"Permissions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248\/e\/wider-corpus-for-judging-whether-a-bash-command-is-safe","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248","markdown":"### Wider corpus for judging whether a bash command is safe\n\nMany more shell commands are recognised as read-only, so you get fewer needless permission prompts.\n\n**What**\n\nCommand safety analysis gained substantially more data: a bigger read-only command set (cal, uptime, hexdump, numfmt and others), zsh and bash builtin lists, literal safe-command patterns for things like `claude --help`, `node -v`, `ip addr`, `jq`, `cd`, `ls` and `find`, and a split of `find` primaries from actions so that `-delete`, `-execdir` and `-files0-from` count as unsafe.\n\n**Evidence**\n\n`\"--multi-turn-model\": \"string\"`\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 4\/5\n- Signal: 2\/5"}