# Does Cursor client implement SSL pinning that prevents HTTPS traffic inspection? **URL:** \ **Category:** Help\ **Tags:** security\ **Created:** [May 12, 2026, 4:09am UTC](https://forum.cursor.com/t/does-cursor-client-implement-ssl-pinning-that-prevents-https-traffic-inspection/160355 "2026-05-12T04:09:46Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Suhas\_Patil](https://avatars.discourse-cdn.com/v4/letter/s/57b2e6/32.png) [@Suhas\_Patil](https://forum.cursor.com/u/Suhas_Patil)\ **Post date:** [May 12, 2026, 4:09am UTC](https://forum.cursor.com/t/does-cursor-client-implement-ssl-pinning-that-prevents-https-traffic-inspection/160355/1 "2026-05-12T04:09:46Z")
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? ---
**Author:** ![mohitjain](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/mohitjain/32/100229_2.png) [@mohitjain](https://forum.cursor.com/u/mohitjain)\ **Post date:** [May 12, 2026, 8:59am UTC](https://forum.cursor.com/t/does-cursor-client-implement-ssl-pinning-that-prevents-https-traffic-inspection/160355/6 "2026-05-12T08:59:38Z")
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. ---
**Author:** ![Suhas\_Patil](https://avatars.discourse-cdn.com/v4/letter/s/57b2e6/32.png) [@Suhas\_Patil](https://forum.cursor.com/u/Suhas_Patil)\ **Post date:** [May 12, 2026, 10:11am UTC](https://forum.cursor.com/t/does-cursor-client-implement-ssl-pinning-that-prevents-https-traffic-inspection/160355/7 "2026-05-12T10:11:56Z")
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. ---
**Author:** ![mohitjain](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/mohitjain/32/100229_2.png) [@mohitjain](https://forum.cursor.com/u/mohitjain)\ **Post date:** [May 13, 2026, 10:40am UTC](https://forum.cursor.com/t/does-cursor-client-implement-ssl-pinning-that-prevents-https-traffic-inspection/160355/8 "2026-05-13T10:40:44Z")
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](https://cursor.com/docs/enterprise/privacy-and-data-governance) docs as well, which cover how data flows in enterprise setups. ---
**Author:** ![system](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/system/32/99069_2.png) [@system](https://forum.cursor.com/u/system)\ **Post date:** [September 16, 2026, 1:51pm UTC](https://forum.cursor.com/t/does-cursor-client-implement-ssl-pinning-that-prevents-https-traffic-inspection/160355/10 "2026-09-16T13:51:55Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.