Skip to content

fix: deny of one tool call permanently blocks all future same-tool calls#1388

Closed
Oliver-ZPLiu wants to merge 1 commit into
Hmbown:mainfrom
Oliver-ZPLiu:fix-tool-deny-persists
Closed

fix: deny of one tool call permanently blocks all future same-tool calls#1388
Oliver-ZPLiu wants to merge 1 commit into
Hmbown:mainfrom
Oliver-ZPLiu:fix-tool-deny-persists

Conversation

@Oliver-ZPLiu

Copy link
Copy Markdown
Contributor

Summary

Fixes #1377 — denying a tool call (e.g. edit_file) once permanently auto-denies every subsequent invocation of the same tool type for the rest of the session.

Root cause

In handle_view_events, when a tool call is denied, both the tool_name (e.g. "edit_file") and the approval_key (per-call unique) were inserted into app.approval_session_denied. The tool_name entry caused all future calls to edit_file to be auto-denied without prompting.

Fix

Only store the approval_key on denial. The approval_key is per-call unique, which still prevents the model's retry loop from re-prompting the exact same command (#360), but allows fresh invocations of the same tool type to prompt the user for approval.

Files changed

File Change
crates/tui/src/tui/ui.rs Remove tool_name insertion into approval_session_denied

Test plan

  • cargo check -p deepseek-tui passes
  • cargo clippy -p deepseek-tui --all-targets --all-features --locked -- -D warnings passes
  • Code only changes denial path; approval path (ApprovedForSession) is unchanged

…lls (Hmbown#1377)

When a user denies a tool call (e.g. edit_file), the tool_name was
inserted into approval_session_denied alongside the per-call
approval_key. Every subsequent invocation of the same tool type was
then auto-denied for the rest of the session without prompting.

Fix: only store the approval_key (per-call unique). This still
prevents the model's retry loop from re-prompting the exact same
command (Hmbown#360), but allows the user to approve a fresh invocation of
the same tool type.
@Oliver-ZPLiu Oliver-ZPLiu changed the title fix: deny of one tool call permanently blocks all future same-tool calls (#1377) fix: deny of one tool call permanently blocks all future same-tool calls May 10, 2026

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates the tool denial logic in crates/tui/src/tui/ui.rs to ensure that only the unique approval_key is cached when a user denies or aborts a tool call. Previously, the code also cached the tool_name, which incorrectly blocked all future invocations of that tool type. I have no feedback to provide as there were no review comments to evaluate.

@Hmbown

Hmbown commented May 10, 2026

Copy link
Copy Markdown
Owner

Cherry-picked into work/v0.8.28 as d4a4892 — thanks @Oliver-ZPLiu!

CHANGELOG entry for v0.8.28:

Deny of one tool call no longer blocks all future calls of the same tool — denying a tool call now only caches the per-call approval_key, not the tool type. Subsequent invocations of the same tool prompt for approval again instead of being silently auto-denied.

This will auto-close when v0.8.28 lands on main.

@Hmbown

Hmbown commented May 11, 2026

Copy link
Copy Markdown
Owner

v0.8.28 is live — your work shipped:

Closing this PR. Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug in deny tool use

2 participants