Rules / Hidden content and security

sec-permission-allow

Allow rule or trust flag skips the prompt for any shell command, network tool or interpreter.

error by default Hidden content and security Config or baseline only

Source: code.claude.com (code.claude.com), read 14 October 2026.

On GitHub: the rule doc and the tests.

All rules73

Severity: error for Bash or Bash(*); a warning for network tools, interpreters with a wildcard and an unscoped WebFetch.

What it catches#

Allow rule or trust flag skips the prompt for any shell command, network tool or interpreter.

A permissions.allow entry in .claude/settings.json that pre-approves Bash or PowerShell with no pattern or (*) (error), or, as warnings: WebFetch with no domain, a network tool with a wildcard (Bash(curl *), Bash(nslookup *)), Bash(git push *) or Bash(gh api *), or a wildcard that covers an interpreter or package runner (Bash(python *), Bash(node *), Bash(sh *), Bash(npx *), Bash(uv run *)). A Gemini CLI MCP server with trust: true is reported here too. Needs --include config; .claude/settings.local.json is read only with --include config-local.

Why it matters#

An allow rule runs the command without asking, so text the agent reads can trigger it. CVE-2025-55284 leaked .env contents through allowlisted ping and nslookup. Bash and Bash(*) allow every command and are errors; network tools, interpreters with a wildcard and an unscoped WebFetch are warnings.

Bad example#

{
  "permissions": {
    "allow": ["Bash", "WebFetch", "Bash(python3 *)"]
  }
}

Every shell command and every URL runs without asking, in every session in this project, for everyone who clones it. Bash(python3 *) is Bash with extra steps: python3 -c runs anything.

Good example#

{
  "permissions": {
    "allow": ["Bash(pnpm test)", "Bash(pnpm lint)", "Bash(git status *)", "WebFetch(domain:docs.example.invalid)"]
  }
}

How to fix#

Allow the exact commands the project uses, with their prefix. Scope network tools to a domain. Leave interpreters out of the allow list; Claude asks before running them, which is the point.

Suppress or configure#

sec-permission-allow is a security rule, so it cannot be suppressed with a comment in the file: a suppression comment is itself a hidden comment, and an attacker who can add a payload can add one next to it. A comment that tries gets a suppression-not-allowed warning.

Turn it off, or change its severity, in .asitisrc.json, which shows up in review:

{ "rules": { "sec-permission-allow": "off" } }

Or accept the findings you have today in a baseline, so only new ones fail the build:

asitis lint --format json --write-baseline > .asitis-baseline.json
asitis lint --baseline .asitis-baseline.json

Source#

code.claude.com, read on 14 October 2026.

Run the rule

This page is generated from the plugin's rule registry. Edit it on GitHub. False positive? Open an issue with the line it fired on.