Feature Request: Per-Command Permission Control for "Allow Always" Option

Feature Request: Per-Command Permission Control for "Allow Always" Option

Summary

Add configuration to disable the "always allow" option in permission dialogs for specific commands or command patterns, forcing certain operations to require explicit approval every time.

Motivation

When Claude Code prompts for permission to run commands, it currently offers three options:

1. Yes
2. Yes, and always allow access to [directory] from this project
3. No

For security-sensitive or destructive operations (like rm, git push --force, docker system prune, etc.), allowing permanent approval creates unnecessary risk. A developer might accidentally approve "always allow" for a dangerous command pattern, and then that command can be executed without future oversight.

Use Case

As a repository maintainer, I want to:

• Allow developers to approve one-time executions of dangerous commands
• Prevent developers from permanently approving certain command patterns
• Ensure destructive operations always require explicit human review

Example dangerous commands that should never have "always allow":

• File deletion: rm, rm -rf
• Force operations: git push --force, git reset --hard
• System-wide changes: docker system prune, chmod -R, chown -R
• Package removal: yarn remove, npm uninstall, cargo clean

Proposed Solution

Add a new configuration option in .claude/settings.json:

{
  "permissions": {
    "allow": ["Bash(git status:*)", "Bash(yarn install:*)"],
    "deny": ["Read(.env)", "Read(secrets.json)"],
    "requireExplicitApproval": [
      "Bash(rm:*)",
      "Bash(git push:*--force*)",
      "Bash(docker system prune:*)",
      "Bash(chmod:-R*)",
      "Bash(chown:-R*)",
      "Bash(yarn remove:*)",
      "Bash(npm uninstall:*)",
      "Bash(pip uninstall:*)"
    ]
  }
}

When a command matches a pattern in requireExplicitApproval, the permission dialog would show:

1. Yes (this time only)
2. No

The "always allow" option would be hidden for these specific commands.

Alternative Solutions

1. Severity levels: Commands could be tagged with severity levels (safe/caution/danger), with "always allow" disabled for danger-level commands
2. Admin override: A repository-level config that team admins control, separate from user preferences
3. Time-based approvals: Allow temporary approvals (e.g., "allow for 1 hour") instead of permanent ones

Benefits

• Improved security: Prevents accidental permanent approval of destructive operations
• Audit compliance: Ensures critical operations always have explicit human oversight
• Team safety: Repository maintainers can enforce safe practices across all developers
• Granular control: Works alongside existing allow/deny lists for comprehensive permission management

Related Features

This complements the existing permission system:

• allow array: Pre-authorize safe commands (no prompt)
• deny array: Block dangerous commands entirely
• requireExplicitApproval array: Prompt every time, no "always allow" option

Together, these provide complete control over command execution safety.

Expected Behavior

| Command | Configuration | Dialog Options |
|---------|--------------|----------------|
| git status | In allow array | No prompt (pre-authorized) |
| rm -rf / | In deny array | Blocked entirely |
| rm file.txt | In requireExplicitApproval | "Yes (this time)" / "No" only |
| yarn build | Not configured | "Yes" / "Always allow" / "No" |

---

Environment:

• Claude Code version: [current version]
• Platform: macOS/Linux/Windows
• Use case: Multi-developer repository with security requirements