Cursor cli is unresponsive and burns cpu

Support Bug Reports
1

Describe the Bug

I started cursor cli today and it basically was unusable. I’d type in keys and it would reflect the change in about 10 seconds. Maybe you were trying to index my repo or something?

Steps to Reproduce

  1. Download cursor cli
  2. Open in git repo that I’ve used for cursor window
  3. See cpu explode in usage.

Operating System

Linux

Current Cursor Version (Menu → About Cursor → Copy)

2025.08.15-dbc8d73
2025.08.15-dbc8d73
2025.08.15-dbc8d73

Does this stop you from using Cursor

Yes - Cursor is unusable

2

We are trying to find cursorrules / cursorignores / gitignores at startup. The latest update made that a lot more efficient, any chance this fixed it?

3

I deleted and redownloaded the agent and got the same version: 2025.08.15-dbc8d73

and I can’t ctrl + c.

Do you need to move the indexing tasks to a background thread?

4

ran out of heap memory

Cursor Agent
\~/gimlet · use_zero_object_det_in_workbench

┌──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ → dldl                                                                                                                                                                           │
└──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

Starting…
/ for commands · @ for files

<— Last few GCs —>

\[3105079:0x6a80000\]   118640 ms: Mark-Compact 4002.9 (4129.4) → 3987.6 (4129.9) MB, pooled: 2 MB, 1495.41 / 0.00 ms  (average mu = 0.100, current mu = 0.005) allocation failure; scavenge might not succeed
\[3105079:0x6a80000\]   120142 ms: Mark-Compact 4003.4 (4129.9) → 3988.2 (4130.6) MB, pooled: 1 MB, 1494.67 / 0.00 ms  (average mu = 0.054, current mu = 0.005) allocation failure; scavenge might not succeed

<— JS stacktrace —>

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

1: 0xe16044 node::OOMErrorHandler(char const\*, v8::OOMDetails const&) \[/home/philkuz/.local/share/cursor-agent/versions/2025.08.15-dbc8d73/node\]
2: 0x11e0dd0 v8::Utils::ReportOOMFailure(v8::internal::Isolate\*, char const\*, v8::OOMDetails const&) \[/home/philkuz/.local/share/cursor-agent/versions/2025.08.15-dbc8d73/node\]
3: 0x11e10a7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate\*, char const\*, v8::OOMDetails const&) \[/home/philkuz/.local/share/cursor-agent/versions/2025.08.15-dbc8d73/node\]
4: 0x140e985  \[/home/philkuz/.local/share/cursor-agent/versions/2025.08.15-dbc8d73/node\]
5: 0x140e9b3  \[/home/philkuz/.local/share/cursor-agent/versions/2025.08.15-dbc8d73/node\]
6: 0x1427a8a  \[/home/philkuz/.local/share/cursor-agent/versions/2025.08.15-dbc8d73/node\]
7: 0x142ac58  \[/home/philkuz/.local/share/cursor-agent/versions/2025.08.15-dbc8d73/node\]
8: 0x1c90921  \[/home/philkuz/.local/share/cursor-agent/versions/2025.08.15-dbc8d73/node\]
\[1\]    3105079 IOT instruction (core dumped)  cursor-agent

Note I am literally doing nothing.

5

any chance there is an easy repro? checking out gimlet and starting cursor-agent?

6

I created a fresh clone and this problem did not occur. I think that cursor-agent doesn’t read our gitignore so it tries to read all of our bazel directories

7

We based a lot of our repo off of this public one: GitHub - pixie-io/pixie: Instant Kubernetes-Native Application Observability

You could clone and bazel build //… and see what happens when cursor-agent runs

8

still impossible to use @lukasmoeller, would really love to try it in my repo!!

9

I tried, cloned the pixie repo, tried running `bazel build //src/pixie_cli:install.sh` (which eventually failed), but it still starts up alright. Does this repro in any other repository?

10

I suspect what is happening right now is that cursor is reading all the symlinks or files created in my bazel repo after a lot of usage. It’s possible that running install.sh only created a few symlinks. I’d recommend you build something more intensive like:

bazel build //src/vizier/services/agent/pem:pem

I think that install.sh literally just copies a file from the repo to the bazel workspace.

11

what you can also try to do is to create a directory that contains 100000 symlinks to another directory outside of a git root and see what happens to cursor-cli

12

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.