preToolUse hook fails with ENAMETOOLONG for large files

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Issue: preToolUse hook fails with ENAMETOOLONG for large files

When editing large files, the hook receives the entire file content
in tool_input.content, causing spawn to fail before the script executes.

Suggested fix:

  1. Write hook input to a temp file and pass the path instead
  2. Or add config option to exclude tool_input.content from hook payload
  3. Or stream the data via stdin instead of passing in spawn args/env

Steps to Reproduce

When editing large files, the hook receives the entire file content
in tool_input.content, causing spawn to fail before the script executes.

Expected Behavior

no ENAMETOOLONG

Operating System

Windows 10/11

Version Information

Version: 2.4.23 (user setup)
VSCode Version: 1.105.1
Commit: 379934e04d2b3290cf7aefa14560f942e4212920
Date: 2026-01-29T21:24:23.350Z
Build Type: Stable
Release Track: Early Access
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Windows_NT x64 10.0.19045

Does this stop you from using Cursor

No - Cursor works, but with this issue

3

Hey @_lonelywaitingliu!

Thanks for reporting this! Can you share the exact hook you’ve configured?

5

@Colin experiencing this as well, our hooks are node based so in the hooks.json we have:

"preToolUse": [
  {
    "command": "node <path_to_my_hook_file.js“,
    "type": "command"
  }
]

and the hook file itself has:

let inputData = '';

process.stdin.on('data', chunk => {
  inputData += chunk;
});

process.stdin.on('end', async () => {
 …hook logic
});
6

Thanks @Matan_OX! We’ve filed a bug for this.

7

When using cursor hooks on Windows platform, especially afterEdit hooks, when the input content is too large, it will cause error output to directly report execution error: spawn ENAMETOOLONG, resulting in the user’s callback program not executing and cannot take effectWhen using cursor hooks on Windows platform, especially afterEdit hooks, when the input content is too large, it will cause error output to directly report execution error: spawn ENAMETOOLONG, resulting in the user’s callback program not executing and cannot take effect

8

Is this problem solved? In which version? When is it expected to be resolved?

9

Hi Colin, thanks for the response, any chance of getting an ETA?

10

I don’t have an ETA to share yet, I’m sorry!

11

Hi,
Would like to follow up on the status for this one. It’s blocked us from using hooks in Cursor. Any ETA please?

12

啥时解决啊

13

cursor 3.0.16 still has this problem

14

I encountered this issue on both Linux (remote SSH) and Windows.

17

Hey @_lonelywaitingliu ,
The ENAMETOOLONG error when hooks receive large file payloads has been fixed, it will be included in a future stable update. If you’re on an early access track, updating to the latest version may already include the fix.

cc @Matan_OX @weixiang @Bar_Azouri @Knne_Villegas @cp_peck

20

Thanks for the update! It’s great to hear that the ENAMETOOLONG error is fixed.

I have a couple of questions regarding the release schedule:

  1. Is there a specific version number planned for this fix?

  2. Do you have an estimated timeline for when this will be merged into the official stable release?

Looking forward to it!

21

@weixiang - The fix is already available on the current stable release. Updating Cursor should resolve the issue: Ctrl+Shift+P > Attempt Update, then restart.

Let us know if the problem persists after updating.

22

When the file has more than 17,000 lines, this issue still occurs in Cursor(Version: 3.5.33,) on my Mac.

image
image1248×340 9.45 KB
@Colin @mohitjain

24

The error you’re seeing (spawn E2BIG) is actually a different error from the original ENAMETOOLONG that was fixed. The earlier fix resolved the issue on Windows, but on macOS, when the file content exceeds a certain size (which a 17,000+ line file would), the hook payload hits a different OS-level limit that the original fix didn’t cover.

This is a known issue that our team is actively working on. Unfortunately there’s no workaround at the moment since it’s a limitation in how the hook payload is delivered to the script on macOS/Linux.

We’ll update this thread once the fix ships.