Claude Code updatedInput Hooks: 2.1.300 Change Tested

Claude Code 2.1.300 changed how it treats updatedInput, the field a PreToolUse hook uses to rewrite a tool call. The changelog says it "is now validated like Claude's own input: unknown keys are dropped, and input the tool rejects denies the call".¹

I ran the same hooks on 2.1.299 and 2.1.300, and the main cases again on 2.1.306, to see what changed in practice. Part of it did change. Part of what that sentence suggests was already true on 2.1.299.

What You'll Learn

• What updatedInput does and where it goes in the hook's JSON
• How I tested it, and on which builds
• Which behaviors changed in 2.1.300 and which did not
• A rewrite hook that works on all three builds
• A short checklist for hooks that rewrite tool calls

What updatedInput does

The hooks reference puts it in one line: updatedInput "directly under hookSpecificOutput replaces a tool's arguments before it runs."²

The word that matters is replaces. A February 2026 GitHub issue was filed because the reporter found it "replaces the entire tool_input object" instead of merging.³ My test agrees with that reading. A Write rewrite with file_path but no content was denied on every build.

Placement trips people up too. A September 2026 write-up by mer.vin tested 2.1.282 and found that an updatedInput placed at the top level of the JSON, next to hookSpecificOutput, was ignored.⁴ I checked that with a Bash call on three builds and got the same result, covered below.

For related hook behavior, see our tests of onFailure block and the Claude Code mods guide.

How I tested it

I installed each build from npm into its own folder: 2.1.299, 2.1.300 and 2.1.306. The two older builds were published on October 14, 2026, and 2.1.306 on October 21, 2026, when its latest tag pointed at it.⁵

The first batch (valid rewrite, wrong types, empty object, timeout and run_in_background) ran on October 15, 2026 from the same npm installs of 2.1.299 and 2.1.300. The Read empty-object check also ran on October 15, in a second early batch. Every other run I report here was on October 21, 2026, on Linux x86_64 with Node.js 22.22.0.

Each run was a real claude -p call with the model claude-sonnet-5-5. I passed --settings pointing at a test file, --setting-sources "" to keep other config out, --max-turns 4, and --allowedTools set to the tool under test (Read and Edit together for the Edit cases).

That flag pre-approves tools but does not remove the others, so the model sometimes called Bash too. The prompt asked for one plain action: touch a marker file for Bash, read one small file, write one, or read a file and then edit it.

Each test had a PreToolUse hook that returned the updatedInput under test. In most runs a PostToolUse hook also wrote the tool_input it received to a log, so I could see what the tool really got.

That covers the unknown-key, relative-path and top-level cases, and the Edit cases where the call went through. A refused call never reaches the tool, so it has no PostToolUse entry.

The first batch (valid rewrite, wrong types, empty object, timeout, run_in_background) and the redirect hook runs had no such log. For those, and for every refused call, I checked marker files, the resulting file and the tool_result text in the stream. Where the table says 3 runs, all three agreed.

Results at a glance

Each row groups related hook return values. The columns show what happened on 2.1.299 and 2.1.300, built from the raw run output. The table below splits the cases out and gives run counts.

Where I ran 2.1.306, it matched 2.1.300 in every case. That covers unknown keys on all four tools, the relative path, all three Edit refusals, the Read offset, the top-level placement and both redirect hooks.

Unknown keys: kept on 2.1.299, dropped on 2.1.300

This is the change the changelog describes, and I could see it.

On 2.1.299 the PostToolUse log for the Bash case held bogus_key and another. On 2.1.300 and 2.1.306 it held only command. Read, Write and Edit behaved the same way, on 2.1.306 as well.

In none of my cases did the extra key change what the tool did. The tools ignored it. For these four tools, a hook can no longer pass unknown keys into the tool call.

Our read: for a hook that builds its output from a template or from model-visible text, this is a small safety win. It does not replace checking the fields you do set.

The Edit case showed a second effect. On 2.1.300 and 2.1.306 the logged input also carried replace_all: false. On 2.1.299 that field was absent. I did not test whether that default explains the double-match result below.

Rejected rewrites: schema errors on both, Edit refusals on 2.1.300

The changelog says input the tool rejects "denies the call". For schema errors that was already true.

On 2.1.299, a rewrite that gave command a number, left command out, passed timeout as a string or passed description as a number came back as an error starting "PreToolUse hook for Bash returned updatedInput that failed schema validation". Nothing ran.

2.1.300 keeps that message and adds a sentence: "The tool input from the model was valid; the hook's rewrite of it was not." It tells Claude, and you, which side to fix.

The Edit cases are where behavior moved. These are errors the Edit tool raises about content, not the schema.

The tool_result text for an Edit rewrite whose old_string is not in the file, on 2.1.300.

With an old_string that is not in the file, 2.1.299 returned the Edit tool's own error, "String not found in file. Failed to apply edit." With identical old and new strings it returned the same message, which does not describe the real problem.

2.1.300 refused both and said the PreToolUse hook's rewrite was the cause. One error read "No changes to make: old_string and new_string are exactly the same." Each one ended with the same sentence blaming the rewrite. In these two cases the file was unchanged in every run on every build.

The third Edit case has real consequences. I put alpha beta beta in the file and asked Claude to replace alpha with gamma, which is a valid call. The hook rewrote it to replace beta with gamma and left replace_all unset. beta appears twice.

On 2.1.299 the Edit tool applied it. The result said the file "has been updated successfully", and the file read alpha gamma beta in all three runs. On 2.1.300 and 2.1.306 the rewrite was refused with "Found 2 matches of the string to replace, but replace_all is false." The file stayed alpha beta beta in all six runs.

One more observation, with a small sample. In the not-in-file and identical-string cases, all six runs on 2.1.299 hit my four-turn cap. Each held four tool calls: Read, the failing Edit, a second Read and a Bash command such as od -c on the file. On 2.1.300 all six runs finished, with two or three tool calls, and in three of them the model simply retried Edit.

That depends on the model, and four is a ceiling I set. An earlier batch used a prompt that made the model's own first Edit fail, and in that batch both builds mostly hit the cap, so I reran these cases. Treat the counts as a hint and not a measurement.

Paths: relative becomes absolute

I returned relative_w.txt as the Write file_path. On 2.1.299 the tool received it as written and the file landed in the working directory. On 2.1.300 and 2.1.306 the tool received the absolute path of the same location.

The practical effect is on logs and audit hooks. In my test, a PostToolUse hook saw the absolute path on 2.1.300 and 2.1.306 and the relative path on 2.1.299. Resolve paths against the cwd field of the hook input before you compare them. I did not test a relative path that came from the model, and I got no usable result for a relative path on other tools.

What did not change

These outcomes were the same on each build I ran them on.

A Bash timeout of -5 slipped through. It ran on 2.1.299 and 2.1.300, and the command was killed straight away with exit code 143. A run_in_background of the string "yes" ran too.

offset: -3 on Read was denied on all three builds, and the error quotes a minimum of 0 from Read's schema. So in this case the minimum came from Read's schema on every build. The only difference between builds was the usual extra sentence on 2.1.300 and 2.1.306.

Top-level placement is still ignored. I returned updatedInput as a sibling of hookSpecificOutput for a Bash call. The original command ran in all nine runs. With a debug file, each run logged "Hook JSON output had unrecognized keys (ignored): updatedInput."

A rewrite hook that works on all three builds

This hook sends every Write into a .claude-out folder under the working directory. It copies the whole input first, because the rewrite replaces it.

#!/usr/bin/env node
// PreToolUse hook for the Write tool: send every write into ./.claude-out/
const fs = require("fs");
const path = require("path");

const event = JSON.parse(fs.readFileSync(0, "utf8"));
const input = event.tool_input;

const target = path.join(event.cwd, ".claude-out", path.basename(input.file_path));

console.log(JSON.stringify({
  hookSpecificOutput: {
    hookEventName: "PreToolUse",
    permissionDecision: "allow",
    // updatedInput replaces the whole input, so copy every field first
    updatedInput: { ...input, file_path: target },
  },
}));

The hook returns permissionDecision: "allow". I only ran it headless with the tool pre-approved, and I did not test ask or interactive mode, so choose the decision that fits your setup. Register it in your settings file:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write",
        "hooks": [
          { "type": "command", "command": "node /path/to/redirect-writes.js", "timeout": 10 }
        ]
      }
    ]
  }
}

I asked Claude to write notes.txt in a folder outside the project, with the content "original". On 2.1.299, 2.1.300 and 2.1.306, in 3 runs each, the file appeared as .claude-out/notes.txt with the right content, and nothing was written at the original path.

The same script with { file_path: target } as the whole updatedInput was denied in all nine runs, with "The required parameter content is missing".

A checklist for rewriting hooks

1. Copy tool_input and change only the fields you mean to change.
2. Put updatedInput inside hookSpecificOutput, never beside it.
3. Test one rewrite per tool you match, with a PostToolUse hook logging tool_input, so you see what the tool received.
4. Do not rely on validation for values such as timeouts. On 2.1.299 it also did not stop a rewrite that matched the file twice. Check numbers, paths and strings in the hook.
5. Pin the Claude Code version in CI. The changelog sections I read for 2.1.301 to 2.1.306 do not mention updatedInput, but the 2.1.300 change shows the behavior can move.⁶
6. Decide what should happen when the hook itself breaks. The onFailure tests cover that for command and HTTP hooks.

What I did not test

I did not test updatedInput on PermissionRequest hooks, where it sits inside a decision object.² I did not test MCP tools, subagents, Windows, interactive mode, ask or defer decisions, async hooks, plugin hooks or managed settings.

I also tested only Bash, Read, Write and Edit. Other tools may normalize or reject input in their own ways.

Two hooks returning different updatedInput for the same call is untested as well. The docs excerpt I read did not state a precedence rule.

For the human-approval side of agent tool calls, see our human-in-the-loop guide.

Bottom Line

On the builds I ran, updatedInput behaves as the docs say: it replaces the input. The 2.1.300 change shows up as dropped unknown keys, a normalized Write path and refusals for Edit rewrites that 2.1.299 either failed with a generic error or, in one case, applied.

Schema-level denial was already there on 2.1.299, so the new sentence in the error is a small part of the change.

Copy the full input, nest the field under hookSpecificOutput, and log what the tool receives. Then test one bad rewrite per tool on the build you ship.

References