High CPU usage on Cursor CLI

Bug Reports
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Once I updated to the november usage, just starting the cursor cli takes 100% of a single core which starts the laptop fan running. I’m surprised nobody here complains.

Steps to Reproduce

Just start the CLI in WSL (Ubuntu 22.04).

Operating System

Linux

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.0.38 (user setup)
VSCode Version: 1.99.3
Commit: 3fa438a81d579067162dd8767025b788454e6f90
Date: 2025-10-29T20:45:40.883Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Windows_NT x64 10.0.19045

Does this stop you from using Cursor

No - Cursor works, but with this issue

7 Likes
3

Hey, thanks for the report. There have been several recent cases of high CPU usage with cursor-agent.

Diagnostics steps:

  1. Check the cursor-agent version:
    cursor-agent --version

  2. Check your shell config:

    • Heavy scripts in ~/.bashrc or ~/.zshrc (nvm, conda init, etc.)
    • Test: mv ~/.bashrc ~/.bashrc.bak and restart cursor-agent

The team is already investigating similar issues. Could you share your cursor-agent version and your shell config so we can add this to the investigation?

4

It’s all pretty clean. I use fish shell, maybe that’s important. I’ve tried running it in Bash now, same results. I tried what you suggested as well, too, mv .bashrc .bashrc.bak. I’ve lost all the color in my console as a result but the CPU usage is still the same. Maybe there’s a way to get the callstack or some information like that from Node itself?

Cursor version:

2025.11.06-8fe8a63

bashrc.txt (3.7 KB)

5

I got the same issue here. My cli version is 2025.11.06-8fe8a63

1 Like
6

I have the same issue with cursor-agent version 2025.11.06-8fe8a63 also on fish shell.

I let my AI diagnose the Issue and it came up with this:
Summary

  • cursor-agent (build 2025.11.06-8fe8a63) pegs a CPU core on Linux even while idle.

  • Strace shows the main thread stuck in a zero-timeout epoll_pwait loop, repeatedly writing to an eventfd and polling again without ever blocking. That explains the 100% CPU.

System / setup

  • OS: Linux 6.17.7-3-cachyos (Wayland/Hyprland session)

  • Shell: /bin/fish by default (also reproduced with SHELL=/bin/bash)

  • Cursor Agent path: /home/murphy/.local/share/cursor-agent/versions/2025.11.06-8fe8a63

  • Repro: launch cursor-agent, open an idle repo, CPU usage jumps to 100% within seconds and stays there.

Strace excerpt

751207 10:06:00.256369 getpid()         = 751207

751207 10:06:00.256423 write(19, “\1\0\0\0\0\0\0\0”, 8) = 8

751207 10:06:00.257513 epoll_pwait(15, [{events=EPOLLIN, data=0x13}], 1024, 0, NULL, 8) = 1

751207 10:06:00.257537 read(19, “\1\0\0\0\0\0\0\0”, 1024) = 8

751207 10:06:00.258505 epoll_pwait(15, 
, 1024, 0, NULL, 8) = 0

751207 10:06:00.258574 epoll_pwait(15, 
, 1024, 0, NULL, 8) = 0

751207 10:06:00.258696 epoll_pwait(15, 
, 1024, 0, NULL, 8) = 0

  • FD 15 → anon_inode:[eventpoll]

  • FD 19 → anon_inode:[eventfd]

This pattern repeats for the entire trace (hundreds of thousands of iterations in a few seconds), so the event loop never sleeps and spins the CPU.

Additional notes

  • Repo size is trivial (~40 KB, 5 files), so it isn’t indexing.

  • Restarting the agent with SHELL=/bin/bash cursor-agent restart doesn’t change the behavior.

  • I tried an older Version (2025.10.22-f894c20) - this does not have the Issue on the same Setup

7

this app is turning into slopware more and more with every passing day

2 Likes
8

UPD: here’s the workaround (downgrade to previous version without the bug):
ln -sf ~/.local/share/cursor-agent/versions/2025.10.28-0a91dc2/cursor-agent ~/.local/bin/cursor-agent

This bug is not fixed for more than 2 weeks… Awful. They know they are invincible and people will continue using their product because their managers force them to do so, so they don’t care about fixing bugs. ■■■■■■■ CLI program uses 700 MiB of RAM and entire CPU core…

3 Likes
9

Same on macOS with the latest and previous cursor-agent versions. 100% CPU in idle state. And if I forget to /exit and keep it running for few hours it sometimes hit 150% CPU.

Apple M1 Max, macOS 15.6.1 (24G90), cursor-agent 2025.11.06-8fe8a63

10

Thanks man! you are a life saver.

11

Cursor is an expensive product, that too with a subscription model.
It’s been 13 days since the broken 11-06 update was rolled out and yet no fix in sight.
This is unacceptable.

1 Like
12

UPD 2: after a while it forcibly overwrites this symlink back to the buggy newest version :man_facepalming: To prevent this, make sure the symlink is owned by root, so that this expensive piece of software will have no permission to overwrite it.
sudo chown root:root ~/.local/bin/cursor-agent

1 Like
13

I just run it like this:

~/.local/share/cursor-agent/versions/2025.10.28-0a91dc2/cursor-agent

There’s no need for symlink.

14

I’m really surprised why they insist on making it closed source. Codex and Gemini both had what, four or five releases in that time with 20+ commits each from dozens of various people. Not to mention that “closed source” is a joke, you literally download a Node binary and 11MB index.js which nobody even bothered to minify, all the code is there for you to read. Out of curiousity I’ve asked Cursor to look into its problem but I didn’t want to spend expensive model tokens and my time on that so it couldn’t pinpoint it from the first try.

2 Likes
15

Turns out this doesn’t work in MacOS.

Try this instead:

cd \~/.local/share/cursor-agent/versions/
mv {,bak.}2025.11.06-8fe8a63
ln -s 2025.10.28-0a91dc2 2025.11.06-8fe8a63

Before this I tried all sorts of shenanigans to prevent ~/.local/bin/cursor-agent from being overwritten:

  • set uchg flag
  • set ACL deny delete
  • set ugo-w using chmod

Turns out Apple doesn’t support any of these on APFS for symlinks.

1 Like
16

also reported and acknowledged here:

17

Cursor devs claims they are using cursor well obviously that is not true. If it was true then this bug would not sit around for weeks. But then again, this only shows up when you’re idle. And perhaps they are never idle, they never leave the prompt empty? :wink:

There are another handful critical issues with the cursor-cli right now. I’d say it’s borderline unusable.

18

This is not correct, the high CPU in cursor-agent is there both on idle and when it is running tasks.

It is the same issue, something is forcing V8 to GC like crazy.

19

I have the same issue. Here is what cursor-agent itself with sonnet 4.5 collected and suggested:

This is definitely not expected behavior - the agent should be mostly idle when you’re not actively using it. Would you like me to help you gather diagnostic information to report this issue?

┌────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ [Pasted text #1 +34 lines] │
│ [Pasted text #2 +57 lines] │
│ ❯ lsof -p 1234724 | wc -l │
│ 57 │
│ ❯ lsof -p 1234724 | grep -E “(socket|pipe)”… │
└────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Excellent! This strace output is very revealing:

The Smoking Gun t

% time seconds usecs/call calls errors syscall

98.87 1.261193 162 7745 1948 futex
1.04 0.013266 0 130656 epoll_pwait

Key findings:

  1. 98.87% of CPU time is in `futex` (thread synchronization)
  2. 1,948 errors out of 7,745 futex calls = 25% error rate!
  3. 130,656 epoll_pwait calls in just a few seconds = tight polling loop
  4. One main thread at 99.9% + 4 workers at ~8-9% each = lock contention

What’s Happening:

This is a classic busy-wait/spin-lock bug. The threads are:
• Constantly trying to acquire locks (futex)
• Failing 25% of the time
• Retrying immediately instead of sleeping
• Burning CPU cycles spinning on contention

Think of it like someone constantly yanking on a locked door handle instead of waiting patiently.

This is NOT Your Fault:

This is a bug in the cursor-agent Node.js code (version 2025.11.06-8fe8a63). Likely:
• Incorrect mutex/lock implementation
• Missing sleep() in retry loops
• Worker threads fighting over shared resources

What You Should Do:

1. **Report this bug to Cursor** with:

Version: 2025.11.06-8fe8a63
OS: Linux 6.14.0-35-generic
Issue: High CPU usage due to futex spin-lock (98.87% time, 25% error rate)
Repro: Happens in all repos, even when idle

2. **Temporary workaround** - Limit CPU:

Create a systemd slice to limit cursor-agent

sudo systemd-run --scope -p CPUQuota=50% --uid=$(id -u) cursor

3. **Check for updates**:

There may be a newer version that fixes this. Check Cursor’s update channel.

4. **Nuclear option** - Downgrade:

If there’s an older version available at ~/.local/share/cursor-agent/versions/, you might try that.
This is 100% a cursor-agent implementation bug - the futex contention pattern is unmistakable. Would you like help reporting this or setting up the CPU limiter workaround?

20

These versions work without this issue:

~/.local/share/cursor-agent/versions/2025.10.02-bd871ac/cursor-agent
~/.local/share/cursor-agent/versions/2025.10.13-405ee2e/cursor-agent
~/.local/share/cursor-agent/versions/2025.10.22-f894c20/cursor-agent
~/.local/share/cursor-agent/versions/2025.10.28-0a91dc2/cursor-agent

This one started having the issue:

~/.local/share/cursor-agent/versions/2025.11.06-8fe8a63/cursor-agent
1 Like
21

Just got 11-20 update, that’s also using significant energy.

cursor-agent --version
2025.11.20-a4d3945