Smarter contextual parsing of shell metacharacters before prompting for permission

Problem

When Claude Code's Bash tool encounters shell metacharacters like >, |, ;, or #, it triggers a permission prompt with messages like:

"Command contains output redirection (>) which could write to arbitrary files"

This happens regardless of context — even when the usage is clearly safe. For example:

• echo "hello" > /tmp/test.txt (known safe path)
• Commands where # appears in a code comment, CSS hex color, or markdown heading
• Simple pipes to well-known safe commands like | head, | wc -l

This creates unnecessary friction, especially for power users who are frequently approving obviously benign commands.

Proposed Solution

Instead of pattern-matching on the presence of a character alone, parse what follows the flagged character to assess actual risk:

1. Output redirection (>): Check the target path. Writing to /tmp, a file in the current working directory, or a path the user has previously approved is far less risky than writing to /etc/passwd or ~/.ssh/authorized_keys.
2. Pipes (|): A pipe to head, grep, wc, sort, jq, less, etc. is not dangerous. Only flag pipes to commands that can cause side effects (e.g., | sh, | bash, | tee /etc/...).
3. Hash (#): Already discussed in other contexts — # in comments, hex colors, and markdown is not a shell risk.
4. Semicolons (;): Evaluate the command after the semicolon with the same rules as a standalone command, rather than flagging the semicolon itself.

General principle: The permission system should evaluate the semantic risk of the full command, not just the presence of a metacharacter. A simple AST-level or tokenized parse of the shell command would catch the actually dangerous patterns while letting safe ones through.

Impact

• Reduces permission prompt fatigue for experienced users
• Prevents users from developing a habit of blindly approving prompts (which defeats the purpose of the security check)
• Keeps the security model effective by focusing attention on genuinely risky commands

Alternatives Considered

• Users can use dedicated tools (Write, Edit, Read) instead of shell commands, but sometimes shell is the right tool for the job
• Allowlisting specific commands works but doesn't scale and requires manual configuration