[BUG] updatedInput PreToolUse response does not work when multiple PreToolUse hooks are executed

[werdnum]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

I have been trying to set up a PreToolUse hook to modify bash commands (add timeout, rewrite known bad patterns) but no matter how hard I try, I can't get it to work.

See #9185, #4368

What Should Happen?

Updated Input should be respected

Error Messages/Logs

Claude's diagnosis:

Bug Report: updatedInput ignored in PreToolUse hooks

Environment

• Claude Code version: 2.0.76
• Platform: Linux (devcontainer)

Summary

PreToolUse hooks that return permissionDecision: "allow" with updatedInput have the updatedInput field completely ignored. The original tool input is executed instead of the modified input.

Blocking (exit code 2) works correctly. Only updatedInput with allow is broken.

Hook Script Output (correct)

When run manually:

$ echo '{"tool_name": "Bash", "tool_input": {"command": "echo foo"}}' | python3 /path/to/hook.py

stdout:

{
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
"permissionDecision": "allow",
"permissionDecisionReason": "Rewriting command: 'echo foo' → 'echo bar'\n Reason: TEST rule",
"updatedInput": {
"command": "echo bar"
}
}
}

The hook script exits with code 0 and outputs valid JSON with updatedInput.

Claude Code Streaming Output (shows bug)

$ echo "run: echo foo" | claude -p --debug hooks --output-format stream-json --verbose 2>&1

Tool call from Claude:

{"type":"assistant","message":{"content":[{"type":"tool_use","id":"toolu_01...","name":"Bash","input":{"command":"echo foo","description":"Print 'foo' to stdout"}}]}}

Tool result (shows original command ran, not modified):

{"type":"user","message":{"content":[{"tool_use_id":"toolu_01...","type":"tool_result","content":"foo","is_error":false}]},"tool_use_result":{"stdout":"foo","stderr":"","interrupted":false,"isImage":false}}

• Expected: "stdout":"bar" (modified command should run)
• Actual: "stdout":"foo" (original command ran, updatedInput ignored)

Blocking Mode Works (for comparison)

When hook returns exit code 2 with stderr message instead of JSON with allow:

{"type":"user","message":{"content":[{"type":"tool_result","content":"Hook PreToolUse:Bash denied this tool","is_error":true,"tool_use_id":"toolu_01..."}]},"tool_use_result":"Error: Hook PreToolUse:Bash denied this tool"}

This correctly blocks the tool and Claude sees the error. So hooks ARE running, just updatedInput is ignored.

Minimal Reproduction

1. Create hook script that returns updatedInput:

#!/usr/bin/env python3
import json, sys
input_data = json.load(sys.stdin)
if input_data.get("tool_name") == "Bash":
cmd = input_data.get("tool_input", {}).get("command", "")
if cmd == "echo foo":
print(json.dumps({
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
"permissionDecision": "allow",
"updatedInput": {"command": "echo bar"}
}
}))
sys.exit(0)
sys.exit(0)

2. Configure in settings.json:

{
"hooks": {
"PreToolUse": [{
"matcher": "Bash",
"hooks": [{"type": "command", "command": "python3 /path/to/hook.py"}]
}]
}
}

3. Run: echo "run: echo foo" | claude -p

4. Expected: Output shows "bar"

5. Actual: Output shows "foo"

Related Issues

• #4368 - Feature request (closed as completed in v2.0.10)
• #9185 - Documentation issue noting feature exists but undocumented
• #11113 - TypeError crash with updatedInput on Grep tool

hook script that returns updatedInput:

#!/usr/bin/env python3
import json, sys
input_data = json.load(sys.stdin)
if input_data.get("tool_name") == "Bash":
cmd = input_data.get("tool_input", {}).get("command", "")
if cmd == "echo foo":
print(json.dumps({
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
"permissionDecision": "allow",
"updatedInput": {"command": "echo bar"}
}
}))
sys.exit(0)
sys.exit(0)

2. Configure in settings.json:

{
"hooks": {
"PreToolUse": [{
"matcher": "Bash",
"hooks": [{"type": "command", "command": "python3 /path/to/hook.py"}]
}]
}
}

3. Run: echo "run: echo foo" | claude -p

4. Expected: Output shows "bar"

5. Actual: Output shows "foo"

Related Issues

• #4368 - Feature request (closed as completed in v2.0.10)
• #9185 - Documentation issue noting feature exists but undocumented
• #11113 - TypeError crash with updatedInput on Grep tool

Steps to Reproduce

1. Create hook script that returns updatedInput:

#!/usr/bin/env python3
import json, sys
input_data = json.load(sys.stdin)
if input_data.get("tool_name") == "Bash":
    cmd = input_data.get("tool_input", {}).get("command", "")
    if cmd == "echo foo":
        print(json.dumps({
            "hookSpecificOutput": {
                "hookEventName": "PreToolUse",
                "permissionDecision": "allow",
                "updatedInput": {"command": "echo bar"}
            }
        }))
        sys.exit(0)
sys.exit(0)

2. Configure in settings.json:

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{"type": "command", "command": "python3 /path/to/hook.py"}]
    }]
  }
}

3. Run: echo "run: echo foo" | claude -p

4. Expected: Output shows "bar"

5. Actual: Output shows "foo"

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.0.76

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

No response

[github-actions]

---

Found 3 possible duplicate issues:

1. [BUG] PreToolUse hook unable to both modify the tool inputs AND request user consent #11282
2. Bug Report: PreToolUse Hooks Strip Result Data from AskUserQuestion Tool #12031
3. PreToolUse hook causes AskUserQuestion tool to return empty responses #13439

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

[werdnum]

I had Claude do some reverse engineering. It seems like the problem occurs when there are multiple hooks for the same tool.

Claude's analysis

Bug Analysis: updatedInput ignored in PreToolUse hooks

Environment

• Claude Code version: 2.0.76
• Platform: Linux (aarch64, devcontainer)

Summary

PreToolUse hooks that return permissionDecision: "allow" with updatedInput have the updatedInput field ignored when multiple hooks are registered for the same tool. The original tool input is executed instead of the modified input.

Root Cause

Found via code archaeology in /home/claude/.npm-global/lib/node_modules/@anthropic-ai/claude-code/cli.js:

The bug is in the hook result aggregation logic in the ms function. When multiple hooks run:

1. permissionBehavior (allow/deny/ask) is correctly aggregated across hooks using a tracking variable E
2. BUT updatedInput is NOT aggregated - each hook's yield uses only its own z.updatedInput
3. The consuming code (Gu5) overwrites z with each hookPermissionResult: case"hookPermissionResult":z=j.hookPermissionResult;break;
4. The LAST hook's result wins, even if it has updatedInput: undefined

The Buggy Code Pattern

// E correctly aggregates permissionBehavior across hooks
if(z.permissionBehavior)switch(z.permissionBehavior){
  case"deny":E="deny";break;
  case"ask":if(E!=="deny")E="ask";break;
  case"allow":if(!E)E="allow";break;
  case"passthrough":break
}

// BUG: This yields after EVERY hook when E is set
// It uses the CURRENT hook's z.updatedInput, not an aggregated value
if(E!==void 0)yield{
  permissionBehavior:E,
  hookPermissionDecisionReason:z.hookPermissionDecisionReason,
  updatedInput:z.updatedInput&&z.permissionBehavior==="allow"?z.updatedInput:void 0
};

What Happens With Multiple Hooks

Example: User hook + bash-guard plugin (2 hooks for "Bash" tool)

1. Hook 1 (user's hook): Returns {permissionDecision: "allow", updatedInput: {command: "echo bar"}}

   • E is set to "allow"
   • Yields: {permissionBehavior:"allow", updatedInput:{command:"echo bar"}}
   • In Gu5: z = {behavior:"allow", updatedInput:{command:"echo bar"}}

2. Hook 2 (bash-guard): Returns nothing (exit 0, no JSON = passthrough)

   • z.permissionBehavior is undefined
   • E stays "allow" (already set from hook 1)
   • Since E !== void 0, it yields AGAIN:
     {permissionBehavior:"allow", updatedInput:undefined} (because z.updatedInput for THIS hook is undefined)
   • In Gu5: z = {behavior:"allow", updatedInput:undefined} - OVERWRITES HOOK 1's RESULT

3. Result: Tool executes with original input, updatedInput is lost

Reproduction

Minimal Hook Script (Node.js)

#!/usr/bin/env node
const Fs = require("node:fs");

async function main() {
  const chunks = [];
  for await (const chunk of process.stdin) chunks.push(chunk);
  const json = JSON.parse(Buffer.concat(chunks).toString("utf8"));

  Fs.appendFileSync("/tmp/debug.log", `input: ${JSON.stringify(json)}\n`);

  if (json.tool_name === "Bash" && json.tool_input?.command === "echo foo") {
    const res = JSON.stringify({
      hookSpecificOutput: {
        permissionDecision: "allow",
        updatedInput: { command: "echo bar" }
      }
    });
    Fs.appendFileSync("/tmp/debug.log", `out: ${res}\n`);
    process.stdout.write(res);
    process.exit(0);
  }
  process.exit(0);
}

main().catch((e) => { console.error(e); process.exit(2); });

Configuration

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{"type": "command", "command": "node /path/to/hook.js"}]
    }]
  }
}

Test Command

echo 'run: echo foo' | claude -p --output-format stream-json --verbose

Debug Log Shows Hook Works Correctly

input: {"tool_name":"Bash","tool_input":{"command":"echo foo",...}}
out: {"hookSpecificOutput":{"permissionDecision":"allow","updatedInput":{"command":"echo bar"}}}

But Stream Output Shows Original Command Ran

{"tool_use_result":{"stdout":"foo","stderr":"","interrupted":false}}

Expected: "stdout":"bar"

Why It Works For Some People

The bug only manifests when multiple hooks are registered for the same tool matcher. If you have:

• Only ONE PreToolUse hook for "Bash" → Works correctly
• Multiple hooks (user hook + plugin hooks) → Last hook's result wins

Most users testing updatedInput probably don't have plugins with PreToolUse hooks installed, so their single hook works fine.

Proposed Fix

Track updatedInput across hooks similar to how permissionBehavior is tracked:

let E;  // existing
let aggregatedUpdatedInput;  // NEW

// In the loop over hooks:
if(z.updatedInput && z.permissionBehavior === "allow") {
  aggregatedUpdatedInput = {...aggregatedUpdatedInput, ...z.updatedInput};
}

// When yielding:
if(E !== void 0) yield {
  permissionBehavior: E,
  hookPermissionDecisionReason: z.hookPermissionDecisionReason,
  updatedInput: aggregatedUpdatedInput  // Use aggregated value
};

Related Issues

• #4368 - Feature added in v2.0.10 (claimed completed)
• #9185 - Documentation missing
• #11113 - TypeError with updatedInput on Grep tool
• #11282 - Can't use updatedInput with permissionDecision "ask"
• #15897 - Initial bug report for this issue

Workaround

Until fixed, users can:

1. Disable all plugins that register PreToolUse hooks for the same tool
2. Use the "block and suggest" pattern instead (exit code 2 with stderr message)

[coygeek]

Independent Confirmation + Additional Findings

I can confirm this bug on Claude Code 2.0.76 (macOS, Anthropic OAuth).

Test Setup

I created isolated tests with minimal hooks to verify the behavior:

Hook 1 (modifier): Returns updatedInput: {command: "echo MODIFIED"} when it sees echo ORIGINAL
Hook 2 (passthrough): Returns empty {}

Results

Config Order	Result	Notes
Modifier only	MODIFIED	Single hook works correctly
[modifier, passthrough]	MODIFIED	Modifier FIRST → works
[passthrough, modifier]	ORIGINAL	Modifier SECOND → broken

Key Finding: Position-Dependent, Not "Last Wins"

The bug behavior is more nuanced than "last hook overwrites." My testing shows:

• Modifier in position 1 → updatedInput is preserved
• Modifier in position 2+ → updatedInput is silently discarded

This means even a passthrough hook that returns {} (and doesn't touch updatedInput) will break subsequent hooks that DO return updatedInput.

Real-World Impact

I have 12 PreToolUse hooks on the Bash matcher. Three of them use updatedInput to:

• Inject -y flags for package managers (non-interactive mode)
• Inject -v flags for file operations (verbose output)
• Split chained git commands

These hooks are at positions 3-5, with passthrough hooks at positions 1-2. Based on my testing, all three have been silently broken this entire time—commands execute as originally written despite the hooks outputting correct updatedInput responses.

Workaround

Move all updatedInput hooks to the beginning of the chain (position 1, 2, 3...). Passthrough hooks should come after.

Limitation: Only the FIRST updatedInput hook that fires will have its modification applied. Multiple updatedInput modifications cannot compose.

Logs Confirming Hook Execution

My hooks log their input/output to files. The modifier hook IS being called and IS returning correct JSON:

INPUT: {"tool_name": "Bash", "tool_input": {"command": "echo ORIGINAL"}, ...}
OUTPUT: {"hookSpecificOutput": {"hookEventName": "PreToolUse", "permissionDecision": "allow", "updatedInput": {"command": "echo MODIFIED"}}}

Yet the executed command is echo ORIGINAL. The updatedInput is being discarded somewhere in the aggregation logic.

---

Environment:

• Claude Code: 2.0.76
• Platform: macOS (Darwin 25.1.0)
• Auth: Anthropic OAuth