beforeTabFileRead is still inherently slow on Windows despite reported hook execution improvements

Support Bug Reports
, , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hi, I wanted to check the current status of this issue.

Original report:
https://forum.cursor.com/t/beforetabfileread-hook-is-extremely-slow-on-windows-and-events-get-queued-up-works-fine-on-macos/147211

Related thread mentioning improvements:
https://forum.cursor.com/t/hook-execution-reports-8-seconds-delay-despite-actual-execution-taking-only-5ms/147584/7

From the other thread, it sounds like there were some improvements to hook execution on Windows.

However, in my environment, beforeTabFileRead still feels noticeably slow.

So I wanted to ask:

  • Has this issue actually been fully patched?

  • If not, is there any timeline for when it might be improved?

Thanks!

Steps to Reproduce

hooks.json

{
“version”: 1,
“hooks”: {
“beforeTabFileRead”: [
{
“command”: “cmd /c echo ‘{“actions”:}’”
}
]
}
}
trigger auto complete

Operating System

Windows 10/11

Version Information

Version: 2.6.19 (system setup)
VSCode Version: 1.105.1
Commit: 224838f96445be37e3db643a163a817c15b36060
Date: 2026-03-12T04:07:27.435Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.19045

Does this stop you from using Cursor

No - Cursor works, but with this issue

4

Hey, thanks for the report.

Short answer, this isn’t fully solved. The improvements Colin mentioned, NaiveTerminalExecutor in 2.4, helped for low frequency hooks like beforeSubmitPrompt. Latency dropped from 7 to 9 s to about 0,8 s. But for beforeTabFileRead that’s not enough, because it fires on every cursor move and autocomplete. Even 0,8 s per call builds up into a backlog.

The core issue is the same. Each hook call spawns a new process on Windows, and for high frequency hooks this is an architecture limit. It needs deeper changes like debouncing, canceling stale calls, or a process pool.

I’ve shared this with the team again.

For now the workaround is the same. If beforeTabFileRead isn’t critical, it’s better to keep only Agent hooks like beforeShellExecution, afterFileEdit, etc. They fire less often and don’t cause these delays.