Rules / Hidden content and security
sec-permission-allow
Allow rule or trust flag skips the prompt for any shell command, network tool or interpreter.
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.
Related guides
Run the rule
- In your browser, on one file
- In Claude Code, on the project
- In CI, on every pull request
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.