[DOCS] Misleading security recommendation for URL filtering in Bash permission patterns

Resolved 💬 2 comments Opened Jan 14, 2026 by coygeek Closed Jan 17, 2026

Documentation Type

Unclear/confusing documentation

Documentation Location

https://code.claude.com/docs/en/iam

Section/Topic

The Tool-specific permission rules section, specifically the Bash subsection regarding URL filtering limitations.

Current Documentation

"Patterns like Bash(curl http://github.com/:*) can be bypassed in many ways... For more reliable URL filtering, consider: Using the WebFetch tool with WebFetch(domain:github.com) permission"

What's Wrong or Missing?

The documentation identifies a valid security concern (that prefix matching for curl in Bash is easily bypassed) but suggests a flawed solution.

The flaw is as follows: If a user follows this advice and configures strict rules for WebFetch while still allowing the Bash tool, the model can simply ignore the WebFetch tool entirely. If the model wants to exfiltrate data or reach a disallowed domain, it can just use curl, wget, or python -c via the Bash tool.

Suggesting WebFetch as a "more reliable" workaround creates a false sense of security because it doesn't address the fact that the Bash tool remains an open vector for the same activity. A "reliable" solution must involve restricting the Bash tool itself or using a middleware-style validation.

Suggested Improvement

The documentation should be updated to clarify that WebFetch is only a replacement if Bash is also restricted, and it should point toward Hooks as the actual architectural solution for validating Bash commands.

Suggested replacement text:

"Patterns like Bash(curl http://github.com/:*) can be bypassed in many ways (redirection, variables, different protocols, etc.). To implement reliable URL filtering: 1. Restrict the Bash tool: Use permissions.deny to block tools like curl or wget entirely. 2. Use PreToolUse Hooks: Implement a hook that parses the command string in the tool_input and exits with code 2 if it detects disallowed domains or patterns. 3. Prefer WebFetch with restricted Bash: Use the WebFetch tool for authorized domains while ensuring the model cannot use the Bash tool as an alternative network vector."

Impact

High - Prevents users from using a feature

Additional Context

  • Related Documentation: [Hooks Guide](/en/hooks-guide) and [PreToolUse Hook Input](/en/hooks#pretooluse-input).
  • Example of Logic Bypass: If a user sets WebFetch(domain:internal.com) to "Allow" and WebFetch generally to "Deny", a model encountering a "Permission Denied" on a WebFetch call to malicious.com will simply attempt ! curl malicious.com if the Bash tool is permitted. The documentation should warn users that the model is clever enough to switch tools to find the path of least resistance.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗