Cursor connects to several domains not listed under Settings → Network → Required domains. Does this mean they can be blocked? What functionality will be affected?
Hey, thanks for the detailed report. This isn’t a bug. All three domains are legitimate Cursor infrastructure, the list in Settings → Network is narrower than the real set. Here’s a breakdown:
metrics.cursor.sh is the endpoint for error and crash reporting. No code, prompts, or file contents are sent there. In Privacy Mode the amount is reduced even more to crash-level telemetry only, basically crash counters, so you still see the connection, but that’s by design and doesn’t violate Privacy Mode since no content is sent.
us-only.gcpp.cursor.sh is a regional proxy that routes to the same backend as api*.cursor.sh. It’s part of the same *.cursor.sh family.
*.public.blob.vercel-storage.com hosts static assets like icons and images for the marketplace and MCP, read-only image fetches.
Can you block them? Yes, core functionality won’t break. Blocking metrics.cursor.sh disables crash report sending. Blocking the Vercel blob means some icons and banners won’t load. It’s better to allow all *.cursor.sh traffic.
Also, for allowlisting in strict networks, don’t rely on the narrow list in Settings. Use the broader wording from the docs: the machine needs access to *.cursor.sh, cursor-cdn.com, marketplace.cursorapi.com, and the AI provider endpoints: https://cursor.com/docs/enterprise/deployment-patterns. The *.cursor.sh wildcard covers both metrics and gcpp.
Let me know if any domain still breaks something when blocked.
This suggests Cursor would initiate the connections only to report errors and crashes, right?
But I see requests to metrics.cursor.sh much more frequently, when cursor is completely idle., more like a beacon pattern.
I’d expect such periodic requests against status.cursor.com, but that connection was made less than once a day on average, while metrics.cursor.sh is being pinged as I type this, with Cursor idle for hours (no agents running) on the Rules, Skills, Subagents settings page.
Good question. It’s important to separate two things: an established connection and session traffic vs actually sending data.
The Sentry SDK (what’s behind metrics.cursor.sh) initializes on startup and keeps a session open, so periodic low-level requests while idle are session keep-alive or heartbeat, not separate crash reports. So the fact that you see periodic calls to metrics.cursor.sh when idle is expected and doesn’t mean code, prompts, or file contents are being sent. In Privacy Mode the filter is even stricter, only fatal-level events (crash counters) are sent out, no content is sent.
To confirm this more concretely, can you clarify two things:
Is Privacy Mode still enabled right now?
Roughly how often are the requests to metrics.cursor.sh happening, once per second, per minute, or less?
If you can, a capture showing the real request frequency and payload sizes would really help distinguish heartbeat from something more frequent that we should look at separately. If it turns out to be a noticeable beacon at a high frequency, I’ll raise it internally and follow up in the thread.
And like before: blocking metrics.cursor.sh in strict networks is safe. Only crash reporting will stop, the rest of the app won’t break.
I’ve been keeping an eye on the requests to metrics.cursor.sh over the past ~3 weeks.
Privacy Mode has always been on
The requests have generally been happening every 5 - 30 minutes, but my usage was a mix of active usage and leaving Cursor idle. Far more often than requests to status.cursor.com eiher way.
When left completely idle overnight, connections happened on the hour sharp; they also happened on the hour during active use last night (that’s as far as the firewall logs go):
Thanks for taking the time to collect data over three weeks. That’s exactly what helps make sense of what’s going on.
On metrics.cursor.sh: the hourly pattern right on the hour plus more frequent requests during active use matches how the Sentry SDK behaves. It keeps a session open and sends keep-alive or heartbeat events. These are not separate crash reports and not a beacon with content. Code, prompts, and file contents are not sent there. In Privacy Mode the filter is even stricter, only fatal-level events go out, basically crash counters. So the frequency you’re seeing is explained by the session being kept alive, not by data being uploaded. Blocking metrics.cursor.sh in locked-down networks is still safe. Only crash reporting will stop, the rest of the app won’t break.
A couple quick questions to narrow it down:
Was this a one-time connection attempt during the update to 3.12.29, or does it keep happening after that too, including while idle?
Did the connection actually get established, or was it only an attempt, can you see allow or deny in the firewall logs?
I’ll check whether this is our infrastructure and what’s triggering it, and I’ll reply here. For allowlisting in strict networks, the approach is the same. Use the broader patterns from the docs *.cursor.sh, cursor-cdn.com, marketplace.cursorapi.com plus the AI endpoints, not the narrower list in Settings → Network: Deployment Patterns | Cursor Docs
