Model re-attempts denied tool call after user explicitly says 'no'

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/21073
2. https://github.com/anthropics/claude-code/issues/31927
3. https://github.com/anthropics/claude-code/issues/29351

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

A PreToolUse hook can track denied tools and block subsequent retries:

INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name // empty')
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // .tool_input.file_path // empty' 2>/dev/null | head -c 100)
SIG="${TOOL}:${CMD}"
HASH=$(echo "$SIG" | md5sum | cut -d' ' -f1)
DENIED_FILE="/tmp/cc-denied-$HASH"
if [ -f "$DENIED_FILE" ]; then
    AGE=$(( $(date +%s) - $(stat -c %Y "$DENIED_FILE" 2>/dev/null || echo 0) ))
    if [ $AGE -lt 300 ]; then  # Within 5 minutes
        echo "BLOCKED: This action was denied by the user. Do not retry." >&2
        exit 2
    else
        rm -f "$DENIED_FILE"
    fi
fi
exit 0

When a tool is denied, the PermissionRequest hook marks it:

INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name // empty')
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // .tool_input.file_path // empty' 2>/dev/null | head -c 100)
SIG="${TOOL}:${CMD}"
HASH=$(echo "$SIG" | md5sum | cut -d' ' -f1)
touch "/tmp/cc-prompted-$HASH"
exit 0

A simpler approach using UserPromptSubmit:

PROMPT=$(cat | jq -r '.userPrompt // empty' 2>/dev/null)
if echo "$PROMPT" | grep -qiE '^(no|deny|reject|don.t|stop)'; then
    jq -n '{"hookSpecificOutput":{"hookEventName":"UserPromptSubmit","additionalContext":"The user just denied your action. Do NOT retry the same or equivalent action. Ask what they want instead."}}'
fi
exit 0

Additional Example: Git Commit Denial → Assumes Success → Attempts Invalid Revert

This issue also manifests in a different pattern: Claude not only retries denied actions but assumes they succeeded and attempts to "undo" actions that never happened.

What Happened:

Sequence:

1. Claude calls git commit -m "message with Claude attribution"
2. User denies the tool use: "don't give attribution to claude"
3. Tool result clearly shows: "The user doesn't want to proceed with this tool use"
4. Claude's response: Immediately attempts git reset HEAD~1 to "undo" the commit
5. Result: Error - no commit exists to reset (file was only staged, never committed)

Expected Behavior:

After tool denial, Claude should:

• Recognize the action was blocked (not completed)
• Check actual state (git status) before proceeding
• Adjust the plan based on the denial feedback

Actual Behavior:

• Claude assumed the commit succeeded despite explicit denial
• Proceeded with "cleanup" logic for non-existent state
• Caused cascading errors

Impact:

This isn't just about retrying the same action - it's about losing track of what actually happened. The model continues executing a planned sequence as if denied actions completed successfully.

Workaround:

Added user memory requiring state verification before any git revert:

# Always check state first
git log --oneline -1
git status
# Only then proceed with revert if commit exists

This pattern likely affects any multi-step workflow where a denied tool call should trigger plan revision rather than continuation.

Environment:

• Model: claude-sonnet-4-5
• Tool: Bash (git commands)
• Platform: macOS, Claude Code CLI

Related to the retry loop issue, but distinct in that Claude proceeds with downstream actions rather than retrying the same action.

---

Question for maintainers: Should this be filed as a separate issue? While related to the "retry after denial" problem, this variant is about assuming denied actions succeeded and proceeding with downstream logic rather than retrying the same action. Let me know if you'd prefer a separate issue for tracking.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This is an open issue, not fixed.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.