[FEATURE] Context-Aware Tool Approval in PreToolUse Hooks

Resolved 💬 3 comments Opened Dec 28, 2025 by dlepold Closed Feb 14, 2026

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

When using MCP tools (like Chrome DevTools MCP) that have both read-only and potentially destructive actions, I want to auto-approve safe actions while still requiring confirmation for risky ones.

Current limitation: PreToolUse hooks only receive TOOL_NAME and TOOL_INPUT - they cannot access the conversation context to understand why a tool is being called.

Example scenario:

  • ✅ "Click the search button to find candidates" → Safe, should auto-approve
  • - ⚠️ "Click the delete button" → Risky, should require confirmation

Both are mcp__chrome-devtools__click calls, but have very different risk levels based on context. Current hooks cannot distinguish between them because they lack conversation context and Claude's intent assessment.

Proposed Solution

Pass additional context to PreToolUse hooks:

$TOOL_NAME        # "mcp__chrome-devtools__click"
$TOOL_INPUT       # {"uid": "1_194"}
$TOOL_CONTEXT     # "User asked to search for tutors. Clicking search button."
$TOOL_RISK_LEVEL  # "low" | "medium" | "high" (Claude's self-assessment)

Hook example:

#!/bin/bash
# Auto-approve low-risk actions
if [[ "$TOOL_RISK_LEVEL" == "low" ]]; then
  exit 0  # approve
fi
exit 1  # show normal prompt

This enables context-aware approval without requiring an external AI - Claude already knows the intent and can assess risk.

Alternative Solutions

Current workaround: Manually approve every click and navigate action, even when they're clearly safe based on the conversation context. This works but significantly slows down workflows that involve browser automation.

Alternative considered: Using a local LLM in the hook to analyze tool calls - but this would require setting up additional infrastructure and wouldn't have access to the conversation context anyway.

Why built-in is better: Claude already knows the intent and context. Exposing this assessment to hooks is more efficient than recreating the reasoning externally.

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

Scenario: Testing a tutoring marketplace website with Chrome DevTools MCP

  1. User: "Search for English tutors in Berlin on my website"
  2. 2. Claude navigates to the search page → navigate_page (low risk)
  3. 3. Claude fills the subject field with "English" → fill (low risk)
  4. 4. Claude fills the city field with "Berlin" → fill (low risk)
  5. 5. Claude clicks the search button → click (low risk - searching)
  6. 6. Claude takes a screenshot of results → take_screenshot (low risk)

With context-aware hooks:

  • Steps 2-6 could auto-approve because Claude knows the intent is "search for tutors"
  • - Risk level is LOW because these are read-only/search operations

But if the user said: "Delete this user account"

  • Claude clicking "Delete" button → click (HIGH risk - destructive)
  • - Hook receives $TOOL_RISK_LEVEL="high" → requires manual approval

Current behavior: All 6 clicks require manual approval, even though 5 of them are clearly safe based on context.

Additional Context

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗