[FEATURE] Options for more restrictive tool permission grants in TUI

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

Refiling because #9294 was closed, without comment, and without a way for me to reopen it:

Just because I granted access to run a tool once in a TUI session, doesn't mean I want all possible tool commands permitted indefinitely in the session. Maybe just exactly the one I said yes to, and maybe just for that prompt. There seems to be a lack of controls within the session and a lack of controls to make granted permissions transient or narrow.

Proposed Solution

I'd like to be able to put claude code into a mode where it needs to explicitly obtain clearance to run a command with different parameters. In other words, just because I approved tool abc for the session, claude should not then be able to run tool xyz without approval, which it appears to be able to do. Finally, just because I want claude to be able to run the tool without confirmation for my current request, I may not want it to be able to run those again for the next task without re-obtaining confirmation.

I'd suggest adding these two options to the tool use dialog. What I currently get looks like:

│   ide - getDiagnostics(uri: "file:///some/path/file.cpp") (MCP) 
│   Get language diagnostics from Emacs 
│  
│ Do you want to proceed?                                                                                                                                                  │
│ ❯ 1. Yes
│   2. Yes, and don't ask again for ide - getDiagnostics commands in /some/path
│   3. No, and tell Claude what to do differently (esc) 

What I'd like to see would be:

│   ide - getDiagnostics(uri: "file:///some/path/file.cpp") (MCP) 
│   Get language diagnostics from Emacs 
│  
│ Do you want to proceed?                                                                                                                                                  │
│ ❯ 1. Yes
│   2. Yes, and don't ask again for ide - getDiagnostics commands in /some/path in this session
|   3. Yes, and don't ask again for ide - getDiagnostics command for /some/path/file.cpp in this session
│   4. Yes, and don't ask again for ide - getDiagnostics commands in /some/path for this prompt
|   5. Yes, and don't ask again for ide - getDiagnostics command for /some/path/file.cpp for this prompt
│   6. No, and tell Claude what to do differently (esc) 

Alternative Solutions

I don't really have one. Once tool use is granted, it appears to persist for all possible invocations of that tool in the session. As a result, I frequently do not grant permission and need to manually approve each tool usage after I've reviewed the actual content.

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

I'd use this all the time. Claude often wants to run commands of some reasonable form with a given tool, which I'd be happy to enable without confirmation. However, sometime later in the session it gets a little off track, and decides to run a command with that same tool that is contrary to what I want, and I don't get an opportunity to course correct.

Additional Context

_No response_