To chime in on this one, we’re also facing the same issue - on the 0.50.2 and onwards (including the 1.0 releases) - and need some kind of workable solution to allow us to continue using Cursor in line with our security and DLP policies.
For some background context,
Netskope does its traffic-monitoring MITM thing by installing its own SSL certificates on our machines, and it’s a fairly common issue for our Engineers to have to set environment variables like NODE_EXTRA_CA_CERTS, REQUESTS_CA_BUNDLE and SSL_CERT_FILE to allow our own scripts to work locally without getting hobbled by SSL verification errors. But once those values are in place, things work.
What we’ve tried:
Disabling HTTP/2 hasn’t worked for us, nor does Disabling HTTP1 SSE appear to have any effect. I’ve also tried some tricks from elsewhere such as installing the Mac CA VSCode plugin and that seemed to work for a brief window, before that also stopped working.
Symptoms:
When switching around certificates and policies, there seems to be a lag in impact, which makes it tricky to debug. But what I can say with confidence is that Tool use such as reading local files is the easiest test, as is the Agent mode itself. With Netskope enabled, both of these reliably fail / timeout with errors, unable to perform actions such as Read the contents of the @README.md file to me
Workarounds:
The only “workaround” we have is allowlisting the Cursor endpoints in Netskope, but this violates our DLP policies and is not a long term solution for us.
Desired remedy:
I’d love to be able to configure a path to a custom CA file for Cursor, much like we do with the existing environment variables we need for running local scripts. That, or have the ability for Cursor to use the System’s own trusted CA files, rather than its built-in ones that come from the underlying VS Code building blocks.
If there’s a way to work more closely with you to get this resolved, we’re open to it!
