Feature Request: Context-aware permission evaluation for read-only operations

Problem

The current permission system is pattern-based, matching command strings against whitelist patterns. This requires users to add explicit patterns for every combination of commands, even when all underlying operations are read-only.

Example: A command like:

cd /home/user/projects/myapp && git show e959a466 2>/dev/null | head -50

Gets blocked even though:

• git show is whitelisted via Bash(git show:*)
• head is whitelisted via Bash(head :*)
• cd is just directory navigation (not destructive)
• The pipe and redirect are flow control

The user must add yet another pattern like Bash(cd /home/*/projects/* && git:*) to cover this specific combination.

Proposed Solution

Implement context-aware permission evaluation that analyzes compound commands semantically:

1. Parse compound commands - Break down &&, ||, |, ; chains into individual operations
2. Evaluate each operation - Check if each component is a read-only operation
3. Allow if all components are read-only - If every part of the compound command is non-destructive, allow execution

Read-only operations would include:

• All git read commands (git show, git log, git diff, git status, git branch, etc.)
• File reading (cat, head, tail, less, grep, etc.)
• Directory navigation (cd, pushd, popd)
• Control structures (for, if, while, case) when their bodies contain only read operations
• Information commands (ls, find, stat, file, which, etc.)
• Pipes and redirects to stdout/stderr

Destructive operations would still require explicit permission:

• File modification (rm, mv, cp, chmod, chown)
• Git write operations (git push, git commit, git reset --hard)
• Package management (npm install, pip install, apt install)
• System changes (systemctl start/stop, kill, etc.)

Benefits

1. Reduced friction - Users don't need to whitelist every possible combination of safe commands
2. Better UX - Aligns with user intent ("allow read operations") rather than requiring pattern engineering
3. Maintains security - Destructive operations still require explicit approval
4. Simpler configuration - Could offer a single toggle like "allowReadOperations": true

Alternative: Simpler Implementation

If full semantic analysis is too complex, a simpler approach could be:

1. Add a "read-only mode" flag for compound commands
2. Allow patterns like Bash(cd:* && git show:*) to match regardless of the specific path
3. Support pattern composition where if A and B are allowed, A && B is automatically allowed

User Story

As a developer, I want Claude Code to understand that chaining read-only operations together is safe, so that I don't have to whitelist every possible combination of safe commands.

---

Environment:

• Claude Code CLI
• Linux/macOS/Windows

Related: Users who set policies like "no need to ask permission for read operations" in their CLAUDE.md still face permission prompts for compound read-only commands.