[FEATURE] Feature request: named permission groups for reusable rule bundles

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Real-world .claude/settings.json files accumulate long, repetitive rule lists. For example, a "git-workflow" set of permissions might include Bash(git status), Bash(git diff ), Bash(git add ), Bash(git commit ), Bash(git log ), etc. Today these must each be listed individually, and keeping them consistent across settings.json, settings.local.json, and managed settings is error-prone.

Proposed Solution

Real-world .claude/settings.json files accumulate long, repetitive rule lists. For example, a "git-workflow" set of permissions might include Bash(git status), Bash(git diff ), Bash(git add ), Bash(git commit ), Bash(git log ), etc. Today these must each be listed individually, and keeping them consistent across settings.json, settings.local.json, and managed settings is error-prone.

Alternative Solutions

Proposed Behavior

{
  "permissionGroups": {
    "git-readonly": [
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git branch)"
    ],
    "node-dev": [
      "Bash(npm test *)",
      "Bash(npm run *)",
      "Bash(npx *)"
    ]
  },
  "allow": [
    "group:git-readonly",
    "group:node-dev",
    "Read"
  ]
}

Groups would be expanded at evaluation time, before the deny > ask > allow precedence logic runs. Groups defined in managed settings could be referenced but not overridden by project-level settings.

Current Workaround

A PreToolUse hook script can approximate this by maintaining rule bundles in an external config and returning approve/deny decisions. This works but is fragile, undiscoverable, and doesn't integrate with the settings UI or "always allow" flow.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

_No response_

Additional Context

_No response_