Feature request: user-selectable permission scopes in command prompts

Problem

Command permission prompts are currently too binary and monolithic.

The user can approve or reject the permission unit chosen by the system, but cannot choose the permission scope that best matches their intent.

This is not limited to commands composed with shell operators. It also applies to the arguments of a single command.

For example, if the requested command is:

rg --files -g '!node_modules/**'

the user may want to approve one of several different scopes:

• rg
• rg --files
• rg --files -g '!node_modules/**'
• this exact invocation only

The same applies to command sequences, pipelines, shell wrappers, environment variables, working directories, paths, and command-specific subcommands.

Today, the permission flow often forces a single system-selected unit. That unit may be too broad, too narrow, or simply the wrong abstraction for persistent permission.

Desired behavior

The permission UI should let the user choose the permission scope.

The selectable scopes should be structured permission units, not arbitrary substrings. They should reflect how the command will execute and how users naturally reason about command permissions.

Useful scope dimensions include:

• exact invocation;
• executable/program name;
• subcommand or action;
• selected flags and option values;
• positional arguments;
• file/path arguments;
• working directory;
• environment variables;
• shell wrapper, when present;
• command sequences such as cmd1; cmd2;
• conditional sequences such as cmd1 && cmd2 or cmd1 || cmd2;
• pipelines such as cmd1 | cmd2;
• redirection such as > or >>;
• one-time permission vs persistent permission.

The important part is that the human chooses the abstraction being authorized.

Examples

For:

rg --files -g '!node_modules/**'

possible scopes could include:

• rg
• rg --files
• rg --files -g '!node_modules/**'
• exact invocation

For:

git -c safe.directory=C:/projects/md2pdf diff --check

possible scopes could include:

• git
• git diff
• git diff --check
• git -c safe.directory=C:/projects/md2pdf diff --check
• exact invocation

For:

npm run build -- --mode production

possible scopes could include:

• npm
• npm run
• npm run build
• npm run build -- --mode production
• exact invocation

For:

rg foo . | sort > results.txt

possible scopes could include:

• rg foo .
• rg foo . | sort
• rg foo . | sort > results.txt
• exact invocation

For:

cd repo; npm test

possible scopes could include:

• cd repo
• cd repo; npm test
• exact invocation

For a shell-wrapped command:

bash -lc 'cmd1 && cmd2'

possible scopes could include:

• the shell wrapper invocation;
• the inner executable step;
• the inner composed sequence;
• exact invocation.

Safety model

The permission UI can show risk warnings for broader or riskier scopes, but warnings should not be hard blocks.

For example:

• approving only an executable name can warn that this is broader than approving a subcommand or exact argument set;
• approving a package-manager script can warn that the script body may change;
• approving a shell interpreter or shell-wrapped invocation can warn that this is a broad executable-code boundary;
• approving a multi-command sequence can warn that future matching commands may run multiple commands;
• approving redirection can warn about file writes;
• approving destructive commands can warn about file deletion risk;
• approving network/install commands can warn about supply-chain or download risk.

The user should still be able to explicitly approve after seeing the warning.

Useful risk levels could include:

• low risk: read-only commands like rg, git status, git diff;
• medium risk: build/test commands, generators, package scripts;
• high risk: shell interpreters, deletion, network install, privilege changes;
• critical risk: recursive delete, credential access, system configuration changes.

Rationale

The human operator often understands the intended permission boundary better than an automatic matcher.

The system does not need to perfectly parse every command and silently decide the right policy. It can expose useful candidate scopes and let the user choose.

Today, the permission flow is too coarse: approve the system-selected unit or reject it. This makes persistent permissions less useful and often encourages overly specific or overly broad rules.

Claude Code should let the human choose which command abstraction is being authorized, with proportional warnings and an explicit one-time vs persistent choice.