Permission auto-approve should separate read/write/delete operations

[ndrone-winsupply]

Problem

When Claude Code prompts for tool permission approval, the "always allow" option uses a wildcard that doesn't distinguish between read and write operations.

Example: Running git branch --show-current (a read-only command) offers git * as the auto-approve option. Accepting that would also auto-approve destructive commands like git push --force, git reset --hard, git clean -f, etc.

This makes the auto-approve option unusable for safety-conscious users — you have to deny every time because the granularity is too coarse.

Expected Behavior

The auto-approve options should separate by operation type. For example:

• Read-only git: git branch *, git log *, git diff *, git status *, git rev-parse *, git show *
• Write git: git add *, git commit *, git push *
• Destructive git: git reset --hard *, git push --force *, git clean -f *, git branch -D *

This way users can auto-approve read operations without inadvertently allowing destructive ones.

Impact

Users who care about safety end up denying most auto-approve prompts, adding friction to every session. The current wildcard grouping defeats the purpose of having granular permissions.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] ask list is ignored when "Bash" is in allow list #6527
2. [FEATURE] Granular permission profiles for Claude Code — alternative to binary skip-permissions #35527
3. Bash read-only commands (curl, gh) still prompt for permission despite allow rules #62135

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[0xbrainkid]

This would also make the permission log much more auditable. Right now an always allow decision over git * records a broad user intent, but it does not preserve the risk class the user thought they were approving.

A useful shape might be to have auto-approve suggestions carry an operation class as well as the command pattern:

• read: git status, git diff, git log, git show, git rev-parse
• write: git add, git commit, branch creation/rename
• remote mutation: git push, git fetch --prune
• destructive: git reset --hard, git clean -f, git branch -D, force push

Then the audit trail can say "user approved read-only git commands" instead of "user approved git wildcard." That distinction matters when reviewing an incident after the fact, because the consent boundary is otherwise impossible to reconstruct.

[dgunay]

You can add entries in Claude's permission settings that will let you do git status *, etc without allowing write operations. I like to tell Claude to update its settings each time the permission dialogue pops up for something that should be safe but doesn't show a sane blanket permission option.