Cursor Was Using 50GB of Memory – The Cause Was a Nested `.cursor` Folder

I recently hit a fairly ridiculous issue while running a Next.js app.

My Mac started slowing down badly, and Activity Monitor showed:

Cursor: 50GB+ memory
Chrome: 16GB+ memory

Enter fullscreen mode Exit fullscreen mode

At first, I assumed the app had a memory leak.

I checked the usual suspects:

• React render loops
• leaking useEffect hooks
• timers and listeners without cleanup
• excessive console logging
• large client-side renders
• Next.js cache problems

I also cleared .next, restarted the dev server, restarted Cursor, and checked for unusually large files.

None of that fixed it.

The Actual Cause

Eventually, I noticed that the .cursor directory was nested inside the project instead of sitting at the repository root.

It looked roughly like this:

my-project/
├── app/
│   └── some-folder/
│       └── .cursor/
├── components/
├── package.json
└── next.config.ts

Enter fullscreen mode Exit fullscreen mode

Instead of:

my-project/
├── .cursor/
├── app/
├── components/
├── package.json
└── next.config.ts

Enter fullscreen mode Exit fullscreen mode

I have no idea how it ended up there.

I moved the nested .cursor folder back to the project root, fully restarted Cursor, and the memory usage immediately returned to normal. That was the only change that actually fixed it.

Why This Took So Long to Find

Restarting Cursor had not helped because it was reopening the same project with the same misplaced directory.

The app itself looked guilty because Chrome was also consuming a large amount of memory, so I spent time checking React and Next.js first.

In the end, the problem was not a render loop or some deeply buried application bug.

It was one hidden folder in the wrong place.

Quick Check

Run this from the project root:

find . -type d -name ".cursor"

Enter fullscreen mode Exit fullscreen mode

For a normal single-project repository, you would usually expect:

./.cursor

Enter fullscreen mode Exit fullscreen mode

A deeply nested result is worth investigating.

Be careful with monorepos, because nested configuration may be intentional. Do not move anything blindly.

The Fix

1. Find the misplaced .cursor directory.
2. Move it to the repository root.
3. Fully quit Cursor.
4. Reopen the project.
5. Check memory usage again.

In my case, that was enough.

The Lesson

When an editor suddenly starts consuming absurd amounts of memory, do not only inspect the application code.

Also inspect the project structure, especially hidden tool-specific directories.

One misplaced folder caused Cursor to reach more than 50GB of memory and sent me looking for problems that were not there.