[FEATURE] Parse an affirmative in free-text permission replies instead of always treating them as a denial

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

Summary

At a tool-use permission prompt, replying with free text (instead of selecting the explicit "Yes"/approve option) is always treated as a denial, and the typed text is forwarded to the model as the rejection reason — even when the text unambiguously affirms (e.g. "yes, go ahead", "yes, but also do X afterward"). The action is silently blocked and must be re-issued.

Current behavior

1. A permission prompt appears for a tool call.
2. The user types a natural reply such as "Yes, but I'd hoped not to be prompted for a read."
3. This is routed to the "No — tell Claude what to do differently" path: the tool does not run; the model receives "user doesn't want to proceed" plus the text.
4. Net effect: the user thinks they approved (they said "yes"), but the action was denied and the model must call the tool again — re-prompting.

Why it's surprising

"Yes, but …" reads to a human as approval with a note. Nothing signals that entering text == reject. Over a long session this creates a confusing loop where the user keeps "approving" and nothing executes.

Proposed Solution

Parse the reply for a clear, unambiguous yes/no; if affirmative, approve and still pass the remaining text to the model as a note — fall back to today's reject-with-feedback only when intent is ambiguous.

Alternative Solutions

1. Add an explicit "Approve with comment" option so leaving a note doesn't force a denial.
2. At minimum, make the UI clearly indicate that a free-text reply will reject the action.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

<img width="809" height="636" alt="Image" src="https://github.com/user-attachments/assets/a0aaa91a-eb45-4ef4-97ed-e29e0941a2ab" />

Additional Context

Surfaced in a long session where several "Yes, but …" replies to read-only command prompts were each recorded as denials, stalling progress until the commands were re-issued or added to the allow-list.