[FEATURE] Suggested "always allow" permission patterns are often too narrow to prevent repeat prompts
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
Claude Code's permission dialog offers "Yes, allow X for this project" to
generalize a command into a reusable allow-list rule. When the command
contains something session-specific - a temp file path with a session/run
ID, a process ID, a timestamp-based filename - the suggested rule includes
that specific detail verbatim, so it matches only that one command and
never anything again.
Over about 2 days of active use on one project (with database queries,
local dev-server checks, and file inspection commands), this produced
roughly 80 allow-list entries, the large majority of which were single-use
and never matched a second time. Each slightly different but functionally
identical command triggered a fresh prompt. The user in this case is not a
developer and can't evaluate a shown shell command's safety - so every
avoidable repeat prompt is pure friction with no real safety benefit, and
it ties them to the computer far more than necessary.
Proposed Solution
When suggesting a generalized allow-list pattern, detect path segments
that look session/run-specific (something shaped like a UUID, a bare
integer that looks like a PID, a timestamp) and wildcard those out
automatically, instead of only offering "this exact command" vs. "the
exact command up to the last flag."
As a complementary option: a /permissions cleanup (or similar) command
that lists allow-list entries which have never matched a second command,
so a user can review and replace them with a broader pattern instead of
the list growing indefinitely with dead entries.
Alternative Solutions
Currently working around this by manually rewriting .claude/settings.json
by hand - reviewing the accumulated allow-list, identifying which entries
are dead (session-specific, will never match again), and replacing them
with hand-written wildcard patterns. This requires understanding which
parts of a command are safe to generalize, which isn't something a
non-technical user can do themselves - so it falls entirely on figuring
this out command-by-command as prompts recur.
Priority
High - Significant impact on productivity
Feature Category
Configuration and settings
Use Case Example
Example scenario:
- I'm working in Claude Code on a project with a local SQLite database,
asking read-only questions about it across several separate chat
sessions over a couple of days.
- Each session writes a slightly different but equally safe command to
query the database (different working-directory prefix, different
quoting, a scratch-file path containing that session's own ID).
- I click "Yes, allow X for this project" each time, expecting this to
stop the prompts for this kind of question going forward.
- It doesn't - because each suggested rule only matches the one exact
command it was generated from. Dozens of clicks accumulate over the
two days without meaningfully reducing future prompts, because none of
the saved patterns generalize to the next command.
Additional Context
Related, smaller documentation gap noticed during the same investigation:
a wildcard (*) in an allow-list pattern does not match across
command-chaining tokens (&&, ;, |, or a newline) - i.e. a command that
chains two otherwise-individually-allowed statements together still
prompts. This is very likely intentional (an allowed prefix's wildcard
shouldn't be exploitable to smuggle an unrelated chained command past
approval), but it isn't documented anywhere discoverable, and the
resulting prompt gives no hint that chaining is the reason - a user can
spend a lot of time trying path/quoting variants before realizing the
actual cause is unrelated command chaining. A one-line hint in the dialog
when this is detected would help.
Observed via the Claude Code VS Code extension, but the underlying
mechanism this report is about (how .claude/settings.json allow-list
rules are generated and matched) is part of Claude Code's shared core,
not VS Code-specific - this likely affects the CLI and other editor
integrations equally.