One of my Cursor instance (“Corporate” - logged into corporate account tied to corporate email) is not responding and another instance (“Personal” - logged into my personal Cursor tied to gmail). For the non-reponsive Corporate instance, I have described all the symptoms in this thread (link), which Mohit provided guidance on and I’m trying to get my IT team to follow. That said, I wonder why the Personal instance is not showing the same symptoms (agents respond within reasonable time) when both instances are set to HTTP/1.0; both should be subject to the same network constraints and the Personal instance is showing the same SSL interception and Chat buffering errors when running Network Diagnostic. I’m concerned there are other underlying issues with the Corporate instance.
How can I troubleshoot this? Are there any logs I can upload that could inform the difference?
Hey @tsufleta,
Both instances are affected by the proxy buffering, but the Corporate one feels it more for a few reasons:
-
Enterprise account overhead: Your corporate account is on a large enterprise team. Cursor makes additional API calls for team authentication, compliance checks, and usage tracking behind the scenes. Each of those calls gets individually buffered by the Netskope proxy, and the cumulative delay adds up.
-
Codebase size: If your corporate project is larger or more complex than your personal one, indexing requires significantly more round-trips to the server. Each round-trip is slowed by the proxy, so bigger projects see much more noticeable delays.
-
Your personal instance is slower too: It’s just less noticeable because shorter prompts and simpler projects produce shorter responses, which means less buffering delay before the response arrives.
On our end, all your requests are completing successfully. There are no errors, timeouts, or dropped connections server-side. The unresponsiveness is entirely from the proxy buffering responses before they reach your client.
The fix remains the same: getting your IT team to exclude Cursor’s domains from Netskope SSL inspection (the domain list and verification curl commands are in the Enterprise Network Configuration docs). Once that’s done, the Corporate instance should see the most dramatic improvement.
For the most useful troubleshooting you can share with your IT team right now: have them run the HTTP/1.1 streaming curl test from those docs. If the output appears all at once after 5 seconds instead of line-by-line, that confirms the proxy is buffering, and excluding those domains is the fix.
A couple more things from your earlier thread:
Why it appeared suddenly: This usually happens when your IT team deploys an updated Netskope policy or proxy configuration. Worth asking your security team if anything changed around when the symptoms started.
GitHub login popup still appearing: Since GitHub: Sign Out and disabling the extension didn’t help, try opening Keychain Access on macOS, searching for github and vscode, and deleting any matching entries. Also run git config --global credential.helper in your terminal. If it shows a credential helper, that could be re-triggering the auth flow.
Thank you for all your support. I have conveyed this to my IT support team.