An unexpected error occurred on our servers. Please try again, or contact support if the issue persists. Request ID: bc15d272-8da4-4687-a3b5-8475d493e947
I looked for the request ID in our logs, and there’s no trace of it on our side, which usually means it was blocked or dropped somewhere on the network path between Cursor and us (often a corporate proxy, firewall, VPN, or DNS issue) rather than a problem with a specific model.
A few things that should help us narrow it down:
Open Cursor Settings > Network and click Run Diagnostics, then share the results here.
If you’re on a VPN or a corporate/office network, try a different network (or temporarily off VPN) to see if the agent responds.
Confirm whether it fails on every single request, or only in one specific chat.
Once we have the network diagnostics output, we can pinpoint exactly where the request is being dropped.
Hi @dobrito Thanks for the screenshot and running the test. This output pinpoints the issue, and it isn’t a problem on Cursor’s side.
The SSL line shows your network is intercepting Cursor’s encrypted traffic and re-signing it with a certificate from “Mercury NZ Ltd”. That’s an SSL inspection proxy on your corporate network. Because Cursor doesn’t recognize that certificate, every connection to our API, Chat, and Agent services fails with “self signed certificate in certificate chain”. That’s also why the original request never reached us and you got the generic server error, the connection was blocked before it left your network.
To fix it, Cursor needs to trust your company’s root certificate. On Windows, in this order:
Ask your IT or security team (or even better if you’re an admin) for your company root CA certificate (a .crt or .pem file). Then either import it into the Windows “Trusted Root Certification Authorities” store (Local Machine), or set a system environment variable pointing to it, for example NODE_EXTRA_CA_CERTS=C:\path\to\mercury-ca.pem
In Cursor, press Ctrl+Shift+P, choose “Preferences: Open User Settings”, search for “certificates”, and enable both “Http: System Certificates” and “Http: Experimental: System Certificates V2”. Looks like this:
Open Cursor Settings > Network and set HTTP Compatibility Mode to HTTP/1.1, since HTTP/2 is stricter through inspection proxies.
Fully quit and reopen Cursor, then run Network Diagnostics again. All checks should pass.
If you’d prefer not to manage certificates on each machine, the cleanest option is to ask your IT team to exclude Cursor’s domains from SSL inspection so the traffic isn’t decrypted: *.cursor.sh, *.cursor-cdn.com, *.cursorapi.com, and api2.cursor.sh. Those can be found under Cursor Settings → Network → Required Domains.
I realize this is a lot, but I’m giving you all the info here to try to get you unblocked ASAP. Hope to get you unblocked as soon as possible. Let me know how this goes.
