Cursor 88-99% cpu

Em_Strange · September 27, 2026, 12:16pm

un-usable start app and immediately high cpu , a full fresh clean install and still same .

Where does the bug appear (feature/product)?

Something else… : the LAB

Describe the Bug
A clear and concise description of what the bug is.: bug eating up entire system cpu !!!

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

… reproduced over 7 times, first with the app image , and also with yay / aur cursor-bin
…
…

Expected Behavior
What is meant to happen here that isn’t working correctly? not suppose to move cpu above 5% extra max on highest use .

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

Linux

Version Information
❯ cursor --version
3.22.7
37076c6c3f9e253c0fa2305197e45befd13a2260
x64

Does this stop you from using Cursor?

Yes - Cursor is unusable 100%

system · September 27, 2026, 12:16pm

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
Terminal & commands
Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)
MCP & tools
Cloud Agents & Automations (cursor.com/agents, scheduled/event)
BugBot & Code Review
Cursor CLI
Cursor Mobile
Remote (SSH / Dev Containers / WSL)
Account, billing & login
Something else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

…
…
…

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

Windows 10/11
MacOS
Linux

Version Information

For Cursor IDE: Menu → About Cursor → Copy
For Cursor CLI: Run agent about in your terminal

IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

Yes - Cursor is unusable
Sometimes - I can sometimes use Cursor
No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

Em_Strange · September 27, 2026, 12:43pm

have been able to get it down significantly , by this , but its exceeding what it should be taking

cat > ~/.config/Cursor/User/settings.json << ‘EOF’
{
“search.followSymlinks”: false,
“search.ripgrep.maxThreads”: 1,
“search.exclude”: {
“**/node_modules”: true,
“**/.git”: true,
“**/dist”: true,
“**/build”: true,
“**/.next”: true
},
“files.watcherExclude”: {
“**/node_modules/**”: true,
“**/.git/objects/**”: true,
“**/dist/**”: true,
“**/build/**”: true,
“**/.next/**”: true
}
}
EOF

Also add them to search.exclude in your settings (for the search panel):

"search.exclude": {
  "**/node_modules": true,
  "**/.git": true,
  "**/dist": true,
  "**/build": true,
  "**/.next": true,
  "**/.venv": true,
  "**/.local": true,
  "**/.fingerprint": true,
  "**/index.crates.io-*": true,
  "**/.cache": true,
  "**/target": true
}

now my cpu% is at 14 , so something else still wrong, because normally my cpu% never goes above 7 for days running cursor ! so now thats double !

deanrie · September 28, 2026, 12:30pm

Hey, thanks for the screenshots, they clearly show where the CPU is going.

The busy rg --files ... processes mean Cursor is scanning all files in the folder it opens on startup, including anything linked in via symlinks. Reinstalling doesn’t help because settings live in ~/.config/Cursor, and Cursor reopens the same folder, so the scan starts again. This usually happens when a very large folder is open, like your home ~, or when it contains a symlink to a large tree.

Why your workaround didn’t fix everything: search.followSymlinks: false doesn’t affect the .cursorignore scan, it has its own toggle. Turn it on here: Cursor Settings > Indexing > “Ignore Symlinks in Cursor Ignore Search”. That’s the walk that’s eating 1100%+ in your screenshots.

To see what’s actually being scanned, run this while CPU is high and share the output:

for p in $(pgrep -x rg); do readlink /proc/$p/cwd; done

A couple quick checks:

Fully quit Cursor, then start it with a temporary clean profile: cursor --user-data-dir /tmp/cursor-clean. Wait a minute. Is CPU normal?
In that window, go to File > Open Folder and open a specific project folder, not your home folder. Does CPU stay normal?

Quick fix: open the project directly with cursor ~/projects/myapp instead of opening your home folder. If you really need to keep a large folder open, enable the toggle above and add heavy folders you don’t need into .ignore at the root of that folder.

Let me know what the command output and the checks show, that will decide what to look at next.

Em_Strange · September 28, 2026, 3:56pm

❯ ps -o pid,pcpu,pmem,etime,comm -p $(pgrep -f "electron.*--type=utility" | tr '\n' ',' | sed 's/,$//')

PID %CPU %MEM     ELAPSED COMMAND

16345 0.0 0.0 06:12:11 electron

16384 0.0 0.1 06:12:11 electron

16455 1.1 0.2 06:12:10 electron

16471 0.0 0.1 06:12:10 electron

16520 9.7 8.6 06:12:10 electron

16549 0.0 0.0 06:12:10 electron

16614 0.0 0.0 06:12:09 electron

16825 0.0 0.0 06:12:08 electron

16852 0.0 0.0 06:12:08 electron

20661 0.0 0.0 06:11:18 electron

1914869 0.5 0.1 23:10 electron

1914914 0.5 0.1 23:09 electron

1914915 0.6 0.1 23:09 electron

1914916 34.6 4.3 23:09 electron

1914980 1.0 0.0 23:09 electron

this is absolutely un-usable , spiking cpu everytime , have been able to get it to maintaining 15% when only Lab , once i open the IDE it spikes again to 34% of cpu . its doing nothing , am not even running a agent , and yet its maintaining these numbers . yes its scanning my project , have done everything i can to make it stop , turn of indexing etc , and changes nothing !

Em_Strange · September 28, 2026, 4:16pm

❯ for p in $(pgrep -x rg); do readlink /proc/$p/cwd; done

/home/en0ch/Projects/coconut

Fully quit Cursor, then start it with a temporary clean profile: cursor --user-data-dir /tmp/cursor-clean. Wait a minute. Is CPU normal? changed nothing , after about 5 mins , multiple /usr/bin/rg , and multiple /usr/lib/electron42 , spiking cpu again !!

deanrie · September 28, 2026, 5:47pm

Thanks, the command output makes everything clear. Both rg walks are running on /home/en0ch/Projects/coconut, so the scan is happening inside that project folder (not across home, which is the usual case). Since a clean profile didn’t help, it’s not a settings issue. It’s something inside the coconut folder itself. Most often it’s a symlink that points into a huge directory tree (like node_modules, caches, target, etc.). The walk runs with --follow, so it follows the link and ends up scanning a massive amount of files.

A few things that can confirm this and reduce the load:

The toggle I mentioned is NOT search.followSymlinks. The .cursorignore scan has its own setting. Turn on this one instead: Cursor Settings > Indexing > Ignore Symlinks in Cursor Ignore Search. Your search.followSymlinks: false does not affect this walk, so that’s why it kept using CPU.
Check whether the project has symlinks and where they point:

find /home/en0ch/Projects/coconut -maxdepth 4 -type l -exec ls -la {} \;

If you see a link into a large directory, that’s the cause.

Add a .ignore file to the root of coconut with heavy folders. This walk respects it:

node_modules
.git
dist
build
target
.next
.cache
.venv

After steps 1 and 3, restart Cursor and check rg again. Please share the output from step 2 and the approximate project size from du -sh /home/en0ch/Projects/coconut. That’ll show whether it’s a symlink issue or the project is just too large, and what to look at next.

Em_Strange · September 28, 2026, 6:32pm

everything you listed here “The toggle I mentioned is NOT search.followSymlinks. The .cursorignore scan has its own setting. Turn on this one instead: Cursor Settings > Indexing > Ignore Symlinks in Cursor Ignore Search. Your search.followSymlinks: false does not affect this walk, so that’s why it kept using CPU.” , i had already done !! and go no change , likewise do i have a the .ignore .cursorignore etc . making no changes , high cpu and ram !! its becoming completly unusable , and have been using cursor for year + now , can’t have this high cpu and ram , when nothing is running , just opening the app and bunch of rg and electron take over the entire cpu at 100%

Em_Strange · September 28, 2026, 10:05pm

i think i stumbled on a fix , so far holding at 6-7% cpu and droping to 3-4 when not in use .

DIR=/usr/share/cursor/resources/app/node_modules/
/ripgrep/bin
sudo mv "$DIR/rg" "$DIR/rg.orig"

sudo tee "$DIR/rg" << 'EOF'
#!/bin/bash
args=()
for arg in "$@"; do
[[ "$arg" == "--follow" ]] && continue
[[ "$arg" == "--no-ignore" ]] && continue
args+=("$arg")
done
exec "$(dirname "$0")/rg.orig" "${args[@]}"
EOF

sudo chmod +x "$DIR/rg"

for the rg spawns . and seems to solve the cpu side, the ram still a bit much like extra 3gb ram , i can spare that on my system but maybe other might not be able to. ill see if a restart fixes the ram side issue .

to find all the rg , " find ~/.cursor-server /usr/share/cursor /opt/cursor -name “rg” -type f 2>/dev/null "

also i updated my settings.json

{
  "search.followSymlinks": false,
  "search.ripgrep.maxThreads": 1,
  "search.exclude": {
    "**/__pycache__": true,
    "**/.cache": true,
    "**/.fingerprint": true,
    "**/.git": true,
    "**/.local": true,
    "**/.next": true,
    "**/.venv": true,
    "**/build": true,
    "**/coverage": true,
    "**/dist": true,
    "**/index.crates.io-*": true,
    "**/node_modules": true,
    "**/target": true
  },
  "files.watcherExclude": {
    "**/node_modules/**": true,
    "**/.git/objects/**": true,
    "**/dist/**": true,
    "**/build/**": true,
    "**/.next/**": true,
    "**/.venv/**": true,
    "**/.local/**": true,
    "**/.fingerprint/**": true,
    "**/index.crates.io-*": true,
    "**/.cache/**": true,
    "**/target/**": true
  },
  "cursor.general.gitGraphIndexing": "disabled",
  "cursor.general.contextSize": "small",
  "cursor.general.enableShadowWorkspace": false,
  "cursor.cpp.disabledLanguages": ["plaintext", "markdown", "scminput", "yaml"]
}

and its currently running and just 6% cpu , reboot fixes ram too !

deanrie · September 29, 2026, 4:40am

Hey, nice catch. Your logic is right, and it makes sense why it behaved that way.

On startup, Cursor runs a few separate rg --files passes. The toggle Cursor Settings > Indexing > Ignore Symlinks in Cursor Ignore Search only affects scanning .cursorignore. But there’s another pass for discovering rules, skills, and AGENTS.md that follows symlinks no matter what that toggle is set to. That’s why flipping one toggle didn’t remove the load, while stripping --follow at the binary level hit all passes at once. This is a known issue, and I shared your details with the team. I can’t give an ETA yet.

A couple important notes about your workaround: replacing the bundled rg will get overwritten on every Cursor update, and it requires sudo for the system install, so it’s more of a temporary stopgap than a permanent fix. After each update, you’ll need to apply it again.

There’s a more stable way to get the same result without changing internal files. From what I can tell, the real trigger is a symlink inside coconut that points into a large tree like node_modules, cache, target, and so on, and --follow pulls the scan in there. If you can find and remove or move that link, CPU usage should drop without patching the binary.

Please share the output of:

find /home/en0ch/Projects/coconut -maxdepth 4 -type l -exec ls -la {} \;
du -sh /home/en0ch/Projects/coconut

If we see a link into a huge directory, that’s the root cause, and we can fix it cleanly from there. Let me know what it shows.

Em_Strange · September 29, 2026, 7:47am

❯ find /home/en0ch/Projects/coconut -maxdepth 4 -type l -exec ls -la {} \;
lrwxrwxrwx 1 en0ch en0ch 25 Sep 16 08:38 /home/en0ch/Projects/coconut/Look/node_modules/.bin/rollup -> ../rollup/dist/bin/rollup
lrwxrwxrwx 1 en0ch en0ch 19 Sep 16 08:38 /home/en0ch/Projects/coconut/Look/node_modules/.bin/json5 -> ../json5/lib/cli.js
lrwxrwxrwx 1 en0ch en0ch 21 Sep 16 08:38 /home/en0ch/Projects/coconut/Look/node_modules/.bin/tsc -> ../typescript/bin/tsc
lrwxrwxrwx 1 en0ch en0ch 32 Sep 16 08:38 /home/en0ch/Projects/coconut/Look/node_modules/.bin/update-browserslist-db -> ../update-browserslist-db/cli.js
lrwxrwxrwx 1 en0ch en0ch 27 Sep 16 08:38 /home/en0ch/Projects/coconut/Look/node_modules/.bin/tauri -> ../@tauri-apps/cli/tauri.js
lrwxrwxrwx 1 en0ch en0ch 26 Sep 16 08:38 /home/en0ch/Projects/coconut/Look/node_modules/.bin/tsserver -> ../typescript/bin/tsserver
lrwxrwxrwx 1 en0ch en0ch 23 Sep 16 08:38 /home/en0ch/Projects/coconut/Look/node_modules/.bin/marked -> ../marked/bin/marked.js
lrwxrwxrwx 1 en0ch en0ch 22 Sep 16 08:38 /home/en0ch/Projects/coconut/Look/node_modules/.bin/browserslist -> ../browserslist/cli.js
lrwxrwxrwx 1 en0ch en0ch 19 Sep 16 08:38 /home/en0ch/Projects/coconut/Look/node_modules/.bin/vite -> ../vite/bin/vite.js
lrwxrwxrwx 1 en0ch en0ch 24 Sep 16 08:38 /home/en0ch/Projects/coconut/Look/node_modules/.bin/nanoid -> ../nanoid/bin/nanoid.cjs
lrwxrwxrwx 1 en0ch en0ch 40 Sep 16 08:38 /home/en0ch/Projects/coconut/Look/node_modules/.bin/baseline-browser-mapping -> ../baseline-browser-mapping/dist/cli.cjs
lrwxrwxrwx 1 en0ch en0ch 18 Sep 16 08:38 /home/en0ch/Projects/coconut/Look/node_modules/.bin/jsesc -> ../jsesc/bin/jsesc
lrwxrwxrwx 1 en0ch en0ch 22 Sep 16 08:38 /home/en0ch/Projects/coconut/Look/node_modules/.bin/esbuild -> ../esbuild/bin/esbuild
lrwxrwxrwx 1 en0ch en0ch 36 Sep 16 08:38 /home/en0ch/Projects/coconut/Look/node_modules/.bin/parser -> ../@babel/parser/bin/babel-parser.js
lrwxrwxrwx 1 en0ch en0ch 23 Sep 16 08:38 /home/en0ch/Projects/coconut/Look/node_modules/.bin/semver -> ../semver/bin/semver.js
lrwxrwxrwx 1 en0ch en0ch 9 Sep 16 08:38 /home/en0ch/Projects/coconut/vendor/istari-plus-brain/node_modules/hermes-tui -> ../ui-tui
lrwxrwxrwx 1 en0ch en0ch 79 Sep 23 07:58 /home/en0ch/Projects/coconut/.venv/bin/python -> /home/en0ch/.local/share/uv/python/cpython-3.12-linux-x86_64-gnu/bin/python3.12
lrwxrwxrwx 1 en0ch en0ch 6 Sep 23 07:58 /home/en0ch/Projects/coconut/.venv/bin/python3 -> python
lrwxrwxrwx 1 en0ch en0ch 6 Sep 23 07:58 /home/en0ch/Projects/coconut/.venv/bin/python3.12 -> python
lrwxrwxrwx 1 en0ch en0ch 3 Sep 23 07:58 /home/en0ch/Projects/coconut/.venv/lib64 -> lib
lrwxrwxrwx 1 en0ch en0ch 25 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/json2dsv -> ../d3-dsv/bin/json2dsv.js
lrwxrwxrwx 1 en0ch en0ch 24 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/dsv2dsv -> ../d3-dsv/bin/dsv2dsv.js
lrwxrwxrwx 1 en0ch en0ch 25 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/rollup -> ../rollup/dist/bin/rollup
lrwxrwxrwx 1 en0ch en0ch 20 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/cssesc -> ../cssesc/bin/cssesc
lrwxrwxrwx 1 en0ch en0ch 19 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/json5 -> ../json5/lib/cli.js
lrwxrwxrwx 1 en0ch en0ch 25 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/json2tsv -> ../d3-dsv/bin/json2dsv.js
lrwxrwxrwx 1 en0ch en0ch 21 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/tsc -> ../typescript/bin/tsc
lrwxrwxrwx 1 en0ch en0ch 24 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/tsv2csv -> ../d3-dsv/bin/dsv2dsv.js
lrwxrwxrwx 1 en0ch en0ch 25 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/dsv2json -> ../d3-dsv/bin/dsv2json.js
lrwxrwxrwx 1 en0ch en0ch 29 Sep 24 18:32 /home/en0ch/Projects/coconut/lab/node_modules/.bin/why-is-node-running -> ../why-is-node-running/cli.js
lrwxrwxrwx 1 en0ch en0ch 32 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/update-browserslist-db -> ../update-browserslist-db/cli.js
lrwxrwxrwx 1 en0ch en0ch 27 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/tauri -> ../@tauri-apps/cli/tauri.js
lrwxrwxrwx 1 en0ch en0ch 26 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/tsserver -> ../typescript/bin/tsserver
lrwxrwxrwx 1 en0ch en0ch 22 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/loose-envify -> ../loose-envify/cli.js
lrwxrwxrwx 1 en0ch en0ch 15 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/katex -> ../katex/cli.js
lrwxrwxrwx 1 en0ch en0ch 23 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/marked -> ../marked/bin/marked.js
lrwxrwxrwx 1 en0ch en0ch 26 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/uuid -> ../uuid/dist-node/bin/uuid
lrwxrwxrwx 1 en0ch en0ch 19 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/vite -> ../vite/bin/vite.js
lrwxrwxrwx 1 en0ch en0ch 24 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/csv2tsv -> ../d3-dsv/bin/dsv2dsv.js
lrwxrwxrwx 1 en0ch en0ch 25 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/tsv2json -> ../d3-dsv/bin/dsv2json.js
lrwxrwxrwx 1 en0ch en0ch 25 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/csv2json -> ../d3-dsv/bin/dsv2json.js
lrwxrwxrwx 1 en0ch en0ch 24 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/nanoid -> ../nanoid/bin/nanoid.cjs
lrwxrwxrwx 1 en0ch en0ch 20 Sep 24 18:32 /home/en0ch/Projects/coconut/lab/node_modules/.bin/vitest -> ../vitest/vitest.mjs
lrwxrwxrwx 1 en0ch en0ch 40 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/baseline-browser-mapping -> ../baseline-browser-mapping/dist/cli.cjs
lrwxrwxrwx 1 en0ch en0ch 26 Sep 24 18:32 /home/en0ch/Projects/coconut/lab/node_modules/.bin/vite-node -> ../vite-node/vite-node.mjs
lrwxrwxrwx 1 en0ch en0ch 18 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/jsesc -> ../jsesc/bin/jsesc
lrwxrwxrwx 1 en0ch en0ch 22 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/esbuild -> ../esbuild/bin/esbuild
lrwxrwxrwx 1 en0ch en0ch 25 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/json2csv -> ../d3-dsv/bin/json2dsv.js
lrwxrwxrwx 1 en0ch en0ch 36 Sep 16 08:38 /home/en0ch/Projects/coconut/lab/node_modules/.bin/parser -> ../@babel/parser/bin/babel-parser.js
lrwxrwxrwx 1 en0ch en0ch 23 Sep 16 08:38 /home/en0ch/Projects//lab/node_modules/.bin/semver -> ../semver/bin/semver.js

❯ du -sh /home/en0ch/Projects/coconut
du: cannot read directory '/home/en0ch/Projects/coconut/.local/share/containers/storage/overlay/9966efe98ee5a25487b5a5b7927b3f742691ff0328aef7c21ed06b584765d998/work/work': Permission denied
du: cannot read directory '/home/en0ch/Projects/coconut/.local/share/containers/storage/overlay/c25b1e1c0135413d4f562edd77b89a329f4281b5eaf3dc9961af679677464557/work/work': Permission denied
du: cannot read directory '/home/en0ch/Projects/coconut/.local/share/containers/storage/overlay/a4969e791177e382ed644e19624f39748cea6ad0671bbb24435081414cc9e3a9/work/work': Permission denied
du: cannot read directory '/home/en0ch/Projects/coconut/.local/share/containers/storage/overlay/c559da49eb4b0739547c58ce2e08d81daea04d2448f18a5f3ca7852b7843714d/work/work': Permission denied
du: cannot read directory '/home/en0ch/Projects/coconut/.local/share/containers/storage/overlay/c559da49eb4b0739547c58ce2e08d81daea04d2448f18a5f3ca7852b7843714d/diff/var/cache/apt/archives/partial': Permission denied
du: cannot read directory '/home/en0ch/Projects/coconut/.local/share/containers/storage/overlay/c559da49eb4b0739547c58ce2e08d81daea04d2448f18a5f3ca7852b7843714d/diff/var/lib/apt/lists/partial': Permission denied
du: cannot read directory '/home/en0ch/Projects/coconut/.local/share/containers/storage/overlay/54d1413c225a5413de0baa93edf13e0a48cf51765b22681594d29e9b8687632d/work/work': Permission denied
du: cannot read directory '/home/en0ch/Projects/coconut/.local/share/containers/storage/overlay/ea16cace89338c84eb6bcb91a7efdfcae6838fff359efe951858227436486c34/diff/var/cache/apt/archives/partial': Permission denied
du: cannot read directory '/home/en0ch/Projects/coconut/.local/share/containers/storage/overlay/d96b9d2481a9697a4b3fe276062fdd5540fdbcadeea5df9ea41121287421bb40/work/work': Permission denied
du: cannot read directory '/home/en0ch/Projects/coconut/.local/share/containers/storage/overlay/d96b9d2481a9697a4b3fe276062fdd5540fdbcadeea5df9ea41121287421bb40/diff/var/cache/apt/archives/partial': Permission denied
du: cannot read directory '/home/en0ch/Projects/coconut/.local/share/containers/storage/overlay/d96b9d2481a9697a4b3fe276062fdd5540fdbcadeea5df9ea41121287421bb40/diff/var/lib/apt/lists/partial': Permission denied
47G     /home/en0ch/Projects/coconut

thats the output

deanrie · September 29, 2026, 8:53am

Thanks, that makes sense now. du shows 47G in coconut, and almost all of that is in coconut/.local/share/containers/storage/overlay/.... That’s container storage Podman that’s sitting right inside the project folder. The initial rg --files runs use --follow and end up walking into that tree with tens of thousands of files. On top of that, there are root-owned overlay folders, so rg hits permission denied, retries, and wastes time. That’s where the 88 to 99 percent CPU is coming from.

The symlinks in node_modules are relative and harmless, and .venv/bin/python is also minor. The real issue is the container storage inside the project.

What to do, in order of effectiveness:

Best option: move the container storage out of the project folder. It doesn’t belong there, it’s not project code. For rootless Podman, the default is ~/.local/share/containers/storage, not inside coconut. Set graphroot outside the project in ~/.config/containers/storage.conf, or move the storage back to the default location. After that, the project size drops a lot and there’s nothing heavy to scan.
If the storage must stay inside the project, add a .ignore file in the exact root of the folder you open in Cursor, for example /home/en0ch/Projects/coconut/.ignore:

.local/
node_modules/
.venv/
.git/
dist/
build/
target/

This scan respects a root .ignore. It probably didn’t help before because .local/ wasn’t excluded, or the file wasn’t in the real root of the opened folder.

Revert the patch to the bundled rg. It works, but it’ll get overwritten on every Cursor update and it needs sudo, so it’s only a temporary workaround. After steps 1 to 2, you shouldn’t need it:

sudo mv /usr/share/cursor/resources/app/node_modules/@vscode/ripgrep/bin/rg.orig /usr/share/cursor/resources/app/node_modules/@vscode/ripgrep/bin/rg

Use the path where you did the replacement, it can differ on the AUR build.

The fact that the one toggle Ignore Symlinks in Cursor Ignore Search didn’t remove the load is expected. It only affects the .cursorignore scan, and there’s also a separate scan for rules, skills, and AGENTS.md that follows symlinks no matter what. That’s a known limitation, I passed your details to the team, and I can’t share an ETA yet.

Try step 1 or 2, restart Cursor, and check rg again. Let me know how it goes.

Topic		Replies	Views
Rg.exe 100% CPU Bug Reports performance , windows	7	321	October 1, 2026
Instant Grep Beta can peg CPU by indexing $HOME with multiple ripgrep processes following symlinks Bug Reports indexing , performance , macos	1	91	June 8, 2026
Cursor 2.2 scanning working directory and keep doing it on close Bug Reports	3	167	December 15, 2025
Memory Leak [Probably] Bug Reports devcontainers , performance , crashes , macos	10	550	February 17, 2026
Cursor user extension host repeatedly accesses C:\ while idle, consuming ~4 CPU cores and >1 GB RAM Bug Reports extensions , performance , windows	3	82	August 26, 2026

Cursor 88-99% cpu

Related topics