I’m trying to analyse network traffic from the Cursor IDE for debugging but I’m struggling to capture HTTPS traffic properly.
I’ve tried using mitmproxy, wireshark and fiddler but none of them produce logs. It seems Cursor IDE is using certificate pinning which might explain this. Can anyone confirm if this is the case?
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_CERTS environment 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.
Thanks @mohitjain
I’ve already tried options 1, 3 and 4 but to no avail. I can only see traffic for authentication and telemetry requests. I’ll give option 2 a try and hopefully I’ll be able to debug and inspect the prompt content.
However, these options are very specific to a particular cursor IDE and its host system. For instance, I’m developing an inline proxy tool that analyses cursor prompts and other cursor IDE activities to perform Data Loss Prevention on content transmitted by each IDE. My concern is whether it’s even feasible to detect and inspect all cursor IDE traffic using an inline proxy tool.
Yes, it’s feasible. Cursor doesn’t do anything to prevent inline proxy inspection. All LLM traffic goes through standard HTTPS to our API endpoints (api2.cursor.sh and related domains). An inline proxy positioned at the network layer (transparent proxy, ICAP, or explicit forward proxy) can intercept and inspect all prompt content if the proxy’s CA is trusted by the host.
The key domains to monitor are *.cursor.sh, *.cursorapi.com, and *.cursor-cdn.com. All prompt/completion payloads flow through these. With NODE_EXTRA_CA_CERTS set and your proxy CA in the OS trust store, you should see the full request bodies.
If you’re only seeing auth and telemetry, the likely issue is that the main LLM traffic is going through a different code path that isn’t picking up your proxy settings. Make sure http.proxySupport is set to override (not fallback) in Cursor settings so all traffic is forced through the configured proxy.
For an enterprise-wide deployment, your IT team may want to look at our Privacy & Data Governance docs as well, which cover how data flows in enterprise setups.