Hey @Jack_McGregor, thanks for the details. I can see the screenshot with the ps aux output, the extensions list, and the terminal screenshot.
A few notes about your setup:
Extensions. You have 150+ extensions installed, and that’s a big load on the extension host. Also, each orphaned window pulls in the full set. Some of these are especially heavy: gitlens, sonarlint-vscode, ms-python.python, rust-analyzer, cpptools, ms-toolsai.jupyter, anthropic.claude-code, plus a few Solidity, Nginx, and Flutter ones. Even if you’re not actively using them in the current project, many auto-activate.
What to try:
- Run
cursor --disable-extensionsand use it for a few hours. If memory stays stable, extensions are the cause. - Go through the list and disable anything you don’t need right now for a Bun or Next project. In practice you only need about 10 to 15 for that stack.
- Use Profiles for different languages and stacks so you don’t load Solidity, Flutter, Python when you’re working with TS. Use
Cmd+Shift+Pthen search for Profiles.
About your ps aux snapshot. Worth flagging: all extension-host processes are in a normal state there (max 3.2% CPU, ~1.6 GB total across 2 windows). That’s not the orphan busy-loop pattern (94% CPU per process) I mentioned earlier. Looks like you captured it during normal operation rather than during the spike. Can you run the same command again when memory actually blows up to 40+ GB (e.g., in the morning after leaving windows open overnight, before you restart)? That snapshot is the one that will tell us whether it’s orphans or a different leak.
One data point from your current snapshot: a single extension-host (user) is already at 812 MB. With 150+ extensions that’s on the high side of expected baseline, which means any leak on top has a lot of headroom to grow.
Windows and Cmd+Q. Leaving 2 to 5 windows open overnight with that many extensions almost guarantees a pile-up of orphan processes by morning. Use Cmd+Q in the evening instead of just closing the window. This is a known issue. When you close a window, orphan processes can ignore SIGTERM and keep running.
Terminal issue in your second post. Your screenshot shows SGR mouse tracking escape sequences (<35;38;5M...) being printed as text. That means a TUI tool (looks like mprocs, overmind, turbo TUI, or bun dev with a multi-process UI, based on the Processes / platform UP box at the top) enabled mouse reporting and then exited or crashed, leaving the terminal stuck in that mode. That’s why every mouse move prints escape codes and you can’t select text.
Can you share:
- The exact command or tool you were running at the top of that terminal?
- Whether the same thing happens if you run it in iTerm2 or Terminal.app vs Cursor’s integrated terminal?
If it reproduces only in Cursor’s integrated terminal, start a separate thread with the repro and a short video if possible, so I can file it independently.
The orphaned extension host bug is in our backlog. I can’t share an ETA yet. When a fix starts rolling out, I’ll reply in the thread.