[DOCS] Ambiguous Security Posture Regarding Bash/Curl Permission Rules
Documentation Type
Missing documentation (feature not documented)
Documentation Location
Section/Topic
The interaction between "Command blocklist" in the Security documentation and "Permission rule syntax" (specifically regarding the Bash tool) in the Identity and Access Management documentation.
Current Documentation
From the Security page:
"Command blocklist: Blocks risky commands that fetch arbitrary content from the web like curl and wget by default. When explicitly allowed, be aware of permission pattern limitations"
From the IAM page:
"A rule that is just the tool name matches any use of that tool. For example, adding Bash to the allow list allows Claude Code to use the Bash tool without requiring user approval."
"If Bash is allowed, Claude can still use curl, wget, or other tools to reach any URL."
What's Wrong or Missing?
There is a conflict in tone and technical clarity between the two pages that creates a potential security vulnerability for users.
- The Security page claims a "default" blocklist protects against
curl/wget. - The IAM page states that
allow: ["Bash"]matches any use of the tool.
It is unclear if the specific "default blocklist" mentioned in Security persists even when a generic Bash allow rule is set in IAM. A user might assume that allow: ["Bash"] grants access to standard shell commands but that the "default blocklist" will still catch risky network tools like curl. The warning in the IAM section suggests curl will work if Bash is allowed, effectively overriding the default security posture, but this override behavior is not explicitly defined as a warning in the configuration section.
Suggested Improvement
In the Identity and Access Management section under "Bash", explicitly warn that adding Bash to the allow list bypasses the default security blocklist for tools like curl and wget.
Provide a specific configuration example that allows generic Bash commands but explicitly maintains the block on network tools to preserve the security posture described in the Security documentation.
Example addition:
Security Warning: Adding"Bash"to your allow list grants permission for all bash commands, overriding the default blocklist for network tools. To allow general bash usage while maintaining security against data exfiltration, you must explicitly deny network tools: ``json { "permissions": { "allow": ["Bash"], "deny": ["Bash(curl:*)", "Bash(wget:*)"] } }``
Impact
High - Prevents users from using a feature
Additional Context
This ambiguity can lead to users inadvertently allowing data exfiltration paths. A user reading the Security doc feels safe because of the "default blocklist," then goes to IAM and enables Bash for convenience, unaware they have just disabled that safety mechanism.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗