Feature Request: Enhance `PreToolUse` Hooks to Modify Tool Inputs

Title: Feature Request: Enhance PreToolUse Hooks to Modify Tool Inputs

Labels: enhancement, feature-request, hooks, tools, developer-experience, security

Overview

The Claude Code hooks system, particularly the PreToolUse hook, provides a powerful way to intercept and validate tool calls before they are executed. As detailed in the Hooks Reference, a hook can currently block a tool call and provide feedback to the model, but it cannot directly modify the tool's input parameters.

This feature request proposes an enhancement to allow PreToolUse hooks to transform tool inputs in-place, making the system more efficient, reliable, and secure.

The Problem: The Inefficient "Block-and-Correct" Cycle

Currently, when a PreToolUse hook identifies a tool call that needs correction (e.g., for safety, performance, or policy compliance), its only recourse is to block the call and provide corrective feedback to Claude. This forces an inefficient and costly multi-turn conversational cycle:

1. Claude: Proposes a tool call (e.g., Bash("grep ...")).
2. Hook: Blocks the call (using exit code 2 or JSON {"decision": "block"}) and provides feedback via stderr (e.g., "Use rg instead of grep for performance.").
3. Claude: Must parse the natural language feedback and generate a new, corrected tool call in a subsequent turn.

This cycle increases latency, raises token costs, and relies on the LLM to reliably interpret and apply what is often a simple, deterministic correction.

Proposed Solution

Enhance the advanced JSON output for PreToolUse hooks to support an optional updatedInput field.

When a PreToolUse hook returns a JSON object with decision: "approve" and an updatedInput field, the Claude Code runtime will execute the tool using the modified input from this field instead of the original input proposed by the model.

This pattern already has a precedent within the Claude Code SDK's permission-prompt-tool, making this a consistent and logical extension of existing functionality.

Example

Imagine Claude proposes to run a destructive command: Bash("rm -rf /path/to/some/dir").

A security-focused PreToolUse hook could intercept this and return the following JSON to stdout:

{
  "decision": "approve",
  "reason": "Command modified for safety: replaced '-rf' with interactive flag.",
  "updatedInput": {
    "command": "rm -i /path/to/some/dir"
  }
}

Result: The Claude Code runtime would then execute the safer rm -i command directly, skipping the inefficient conversational turn and guaranteeing the safer version is run.

Benefits

• Reduced Latency: Eliminates the need for an extra LLM turn to correct the tool call.
• Lower Costs: Saves on token usage by avoiding the "block-and-correct" cycle.
• Improved Reliability: Deterministically enforces policies and corrections, removing the possibility of the LLM misinterpreting the feedback.
• Enhanced Security: Allows security-conscious hooks to transparently sanitize or modify commands to enforce safer practices without halting the agent's workflow.

Conclusion

This enhancement would transform the PreToolUse hook from a simple validation gate into a powerful, transformative middleware. It would allow developers to build safer, more efficient, and more reliable automations by decoupling deterministic input correction from the probabilistic LLM. This is a critical step for deploying Claude Code in complex, automated, and enterprise-grade environments