[FEATURE] Allow settings.json to prompt

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

Summary
Currently, Bash command permissions in Claude Code operate as a binary: commands are either auto-approved or auto-denied. There is no middle ground that allows Claude to ask the user before proceeding for specific commands or patterns.
Problem
When Bash(*) is set to allow, all Bash commands are auto-approved. The only way to restrict specific commands (e.g. rm) is to add them to the deny list — which blocks them entirely rather than prompting for confirmation.
Conversely, if Bash(*) is removed from the allow list to re-enable default "ask" behaviour for a specific command, the user loses the convenience of auto-approval for all other commands and must manually enumerate every allowed pattern.
This creates an all-or-nothing tradeoff: either trust everything or lose blanket approval.

Proposed Solution

Desired Behaviour
A third permission level — prompt — that would cause Claude to pause and ask the user for explicit confirmation before executing matching commands, without blocking them outright.
Example configuration (conceptual):
json{
"permissions": {
"allow": ["Bash(*)"],
"deny": [],
"prompt": ["Bash(rm *)"]
}
}
With this setup:

Most Bash commands run automatically (via Bash(*) allow)
rm commands pause and ask the user: "I'm about to run rm -rf ./old_logs. Proceed?"
The user can confirm or cancel per-invocation

Use Cases

Destructive commands (rm, rmdir, truncate, dd) — confirm before data loss
Network requests (curl, wget, ssh) — confirm before external communication
Package installations (npm install, pip install) — confirm before modifying dependencies
Privilege escalation (sudo) — confirm before elevated execution

Why This Matters
Power users who grant broad Bash(*) approval still want a safety net for a small class of high-risk commands. The current binary permission model forces a choice between convenience and safety. A prompt tier resolves this tension cleanly.
Proposed Implementation Notes

prompt entries should be evaluated after allow and before deny in the permission resolution order, or alternatively prompt should take precedence over allow for matched patterns
The prompt should display the exact command to be run and ask for a yes/no confirmation in the chat interface
Optionally: support a "remember for this session" checkbox to avoid repeat prompts for the same pattern

Related Behaviour
This is consistent with how Claude already handles sensitive browser actions (e.g. form submissions, purchases) — pausing to confirm rather than auto-executing or hard-blocking.

Alternative Solutions

_No response_

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

_No response_