Tool-approval annotation text is not applied to the in-flight tool call
Summary
When a permission prompt for a tool call is approved with additional annotation text (e.g. typing "yes, but use X instead of Y" in the approval box), that annotation does not affect the tool call it was attached to. The already-built tool call executes as originally proposed, and the annotation text only reaches the model as a separate, later user turn — after the call has already run.
Observed behavior
- Claude proposes a batch of tool calls (e.g. several file edits) using parameter/name choice A.
- The permission prompt appears for approval.
- The user approves but appends a correction, e.g. "yes, but use B instead of A."
- The tool calls execute using the original choice A (unchanged).
- The correction text arrives to the model afterward as a new message, requiring a second, separate round of edits to fix what already happened.
Expected behavior
If the approval UI accepts free-text annotations at the point of approval, that text should be able to influence/redirect the tool call before it executes (or the UI should make clear that annotations are not applied to the current call and only serve as a note for the next turn).
Why this matters
Users naturally treat the approval prompt as a checkpoint where they can course-correct before an action happens — that's the point of a confirmation step. If annotations are accepted there but not actually incorporated, it defeats the purpose of the checkpoint and creates redundant correction work.
Environment
- Claude Code CLI
- Reported via a user session while approving a batch of
Edittool calls