Cursor does not implement SSL pinning. The app uses standard OS/Chromium certificate validation, so HTTPS interception with tools like mitmproxy, Fiddler, or Charles should work if configured correctly.
A few common reasons traffic inspection fails and how to fix each:
1. HTTP/2 compatibility Many proxy tools struggle with HTTP/2 multiplexed streams. Try switching Cursor to HTTP/1.1: open Cursor Settings > Network and set HTTP Compatibility Mode to HTTP/1.1. You can also set "cursor.general.disableHttp2": true in settings.json.
2. Proxy CA certificate not trusted Your interception proxy generates its own certificates signed by a custom CA. That CA must be trusted by the app:
-
OS trust store: Install the proxy’s root CA in your system certificate store. Since Cursor uses Chromium’s networking stack, it picks up OS-trusted CAs automatically.
-
Node.js layer: For requests handled by Node.js internally, set the
NODE_EXTRA_CA_CERTSenvironment variable to point to your proxy’s CA certificate file before launching Cursor.
3. Proxy configuration Make sure Cursor knows about your proxy. In Cursor settings, set http.proxy to your proxy address (e.g., http://127.0.0.1:8080). Set http.proxyStrictSSL to false if using a self-signed proxy CA.
4. Wireshark (passive capture) Wireshark can’t decrypt TLS without session keys. Set the SSLKEYLOGFILE environment variable to a file path before launching Cursor. Chromium (which Cursor is built on) will log TLS session keys there, and Wireshark can use them to decrypt the capture.
For mitmproxy or Fiddler, steps 1-3 above should be sufficient.