Cursor creating a huge amount of data flows

[user1397]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

While using cursor for coding purposes, we noticed each cursor client created a huge amount of data flows to a whole bunch of AWS public IPs (various IPs of api2.cursor.sh, api3.cursor.sh). For each user, we saw up to 12000 active data flows (as a comparison a normal user without using cursor will only have 50-100 active flows). This is causing a problem to the company network as the network devices couldn’t handle that many flows. We did packet capture and had a look of those flows, they look like stale sessions with minimal packets sent/received. And they don’t get terminated until the default timeout value elapsed.

We have tried changing into privacy mode, stop indexing, and disabled the LLMs but to no avail. It’s still calling the cursor API to reach out to AWS.

Can you please provide some suggestions on how to mitigate this issue?

Thanks.

Steps to Reproduce

You just need to run cursor IDE and check the network flow table (or wireshark packet capture), then you will see this.

Expected Behavior

I don’t expect a single software to generate that many active flows. With each user generating 10k flows, 100 users will create 1 million flows simultaneously.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.1.50
VSCode version: 1.105.1

For AI issues: which model did you use?

the default models, even after disbaling all the models the issue continues.

Does this stop you from using Cursor

Yes - Cursor is unusable

[deanrie]

Hey, thanks for the report.

It looks like a conflict with a corporate proxy/SSL inspection and HTTP/2 streaming. Please check:

1. In app settings Ctrl+, find “HTTP/2” and enable “Disable HTTP/2,” then restart Cursor. Short docs: Common Issues | Cursor Docs

2. Cursor Settings → Network → Run Diagnostics and send the full output.

3. Are you using Zscaler/SSL inspection or any other SWG? If yes, add exceptions for these domains:

   cursor-cdn.com, 
   marketplace.cursorapi.com, 
   authenticate.cursor.sh, 
   authenticator.cursor.sh
   

   Proxy/streaming requirements: Network Configuration | Cursor Docs

4. Confirm it’s TCP:443 (not UDP/QUIC) and attach a short pcap/log showing an example of “stuck” sessions.

5. If the issue persists after step 1, send 1-2 Request IDs from chats at the moment the connection count grows (chat menu → Copy Request ID), along with your Windows version and the result from Help → About.

Let me know if disabling HTTP/2 helped.

[user1397]

Hi Dean, thanks for the reply. Let me attach some more info.

I checked the app settings for http/2, looks like it’s already disabled by default. We are not using a proxy in our environment, internet traffic goes throug the firewall and it doesn’t do any SSL inspection.

In the packet capture, you will see 54.156.173.217 as one of the IPs with stuck sessions.

cursor packet capture.zip (1.6 MB)

network diagnostics.txt (3.8 KB)

[user1397]

Hi Dean, did you get a chance to look into this further?