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

Resolved 💬 3 comments Opened Mar 10, 2026 by ZacharyBys Closed Mar 14, 2026

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

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_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗