[FEATURE] Global 'disableAlwaysAllow' Option in Permissions Configuration

Preflight Checklist

• [x] I have searched existing enhancement requests
• [x] This is a single feature request (not multiple requests)

Problem Statement

Claude Code currently supports three permission arrays: allow, ask, and deny. While the ask array allows project maintainers to flag specific commands that always require approval, there's no way to globally disable the "always allow" option across all commands.

When users approve commands, they see three options:

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

This creates a security gap: even with carefully configured allow, ask, and deny arrays, users can still bypass project-level controls by permanently approving any command that isn't explicitly configured. Project maintainers have no way to enforce that all unapproved operations require one-time approval only.

What's missing: A global toggle to disable the "always allow" option, forcing users to either:

• Use commands pre-authorized in the allow array, OR
• Approve commands one-time for each execution

Proposed Solution

Add a disableAlwaysAllow boolean flag to .claude/settings.json:

{
  "permissions": {
    "disableAlwaysAllow": true,
    "allow": [
      "Bash(git status:*)",
      "Bash(yarn install:*)",
      "Bash(yarn build:*)"
    ],
    "ask": [
      "Bash(rm:*)",
      "Bash(git push:*--force*)"
    ],
    "deny": [
      "Read(.env)",
      "Read(secrets.json)"
    ]
  }
}

When disableAlwaysAllow: true:

• Permission dialogs show only two options: "Yes (this time only)" / "No"
• The "always allow" option is completely hidden for all commands
• Users must rely on the project-configured allow array for permanent approvals

User Experience:

Current behavior (default):
Command: yarn dev
Dialog:
1. Yes
2. Yes, and always allow
3. No

With disableAlwaysAllow: true:
Command: yarn dev
Dialog:
1. Yes (this time only)
2. No

Expected Behavior Table

| Command | Configuration | Dialog Options |
|---------|--------------|----------------|
| git status | In allow array | No prompt (pre-authorized) |
| rm file.txt | In ask array | "Yes (this time)" / "No" only |
| rm -rf / | In deny array | Blocked entirely |
| yarn dev | Not configured + disableAlwaysAllow: false | "Yes" / "Always allow" / "No" |
| yarn dev | Not configured + disableAlwaysAllow: true | "Yes (this time)" / "No" only |

Alternative Solutions

1. Time-based approvals: Replace permanent "always allow" with temporary approvals (e.g., "allow for 1 hour" or "allow for this session")

1. Layered configuration files: Support .claude/settings.json (project-level, committed) and .claude/settings.local.json (user-level, gitignored), where project settings can enforce disableAlwaysAllow that users cannot override

1. Automatic enforcement: When ask or deny arrays are non-empty, automatically enable disableAlwaysAllow behavior

Current workaround: Use exhaustive allow and ask arrays to cover every possible command, but this is impractical and doesn't prevent users from approving new/unexpected commands.

Priority

Medium

(While not blocking daily work, this addresses legitimate security concerns for teams and enterprises requiring strict access control)

Feature Category

Configuration

Use Case Example

Scenario: Enterprise Team with Strict Security Policy

Project maintainer configures:

{
  "permissions": {
    "disableAlwaysAllow": true,
    "allow": [
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Bash(yarn install:*)",
      "Bash(yarn build:*)",
      "Bash(yarn test:*)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(git commit:*)"
    ],
    "deny": [
      "Read(.env)",
      "Read(secrets.json)",
      "Bash(rm:*--force*)",
      "Bash(git push:*--force*)"
    ]
  }
}

Workflow:

1. Developer asks Claude: "Build the project"

• Runs yarn build → Executes immediately (in allow array)

1. Developer asks Claude: "Commit these changes"

• Runs git commit → Shows approval dialog (in ask array)
• Dialog shows: "Yes (this time)" / "No" (no "always allow" option)
• Developer approves for this one time
• Next commit requires approval again

1. Developer asks Claude: "Start the dev server"

• Runs yarn dev → Shows approval dialog (not configured)
• Dialog shows: "Yes (this time)" / "No" (no "always allow" option due to global setting)
• Developer cannot permanently approve this command

1. Developer asks Claude: "Delete all log files"

• Runs rm -rf logs/ → Blocked (matches deny pattern)

Security benefit: Project configuration ensures developers cannot bypass access controls. Only pre-approved operations can run without repeated approval.

Without This Feature:

In step 3, the dialog would show "Always allow" option, and the developer could permanently approve yarn dev, bypassing the project's security policy. Over time, the project loses control as users accumulate permanent approvals for unapproved commands.

Additional Context

Permission Resolution Order with This Feature:

1. Check deny → blocked if matched
2. Check allow → execute immediately if matched
3. Check ask → show approval dialog without "always allow" option
4. Otherwise → show permission dialog

• If disableAlwaysAllow: true → hide "always allow" option
• If disableAlwaysAllow: false (default) → show all three options

Security Control Levels (Weakest → Strongest):

1. Default (current): Users can permanently approve anything
2. Selective control: Use ask array for specific dangerous commands
3. Global enforcement (proposed): disableAlwaysAllow: true + curated allow array
4. Full lockdown: Combine above with comprehensive deny list

Relationship to Existing Features:

• allow array: Pre-authorize safe commands ✅ Exists
• deny array: Block dangerous commands ✅ Exists
• ask array: Force approval for specific commands ✅ Exists (as of v1.0.72)
• disableAlwaysAllow: Force approval for all non-allowed commands ❌ Requested

Together, these provide complete access control:

• Pre-authorization for trusted operations (allow)
• Complete blocking for prohibited operations (deny)
• Per-command mandatory review (ask)
• Global mandatory review for everything else (disableAlwaysAllow)

Security Benefits:

• Prevents users from bypassing project-level security policies
• Enables audit compliance (all unapproved operations require explicit review)
• Allows project maintainers to enforce consistent security posture across all contributors
• Provides "allowlist-first" security model: only pre-approved operations can be permanently allowed

Target Users:

• Enterprise teams with strict security policies
• Open-source projects with multiple contributors
• Repositories handling sensitive data or infrastructure
• Teams requiring audit trails for all code changes
• Organizations with compliance requirements (SOC 2, ISO 27001, HIPAA, etc.)

Implementation Considerations:

• disableAlwaysAllow should be repository-level config (committed to git)
• Configuration should support layered overrides (project-level takes precedence over user preferences)
• When "always allow" is disabled, show a brief message explaining: "This project requires approval for each command execution"
• Should work consistently across CLI and any GUI interfaces