Cursor last update freeze on macOS

[samson-k (Samson Kipp)]

1. This file does not exist (there is no cursor folder in app sup)

2. {

   “mcpServers”: {

   "sequential-thinking": {
   
     "command": "npx",
   
     "args": \[
   
       "-y",
   
       "@modelcontextprotocol/server-sequential-thinking"
   
     \]
   
   }
   

   }

   }%

   All other MCPs are installed through their respective plugins. (context7, supabase, next.js, stripe, etc.)

3. The new Cursor Agent Layout, the whole app freezes so I can’t check if it also applies to the old editor.

4. no, im using GitHub desktop to commit/push and pull, im a single developer

5. 

[samson-k (Samson Kipp)]

my stupid ahh was looking in the system library not user library, my bad…
Here is the main.log. It’s always code 15.

BTW updated yesterday to the latest version and it is even worse. 100% not usable, the second I hit enter on the prompt it freezes. Sometimes restarting the Mac 2-3 times helped for half an hour.

Do you have recommendation for reverting? Does it keep my chat history in the app support folders when I delete 3.2 and just drag 3.1 into the app folder?

main.txt (2.1 KB)

[leogou (Leo G)]

1. main.txt (1.4 KB)

2. MCP config exists but it’s empty.

3. Cursor freezes the extensions, the source control… (I recorded a video)

4. Sometimes are linked to a Github PR, sometimes not.

   

[deanrie]

Hey, thanks for the screenshot and the log, but it’s still hard to tell what’s going on right now.

From what we have so far:

• main.log is only 1.4 KB and shows only idle stuff update checks, extension host exits with code: 0, so a clean exit. Other users in this thread with a similar symptom show code: 15 (SIGTERM). You don’t have that, so this looks like a different pattern.
• Activity Monitor shows ~12% total CPU and Renderer at 4.3%, which also doesn’t look like a freeze moment.

We need to capture the state right when it freezes. Next time you hit the freeze:

1. Note the exact time, then immediately open Activity Monitor, sort by %CPU, and take a screenshot. We care about Cursor Helper (Renderer) and the extension-host processes.
2. Right after the freeze, without restarting Cursor, send the latest main.log so it still includes an entry with the same timestamp.
3. Also check ~/Library/Application Support/Cursor/logs/. There may be subfolders with renderer and extension host logs. If you see fresh ones, attach those too.

Since you’re seeing freezes specifically in extensions plus the source control panel, this looks like a separate pattern we’ve seen for a few users on 3.0.x to 3.2.x. A full log from the freeze moment will really help us connect the dots.

[timkindberg]

Same here, very slow with only 2 workspace open.

Operating system: Mac, M2 Max, 64GB, Mac OS26.4

About Cursor:
Version: 3.2.16
VSCode Version: 1.105.1
Commit: 3e548838cf824b70851dd3ef27d0c6aae371b3f0
Date: 2026-04-28T21:07:47.682Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.4.0

Memory Usage:

• Cursor Helper (Renderer) — 2.97 GB RAM | 29 threads | PID 23964 | CPU: 0.3%

• Cursor Helper (Plugin): extension-host vndly2 — 578.8 MB | 52 threads | PID 67451 | CPU: 0.7%

• Cursor Helper (GPU) — 480.0 MB | 15 threads | PID 23959 | CPU: 0.0%

• Cursor — 262.8 MB | 51 threads | PID 23954 | CPU: 0.3%

• Cursor Helper (Plugin): extension-host vndly-ux — 247.9 MB | 52 threads | PID 83044 | CPU: 0.6%

• Cursor Helper (Plugin): extension-host empty — 235.3 MB | 35 threads | PID 24017 | CPU: 1.3%

• Cursor Helper (Renderer) — 136.3 MB | 20 threads | PID 68198 | CPU: 0.0%

• Cursor Helper: shared-process — 82.3 MB | 23 threads | PID 24020 | CPU: 0.0%

• Cursor Helper: fileWatcher — 47.9 MB | 25 threads | PID 31443 | CPU: 0.0%

• Cursor Helper: terminal pty-host — 37.1 MB | 26 threads | PID 24023 | CPU: 0.3%

• Cursor Helper: fileWatcher — 30.9 MB | 25 threads | PID 24069 | CPU: 0.0%

• Cursor Helper: fileWatcher (empty-window) — 30.5 MB | 25 threads | PID 24021 | CPU: 0.0%

• Cursor Helper — 18.2 MB | 19 threads | PID 23961 | CPU: 0.1%

• Cursor Helper (Plugin) — 15.9 MB | 10 threads | PID 23319 | CPU: 0.0%

• Cursor Helper (Plugin) — 14.4 MB | 14 threads | PID 83238 | CPU: 0.0%

• Cursor Helper (Plugin) — 14.2 MB | 10 threads | PID 67667 | CPU: 0.0%

• Cursor Helper (Plugin) — 14.1 MB | 10 threads | PID 24425 | CPU: 0.0%

• Cursor Helper (Renderer) — 13.3 MB | 16 threads | PID 68202 | CPU: 0.0%

• CursorUIViewService — 12.6 MB | 3 threads | PID 1682 | CPU: 0.0%

• AutoFill (Cursor) — 10.2 MB | 4 threads | PID 26650 | CPU: 0.0%

• Cursor Helper — 8.9 MB | 11 threads | PID 36509 | CPU: 0.0%

Total: 21 processes — The first Cursor Helper (Renderer) alone is eating nearly 3 GB, and total RAM across all Cursor processes is roughly 5.3 GB.

[deanrie]

Hey @timkindberg, thanks for the detailed snapshot. What you’re seeing looks different from the original freeze in this thread. CPU is basically near zero everywhere, but Renderer is holding almost 3 GB, and total is about 5.3 GB. That looks more like a slow degradation from state building up in agents or composer storage in Glass mode, not the freeze we fixed in 3.1.14.

To confirm it’s that pattern and make sure we’re not missing something new, can you share:

1. ~/Library/Application Support/Cursor/logs/main.log rename it to .txt so you can upload it. Ideally from the same session where you took the Activity Monitor screenshot.
2. How many agent conversations or chat tabs you have open in the Glass panel, and how long Cursor has been running without a restart hours or days.
3. If you can, a heap hint: run cat ~/.cursor/mcp.json if the file exists, and attach the contents.

For now, please try this workaround to test. It helped other users in this thread:

• Close Cursor.
• In Finder go to ~/Library/Application Support/Cursor/User/globalStorage/ this is where the agent databases live. If there are lots of old ones, you can clean them up or back them up and delete them to see if it changes anything.
• Restart Cursor and check if the Renderer memory footprint goes down.

This is a known area the team is working on memory growth during long agent sessions. The logs and answers above will help us match your case exactly.

[timkindberg]

Your system is not allowing me to upload the things you requested

[deanrie]

Got it, the forum can be a bit flaky with uploads sometimes. A few options:

1. main.log: rename it to main.txt before uploading, Discourse blocks .log. If it’s small, you can just paste the contents directly in the thread in a code block using triple backticks.
2. If the file is too big (the forum caps at about 4 MB): upload it to gist.github.com or pastebin.com and drop the link here. Or share only the last ~500 lines from when you start noticing the slowdown.
3. Activity Monitor screenshots: PNG files up to 4 MB should work. If it still won’t upload, try WebP or JPEG with lower resolution, or upload via imgur or gist too.

What’s especially helpful:

• main.log (or the tail) around the moment when Renderer is already sitting at about 3 GB
• the contents of ~/.cursor/mcp.json (if it exists), you can paste it as text
• how many agent conversations or chat tabs you have open in Glass, and how long Cursor has been running without a restart