[BUG] "Don't ask again for similar commands" saves verbatim command strings, so near-identical commands re-prompt every time

Status Open
Reported on v2.1.228
Maintainer reply None cached
Activity 1 comment · opened Aug 12, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Environment — Windows 11 (26100), "defaultMode": "acceptEdits" in project settings.

Summary — The dialog offers "Yes, and don't ask again for similar commands in <project-dir>". It does not create a rule matching similar commands; it appends the verbatim command string, absolute paths included, to permissions.allow. Any command differing by one argument re-prompts and appends another single-use entry. One session: ~20 prompts, ~20 rules, none of which ever matched again.

Repro — Approve node a.mjs <dir> via the "similar commands" option → run node b.mjs <dir> → prompted again → repeat for c, d, e → inspect settings.local.json.

Expected — A rule generalising over the executable (optionally + first arg). Or, if only exact matches are possible, a label that says "this exact command" so the option isn't clicked 20 times expecting accumulation.

Actual — Sanitised excerpt showing five entries for one script pattern and four curl entries against one localhost port differing only by a timeout flag. Also notes that piped/heredoc commands appear ungeneralisable and re-prompt unconditionally.

Secondary — 2: acceptEdits excludes Bash with no UI indication; in this session every single prompt was Bash, so the enabled mode was silently irrelevant to all of them. 3: Bash rules take command prefixes but not directory scopes, so "allow node, but only in thi— the only prompt-stopping rule is a machine-wide grant for that binary.

Suggested fixes — generalise the rule or relabel; surface that acceptEdits doesy scoping for Bash.

Impact — Approval fatigue with no accumulating benefit; the natural escape is -s, a materially worse posture than the correctly-scoped rule the model can'texpress.

What Should Happen?

A rule generalising over the executable (optionally + first arg). Or, if only exact matches are possible, a label that says "this exact command" so the option isn't clicked 20 times expecting accumulation.

Error Messages/Logs

Steps to Reproduce

Approve node a.mjs <dir> via the "similar commands" option → run node b.mjs <dir> → prompted again → repeat for c, d, e → inspect settings.local.json.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.228

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

When I asked for a fix explicitly refusing to run claude --dangerously-skip-permissions as this whole procedure feels like privilage extortion Opus 4.8 suggested i paste:

{
"permissions": {
"allow": [
"Bash(node:)", "Bash(npm:)", "Bash(git:*)",
"Bash(ls:)", "Bash(cat:)", "Bash(grep:)", "Bash(sed:)",
"Bash(curl:)", "Bash(python:)", "Bash(mkdir:*)",
"Read(//c/Users/<my_username>/)"
],
"deny": ["Read(.env)", "Read(./secrets/
)", "Bash(rm -rf:)", "Bash(git push:)"],
"defaultMode": "acceptEdits"
}
}

This feels extremely wrong - using Claude in VS terminal without allowing full access is impossible with 50+ conformation requests each prompt.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗