Hey, I see the screenshot. That’s a lot of connections to api2.cursor.sh while Cursor is idle.
A few things to help narrow this down:
Try launching Cursor without extensions. Run cursor --disable-extensions in Terminal, then monitor the network again. Extensions are a common cause of extra background activity.
What tool are you using to monitor connections? Little Snitch, Proxyman, etc. If you can see the request paths or endpoints, that can help us figure out what’s polling.
Can you check Activity Monitor and share the CPU percent for the Cursor Helper processes while this is happening?
Cursor does make some periodic network calls by design, like telemetry, feature flags, and update checks, but about 1 request per second while idle isn’t expected. Let’s rule out extensions first since that’s been the cause in most similar battery drain reports on macOS.
Thanks, I see a new screenshot from Surge. GetGlassEarlyPreviewEnrollment and GetTeams every 1 to 3 seconds while idle is definitely more frequent than it should be.
One question left, did you try launching Cursor with cursor --disable-extensions? I want to make sure extensions aren’t adding extra requests on top. If the polling still happens without them, then it’s definitely on our side.
Thanks for testing with --disable-extensions and sharing the Surge logs. That confirms it’s on our side, not caused by extensions.
From the screenshot you shared, the polling frequency is clearly too aggressive when the app is idle. Requests like GetGlassEarlyPreviewEnrollment, GetEffectiveUserPlugins, AnalyticsService/SubmitLogs, and GetTeams shouldn’t be firing every few seconds when nothing is happening.
I’ve flagged this to the team. No ETA yet, but your detailed Surge captures are exactly what we need to track it down. We’ll update here if there’s any news.
