Agents Window Feedback

Ideas Feedback
,
1

Hi, I hope you’re open to some feedback.

It seems like you are doubling down on the vibe only experience (Agent Mode).

It’s cool you built a faster side experience that doesn’t have the memory and CPU issues that one often encounters in the main Cursor experience.

I’m sure you have visibility into actual data but from how hard you have been pushing users towards agent mode, though I have a hunch that you’re not getting the usage that you expected. My hunch is purely based on how hard you’ve been trying to push users to try it with CTAs in the app and emails.

In terms of tokens per $ you cannot compete with a CC or Codex subscription, so there is no way that I will replace the pure agent mode that I have with those tools with the Cursor one.

Those experiences are evolving very fast thanks to Anthropic and the community.

However, Cursor is still my main tool because it complements the others with its code editing, tab completion, the ability to easily select a code block and prompt quick instructions to fix. Extensions..

Simply put it’s a tool for day to day engineering, not for vibing. To be clear, Claude still writes most of my code, but I research, review CC’s code, debug, and make quick small changes where I don’t need to wait for an agent loop directly on the IDE.

So I really wish you put your efforts where your users are (I’m making assumptions here obviously) and make the core experience fast and reliable. Right now you have CPU and memory usage that’s going through the roof. So replacing your VS code based IDE with a homegrown blazingly fast experience would be my vote.

I’m on the verge of switching to Zed exactly for that. You don’t have a moat with Agent Mode. You DO have one on the IDE.

The fact that I have GitHub integration, k8s plugins, todo list plugins, etc, that’s the kind of stuff that makes an engineer productive – Yes, AI driven development is a brand new era but it complements and enhances the parts that was slow. It doesn’t replace the parts that weren’t.

For 20 years I was a Jerbrains purist. And I hated VS Code. But Jetbrains lost the race when they didn’t adapt their pricing and moved too slow on AI driven development, when they realized their mistake they made the wrong moves with trying to push their own AI brand (What was it? Junie?) that no one wanted. Then they tried to backtrack a little but it was too little too late.

For me, Cursor replaced IntelliJ, but now it seems like you’re trying to pivot and get me to pay a lot more money, for a lot less usage, replace CC at the cost of losing what I switched to Cursor for in the first place. That’s not going to happen.

Please stop it with trying to force the Agents mode on us. The recent change to make agents window the default is so incredibly frustrating. It doesn’t make any sense. If the last thing I used was the editor window, why would I want to come back to the agents window? Why not take me back to the last thing I used?

Thanks.

Ran

ranmagen.com

4

Hey Ran, thanks for the detailed feedback. Posts like this, with clear specifics on what works for you in Cursor (tab, inline edit, extension ecosystem) and what you’re worried about, are really helpful.

On the Agents Window startup behavior, noted. You’re not the only one asking for this. I can’t share exact plans or a timeline for changing it right now, but the feedback is coming in and being read.

On core IDE performance, it helps a lot to turn this into specifics, otherwise the signal gets lost. If you have a minute, can you share a separate thread with:

  • your Cursor version and OS
  • a screenshot from Process Explorer Cmd+Shift+P > Developer: Open Process Explorer at the moment CPU or RAM spikes, what exactly is using resources extensionHost, ptyHost, renderer
  • a run with cursor --disable-extensions to check if an extension is the cause
  • if you caught a Request ID during the slowdown, that would help too

With that, we can bring something concrete to the team.

5

You can search this forum for this problem.. I’m not the only one reporting this and I have commented on a few. The problem is that once this happens, the entire Mac completely freezes and I can’t get any data.

Others have said the same, and then this system automatically closes threads without comments within a certain amount of days. If you get enough reports about a problem, your users are not the ones on the hook to find the root cause for you and closing the threads prevents them from being able to go back and update if it happens again.

From a customer service perspective, it’s kind of odd, customers are telling you what the problem is, they’re doing their best to report, and then on your end you let those threads die and no one else can comment on them if the same problem arises so we have to re-report from scratch.

On my end, the best I can give you is that I think it is somehow related to gopls, possibly with a Pulumi project in the repo alongside a normal go project (so, multiple modules)

6

Fair point about auto-closing. That is default Discourse behavior, not something we set up on purpose, but the effect is the same as you described. If you ever see an old closed thread with your same symptom, just open a new one and ping me here or there, and I’ll connect it.

On Mac fully freezing and not being able to collect data, we can still work with that because macOS logs system-level diagnostics even when Cursor stops responding. Next time you hit a freeze, here are a few options, in order of usefulness:

  1. Activity Monitor → Sample Process: open Activity Monitor if you can before the full freeze, find the process using CPU, usually Cursor Helper (Plugin) or gopls, right click, then Sample Process. This gives a stack trace without needing to type anything.

  2. Spindump during the freeze: from another terminal, or iTerm in a separate window, run sudo spindump -reveal 30 -file ~/Desktop/cursor-freeze.txt. This captures a 30-second snapshot of all system processes and often still works even when the main process is stuck.

  3. Crash reports after reboot: check ~/Library/Logs/DiagnosticReports/. macOS writes hang reports there. Files like Cursor-*.ips or gopls-*.ips from the freeze date are exactly what we need.

Send any of those artifacts here. You can post it in a new thread so it doesn’t mix with the feedback about the Agents Window. Any one of them is enough to tie the issue to a specific process.

Your hypothesis about gopls plus Pulumi plus multiple Go modules in one workspace sounds plausible. gopls with multiple module roots has historically been heavy. While you’re trying to catch a repro, you can narrow it down:

  • Run cursor --disable-extensions on the same workspace. If the freeze goes away, it’s likely an extension issue.
  • If yes, re-enable extensions and temporarily disable Go golang.go. That helps isolate gopls.
  • Try opening the Pulumi project and a normal Go project separately in different windows. If each is fine alone but they freeze together, that’s a solid repro for the team.

Also useful: your Cursor version from Cursor > About, your macOS version, and your Go extension version. Let me know what you find.

7

When the memory overload happens, the entire mac freezes. I can’t go to Activity Monitor, nor switch to the terminal. I can’t run a dump or literally do anything other than stare at a spinning beachball until my screen goes blank and the mac crashes.

Before this happens, Mac opens up a little window showing applications are frozen, and their memory usage, with the only option to force kill. Cursor is the main culprit Although I understand you are saying that it’s more likely some extension rather than cursor itself.

However, given that cursor is the host for these extensions, it seems reasonable to me that you could enact some kind of data collection and enforcement of CPU and memory usage allocated to extensions or sub-processes that are started by extensions.

The reason I think this is related to gopls is that the one time I was able to kill Before going into a spiral, I had run top -o mem and saw 5-6 gopls processes consuming a lot of memory all parented by a “Cursor Helper (Plugin)” process that was not killed along with the main Cursor window.

Here are some other threads:

  1. Cursor consumes a lot of memory
  2. Cursor on macOS consuming massive memory (40GB+) → “Your system has run out of application memory”
8

ok it happened again. gopls is losing its mind. I didn’t open any pulumi files this time so I can’t exactly say.

Sample of gopls.txt (84.5 KB)

pstree -p 96974     
-+= 00001 root /sbin/launchd
 \-+= 33157 ran /Applications/Cursor.app/Contents/MacOS/Cursor
   \-+- 96764 ran Cursor Helper (Plugin): extension-host (user) backend [2-14]                      
     \-+- 96974 ran /Volumes/dock/go/bin/gopls
       \--= 96995 ran /Volumes/dock/go/bin/gopls ** telemetry **

Screenshot 2026-05-12 at 4.33.09 PM
Screenshot 2026-05-12 at 4.33.09 PM3213×326 153 KB

I also go the spindump but it contains PII so I can share it privately if you tell me how.

the command was wrong btw, it’s

sudo spindump -notarget 30 -o ~/Desktop/cursor-freeze.txt -reveal

Version: 3.3.30
VSCode Version: 1.105.1
Commit: 3dc559280adc5f931ade8e25c7b85393842acf30
Date: 2026-05-09T18:28:42.332Z
Layout: editor
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

Mac Mini M4 16GB

MacOS 26.4.1

9

Thanks, this data helped. A couple of clarifications based on what I can see:

The sample you sent was captured after gopls had already gotten stuck. All 50+ threads are sitting in __psynch_cvwait / kevent / wait4. So the process isn’t doing work, it’s frozen and waiting. The peak physical footprint is 12.5GB, which matches what top shows 13G+. This sample confirms the symptom, but it doesn’t show what gopls was doing while memory was growing. The most useful thing would be a spindump captured during the memory growth, or a gopls sample while it’s still alive and active.

About spindump with PII: you can send it to me privately via forum DM. Tell me and I’ll message you.

About gopls: gopls is the Go language server from the Go team The Go Programming Language, and it’s launched by the Go extension golang.go. So it’s not Cursor code. The extension host just runs the binary that the Go extension installs. On large Go workspaces, especially with multiple modules, replace directives, Pulumi, and similar setups, gopls has historically had memory issues.

Things you can try right now so you don’t have to wait for the next freeze:

  1. Set a memory limit for gopls. In settings.json:

    "go.toolsEnvVars": {
  "GOMEMLIMIT": "4GiB"
}

    gopls is written in Go, so it will run GC more aggressively as it approaches the limit instead of growing without bounds.

  2. Update gopls. In the terminal: go install golang.org/x/tools/gopls@latest. Newer versions are noticeably better with memory.

  3. Check your Go extension version. Which golang.go version do you have installed? If it’s old, update it.

  4. Confirm the culprit. Run cursor --disable-extensions on the same workspace. If there are no freezes, then it’s definitely an extension or gopls.

About your suggestion in post #7, that Cursor should enforce memory limits for extension subprocesses, the idea is valid but it’s architecturally hard. The extension host lets extensions launch arbitrary processes, and applying cgroup-style limits on macOS isn’t trivial. VS Code doesn’t do this either. I’ll log it as feedback, but I can’t promise anything.

10

I can’t know it’s going to happen before my machine gets to the point where it’s barely responding and the Force Quit window pops up.

Yes, DM me and I’ll reply with it. I took it after the capture though.

gopls is the Go language server..

Yes I’m aware :slight_smile:

I’ll try your suggestion (upgrading gopls and limiting the memory in the settings). I’m up to date on everything.

I can’t try the cursor --disable-extensions option. It can take between hours and days for this to happen and Cursor without Go is useless for me.

11

FYI I’m not getting an auto-complete on that key. Not sure it’s real. might be a hallucination. Instead I went with

"go.languageServerFlags": ["-profile.mem=/Users/ran/Downloads/gopls-mem.txt"],
12

go.toolsEnvVars is real, it’s a documented setting in Google’s Go extension wiki settings · golang/vscode-go Wiki · GitHub. The extension automatically forwards env vars from this setting into gopls. There’s no autocomplete for values inside like GOMEMLIMIT, GOPROXY because it’s just a free-form env var map and the schema doesn’t describe them. But it works.

These two approaches are for different things and don’t conflict:

  • GOMEMLIMIT via go.toolsEnvVars is a preventive step. Go 1.19+ has a soft memory limit and it makes the GC work more aggressively as it gets close to the limit. This is what can reduce the chance of freezes.

  • Profiling is the diagnostic part. It’s better to use the gopls debug server since it gives live access to heap and CPU profiles without needing to catch the right moment:

    "go.languageServerFlags": ["--debug=localhost:6060"]

    After restarting Cursor, open http://localhost:6060 for the memory and profiling pages. When you notice memory growing, run go tool pprof http://localhost:6060/debug/pprof/heap to grab a real-time snapshot. This is more reliable than waiting for exit Gopls: Troubleshooting - The Go Programming Language.

One more important note: gopls also automatically writes memory debug files into /tmp when usage goes over 1GB. You’re seeing peaks of 12.5GB, so those files are likely already there. Check /tmp/gopls-* or /tmp/gopls.*. If you find them, send them to me in DM along with the spindump.

I’ll DM you so you can send them privately.

13

I meant there was no auto-complete for go.toolsEnvVarsbut sorry that was on me. It didn’t auto complete because the key already existed in the file.

(I’m on Go 1.26 fwiw)

I’ll set all of that up. Thanks.