Permission auto-approve should separate read/write/delete operations
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.
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This would also make the permission log much more auditable. Right now an
always allowdecision overgit *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:
git status,git diff,git log,git show,git rev-parsegit add,git commit, branch creation/renamegit push,git fetch --prunegit reset --hard,git clean -f,git branch -D, force pushThen 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.
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.A wildcard such as
git *collapses observability and mutation into one permission. Git is a good demonstration becausestatusandbranch --show-currentare read-only, whileclean -fd,reset --hard, force-push, and branch deletion can destroy work.The safer permission model is operation-aware: broad convenience allowances for proven read-only subcommands, then a non-overridable floor for destructive variants. An “always allow” choice for one read command should never authorize destructive siblings.
Disclosure: I maintain gate.cat, an open-source local veto layer. We use this read/write/delete separation as defense in depth when agent clients expose overly broad wildcard permissions.