Hey man, if you have been running cursor for a while (both like.. on a single run and since a long time) a bit of cleaning around can totally fix this problem. How many plugins and skill do you have? If you don’t use them all, or have some outdated ones, cleaning those can fix those long CPU holds, you can also just ask cursor to do so.
I have all plugins and mcps deactivated. I only activate them when I need them (which I don’t understand, I think I shouldn’t have to pay a price in context when I just want to easily activate a plugin on a given conversation). Also did a skill pruning last week. I’m pretty sure that’s not the issue. The last message is the clue imo
This is a known bug with the Glass sidebar. When a workspace has a very large number of uncommitted changes (your 92 files / +136K lines), the sidebar row subscriptions scale with the change set size and aren’t capped. Combined with 10+ agent threads, it overwhelms the renderer.
Our team is tracking this and working on a fix (capping the per-row work and virtualizing the sidebar).
In the meantime, two workarounds:
Commit or stash the large change set in the affected workspace before opening Cursor. The sidebar performance scales with uncommitted diff size, so reducing it should help immediately.
Close agent threads you’re not actively using. Each mounted sidebar row adds subscription cost, so fewer visible agents = less pressure on the renderer.
Let me know if either of those helps, or if the issue persists even with a smaller diff.
We’ve made a number of improvements over the past few months to how the agents sidebar and diff views handle workspaces with very large uncommitted change sets.
If you’re still seeing the heavy CPU usage on startup on the latest version, please let us know!
