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.
