When using NextJS Routing: Dynamic Routes | Next.js paths the ripgrep subprocess takes 100% CPU for that opened project, and it does not fix itself when closing and reopening the editor, essentially, in a nextjs project I am stuck with having my CPU 100% all the time, making all my machine slow and essentially voiding any performance from my 200$ subscription…
Extra observations:
Usually when the issue starts the rg.exe processes are direct children of cursor.exe
After some time the rg.exe processes seems to be killed by cursor for a sec, the CPU usage normalizes and then they immedieately pop up again but not a direct children of cursor.exe BUT spawned by cursor.
If this would not be fixed ASAP and properly, I am being dead honest, I am unsubscribing from Cursor, once and for all, I had enough.
Leaving this overnight eventually cleans off any rg.exe processes and by morning editor seems OK, up until a file is opened. This action of opening a file spawns that rg.exe processes again, with 100% usage and it stays like that for hours, for that one single opened file.
Steps to Reproduce
N/A Use claude to write reproduceable scenarios, I am paying 200$ for what? Hire a ■■■■■■■ QA
Expected Behavior
rg.exe should not eat up all my potato CPU and should have exponential backoff when it runs for too long with non-archive conversations actively not needing it.
Hey there!
What you’re describing isn’t intended behavior, and it’s not something in your setup. We’ve let the team know and this is an issue we’re tracking.
While that’s being looked at, a couple of settings should tame the CPU right away.
1. Cap ripgrep’s threads. In your settings.json:
"search.ripgrep.maxThreads": 1
By default each search process uses every core, so a few of them running at once peg the CPU. This is the single biggest lever (you can bump it to 2 if search feels slow).
2. Keep heavy folders out of search and indexing. Also in settings.json:
This is all workarounds, wake me up when you have a solution patched in a certain version for me to test, please. Thank you zery much. Because even if it’s one single core doing the job, still, it occupies that core to it’s limit.
The setting that actually ends it is "search.followSymlinks": false, plus excluding node_modules and .next in search.exclude. If you’re on pnpm or a symlinked node_modules, that’s usually what turns a continuous run into an instant one. Are you on pnpm?
On a real fix: this isn’t intended behavior and it’s an issue we’re tracking. No version or timeline yet, but I’ll post here as soon as there’s a build for you to test.
