Skip to content

[FEATURE] Add "Yes, always allow" option to permission prompt that persists to global allowlist #32973

Description

@ZacharyBys

Preflight Checklist

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

Problem Statement

When using Claude Code across multiple projects and sessions, I frequently get prompted for permission on commands I've already approved many times before (e.g. kubectl, docker). The current permission prompt only offers "Yes" (one-time), "Yes, allow for this session", and "No" — there's no way to permanently allow a command from the prompt itself.

The only way to stop being asked is to manually edit ~/.claude/settings.json and add the pattern to permissions.allow, which requires knowing the exact syntax and interrupting your workflow to go edit a config file.

This is especially painful when running agentic workflows, where a single unapproved command halts the entire agent loop waiting for human input.

Proposed Solution

Add a fourth option to the permission prompt:

Yes
Yes, allow for this session
Yes, always allow "___" for Claude Code
No

Selecting "Yes, always allow" would:

  1. Approve the command immediately
  2. Append a pattern (e.g. "Bash(kubectl *)") to permissions.allow in ~/.claude/settings.json
  3. Never prompt for that command again in any session

The generated pattern should use the binary/command name with a wildcard (e.g. Bash(kubectl *)) rather than the exact command string, matching how users typically configure allowlists.

Alternative Solutions

While waiting for a native "Allow always" option in the permission prompt, I set up a hook-based workaround that achieves something similar:

  1. A PostToolUse hook on Bash runs after every command and checks if it matches any pattern in the global allowlist (~/.claude/settings.json). If not, it logs the binary name to a temp file.
  2. A Stop hook fires at the end of each session, reads the temp file, and outputs a message that Claude sees — prompting it to ask the user if they'd like any of those commands added to their global allowlist permanently (e.g. "Bash(kubectl *)" added to permissions.allow).

This effectively gives you a deferred "allow always" flow: you approve commands normally during the session, then at the end you get a batch prompt to make any of them permanent. It's not as seamless as a fourth button in the permission prompt would be, but it eliminates the problem of repeatedly approving the same commands across sessions.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

I'm running Cypress e2e tests against an ephemeral Kubernetes backend. Claude needs to run kubectl commands to find pods and read logs. Every new session, I get prompted to approve kubectl again. With "Yes, always allow", I'd approve it once and never be interrupted for it again — across any project.

Additional Context

No response

Activity

  1. github-actions commented on Mar 10, 2026

    @github-actions

    Found 3 possible duplicate issues:

    1. Feature Request: Add 'Allow always (save to settings)' permission option #18699
    2. [FEATURE] Save to global permissions' option in permission prompts #22014
    3. Feature: Persistent permission preferences across sessions #22292

    This issue will be automatically closed as a duplicate in 3 days.

    • If your issue is a duplicate, please close it and 👍 the existing issue instead
    • To prevent auto-closure, add a comment or 👎 this comment

    🤖 Generated with Claude Code

  2. github-actions commented on Mar 14, 2026

    @github-actions

    This issue has been automatically closed as a duplicate of #18699.

    If this is incorrect, please re-open this issue or create a new one.

    🤖 Generated with Claude Code

  3. github-actions commented on Mar 22, 2026

    @github-actions

    This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

  4. locked as resolved and limited conversation to collaborators on Mar 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    duplicateThis issue or pull request already exists

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions