Cursor stopped working after update — self-signed certificate / SSL decryption issue?

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I recently updated Cursor, and I am wondering whether the issue I am seeing might be related to the new Cursor version. I cannot say for sure, though, so it may also be unrelated.

I am working in a corporate network where SSL traffic is decrypted using a company-managed, self-signed certificate. This certificate has been installed and trusted on my system, and until now this setup worked without any issues in Cursor.

Since the update, however, I can no longer use Cursor properly. All chats fail with an internal error. When I run the built-in Cursor Network Diagnostic, I see failures for several endpoints. The error seems to be related to the certificate chain:

self signed certificate in certificate chain

The SSL diagnostic also reports that encrypted traffic is being intercepted by an unrecognized certificate:

CN=Palo Alto Trust

This is expected in our environment because of our corporate SSL decryption setup, but the certificate should already be trusted by the system. As mentioned, this worked before.

Here is the relevant part of the diagnostic output:

FAILED (4): API, Ping, Chat, Agent
WARNINGS (1): SSL

SSL: Warning: Encrypted traffic is being intercepted by unrecognized certificate: C=undefined; O=undefined; CN=Palo Alto Trust

API: Error: [internal] self signed certificate in certificate chain
Ping: Error: [internal] self signed certificate in certificate chain
Chat: Error: [internal] self signed certificate in certificate chain
Agent: Error: [internal] self signed certificate in certificate chain

Other checks such as Marketplace, Authentication, Authentication UI, Cursor Tab, Agent Endpoint, Codebase Indexing, Downloads, and CDN appear to succeed.

My questions are:

  1. Has anything changed recently in Cursor regarding certificate handling, TLS validation, or trusted certificate stores?
  2. Is there a recommended way to configure Cursor so that it trusts a corporate CA / self-signed certificate used for SSL inspection?

Any guidance would be appreciated. This setup worked previously, so I am trying to understand whether this is a regression, a configuration issue, or a change in how Cursor validates certificates.

One more detail about my setup: I am using Cursor on macOS, while my actual development environment runs inside an Ubuntu-based Dev Container. The corporate CA certificate is available both on the macOS host and inside the Dev Container. On the host, it is installed in the OS trust store and also provided to Node via NODE_EXTRA_CA_CERTS. Inside the Ubuntu-based container, it is available through the OS trust store as well, using update-ca-certificates, and is also provided via NODE_EXTRA_CA_CERTS. This setup worked previously, so I am not sure whether the failure is happening on the macOS/Cursor side, inside the Dev Container, or specifically in the communication between Cursor and the container environment.

Thanks!

Steps to Reproduce

This is difficult to reproduce outside of a managed corporate network. The issue occurs in an environment where SSL/TLS decryption is active, using a corporate/self-signed CA certificate that is installed in the OS trust store and also provided via NODE_EXTRA_CA_CERTS.

Expected Behavior

Cursor should continue to trust the configured corporate CA certificate and allow chats, agent requests, and API calls to work as they did before the update.

Operating System

MacOS
Linux

Version Information

Version: 3.9.16 (Universal)
VS Code Extension API: 1.105.1
Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80
Date: 2026-06-27T06:41:01.941Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

Does this stop you from using Cursor

Yes - Cursor is unusable

I was able to fix my problem by checking http.experimental.systemCertificatesV2 in VS Code Settings (not in Cursor Settings, as suggested [here])(Certificate signature failure after recent update - #4 by Rezvan_Orlechuk) (http.systemCertificates was already checked)