preToolUse hook drops line range parameters (offset/limit) on ReadFile tool calls (v3.2.18)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

In Cursor v3.2.18, the preToolUse hook drops line range parameters (offset and limit) from the payload when the agent uses the ReadFile tool. The hook receives only the path, while all range-related fields (offset, limit, start_line, end_line, etc.) are passed as null. This prevents custom hooks from intercepting targeted file reads correctly, forcing them to treat every request as a full-file read.

Steps to Reproduce

Configure a preToolUse command hook in Cursor settings.

Open the Agent and prompt it to read a specific line range of a file (e.g., “Read lines 880 to 890 of file.ts”).

The Agent successfully calls the tool with arguments like: ReadFile({ path: “/path/to/file.ts”, offset: 880, limit: 11 }).

Check the raw payload passed to the preToolUse hook script.

Observe that the payload stripped the data and sent “offset”: null and “limit”: null.

Expected Behavior

The preToolUse hook payload should preserve and include the exact offset and limit (or startLine/endLine) parameters that the Agent generated for the tool call.

Operating System

MacOS

Version Information

3.2.18

Additional Information

This payload stripping issue appears heavily related to another major bug where the postToolUse hook runs asynchronously and discards injected context (Forum thread: Native postToolUse hooks accept and log additional_context successfully, but the injected context is not surfaced to the model - #11 by Andy_Lockey). It seems the entire serialization/data pipeline between the Agent, Tools, and the Hook runner is currently losing data in v3.2.18.

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the report, and extra thanks for digging into the payload offset/limit to null. I reproduced it and can confirm the bug: preToolUse for ReadFile really only passes file_path, and offset and limit get lost along the way, even though the agent sends them correctly to the tool.

I filed this internally as a separate issue. I can’t share an ETA yet, but the fix is pretty targeted, so I’m hoping it’ll land in one of the next releases. When there’s an update, we’ll reply in this thread.

Also, about your note on the general pattern with postToolUse additional_context, thread 155689 Native postToolUse hooks accept and log additional_context successfully, but the injected context is not surfaced to the model, it’s a different issue but it does look like the same class of problem, data gaps in the hooks pipeline. We’re tracking both.

8

Awesome, thanks for the quick repro and for filing it internally, @deanrie! Glad to hear the fix is targeted and relatively straightforward. I’ll keep an eye out for the upcoming releases. Appreciate the transparency and support!