[BUG] Permission prompt offers no-op "always allow directory" option when real blocker is an unlisted Bash command

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

When a Bash command (e.g. rm) is not in the allow list, the permission prompt appears as expected. However, the "always allow" option offered is "Yes, and always allow access to <directory> from this project" — even when that directory is already listed in additionalDirectories. Accepting this option writes a duplicate/redundant directory entry and does not add the command to the allow list, so the prompt reappears on every future invocation of that command.

What Should Happen?

When the directory is already in additionalDirectories, the prompt should not offer a directory-access option as the resolution. The "always allow" option should instead offer to add the specific command pattern to the allow list (e.g. Bash(rm *)), since that is the actual missing permission.

Steps to Reproduce

1. Add a directory to additionalDirectories in settings.json, e.g. "../myproject" (resolves to a sibling of the project root).
2. Run a Bash command targeting a file in that directory that has no matching allow rule, e.g.:

``
rm /home/user/projects/myproject/some-file.md
``

1. Observe the permission prompt. The middle option reads "Yes, and always allow access to myproject\ from this project".
2. Accept it. The directory is added again (duplicate), but rm still prompts on the next run.

Is this a regression?

Don't know

Claude Code Version

2.1.92 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal