Feature Request: Parameter-Specific Command Whitelisting

Summary

Add support for whitelisting exact commands with their specific parameters, rather than just the base command. This would provide more granular security control while reducing repetitive confirmation prompts.

Current Behavior

When Claude Code executes a command and asks for user confirmation, the "don't ask again" option whitelists the entire base command for a directory. For example:

warden env exec -T php-fpm php test_settings_endpoint.php 2>&1 | grep -A 10 "Product"

Do you want to proceed?
❯ 1. Yes
  2. Yes, and don't ask again for warden env exec commands in /home/x/y

Selecting option 2 currently whitelists ALL warden env exec commands in that directory, regardless of their parameters.

Desired Behavior

The whitelisting system should support three levels of granularity:

1. Exact command with parameters (most restrictive)
2. Command with partial parameters (moderate)
3. Base command only (current behavior, least restrictive)

Example of proposed prompt:

warden env exec -T php-fpm php test_settings_endpoint.php 2>&1 | grep -A 10 "Product"

Do you want to proceed?
❯ 1. Yes (one time)
  2. Yes, and don't ask again for this exact command in /home/x/y
  3. Yes, and don't ask again for 'warden env exec -T php-fpm php' commands in /home/x/y
  4. Yes, and don't ask again for any 'warden env exec' commands in /home/x/y

Use Cases

Security-Critical Environments

• In production or staging environments, teams need fine-grained control over what commands can be executed
• Whitelisting rm -rf /specific/cache/dir should not automatically allow rm -rf /

Container Commands

• Commands like docker exec, kubectl exec, warden env exec often have critical parameters
• -T flag, specific container names, and commands run inside containers should be controllable
• Example: Whitelisting docker exec -it web bash shouldn't allow docker exec -it db mysql -uroot

Script Execution

• Whitelisting python script.py --dry-run should not automatically allow python script.py --production
• NPM scripts: npm run test vs npm run deploy have very different implications

Database Operations

• mysql -e "SELECT * FROM users LIMIT 10" vs mysql -e "DROP TABLE users"
• Both start with mysql -e but have vastly different consequences

Proposed Implementation

Settings Structure

Enhance the current settings/whitelist structure to support parameter matching:

{
  "whitelisted_commands": [
    {
      "command": "warden env exec",
      "path": "/home/x/y",
      "match_type": "exact",
      "full_command": "warden env exec -T php-fpm php test_settings_endpoint.php",
      "parameters_pattern": null
    },
    {
      "command": "npm run",
      "path": "/home/user/project",
      "match_type": "prefix",
      "full_command": null,
      "parameters_pattern": "^(test|lint|typecheck)"
    },
    {
      "command": "rm",
      "path": "/tmp",
      "match_type": "base",
      "full_command": null,
      "parameters_pattern": null
    }
  ]
}

Matching Logic

1. Exact match: Compare the entire command string
2. Pattern match: Use regex or glob patterns for parameters
3. Base match: Current behavior (match command prefix only)

User Interface Options

• Add keyboard shortcuts for quick selection (1-4 keys)
• Remember user's preference pattern (if they always choose exact, make it the default)
• Add a settings command to review/edit whitelisted commands: /whitelist review

Benefits

Enhanced Security

• Prevents accidental whitelisting of dangerous command variations
• Maintains principle of least privilege
• Reduces risk of unintended operations

Better User Experience

• Power users can still broadly whitelist if desired
• Cautious users get the granularity they need
• Reduces "confirmation fatigue" without sacrificing security

Compliance & Auditing

• Some organizations require detailed command approval logs
• Parameter-specific whitelisting provides better audit trails
• Helps meet security compliance requirements

Backward Compatibility

• Existing whitelisted commands continue to work with "base" match type
• No breaking changes to current user settings
• Migration path: Existing entries get "match_type": "base" added automatically

Priority

High - This is a security-sensitive feature that would benefit many users working in production environments or with sensitive data.

Related Issues

• Could be related to any existing issues about command execution safety
• May complement features like command history or command templates