ConnectError: SSLV3_ALERT_HANDSHAKE_FAILURE on macOS (arm64) — HTTP/2 broken

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hi team,
I am facing a persistent “Connection failed. If the problem persists, please check your internet connection or VPN” error when trying to use Chat/AI features.

The Issue:
The AI stream fails instantly with an SSL Handshake error. I have confirmed via Network Debugging that while REST API calls (like marketplace) return 200 OK, the gRPC streaming connection fails immediately.

Workaround & Performance Impact:
If I enable “Disable HTTP/2” in settings, the connection starts working. However, this is not a viable solution because the response latency becomes extremely high, making the IDE practically unusable for productive work. I need HTTP/2 for normal performance.

Steps to Reproduce

  1. Open Cursor IDE on macOS (Apple Silicon).
  2. Ensure “Disable HTTP/2” is unchecked in settings (default state).
  3. Try to send any message in the Chat or use Cmd+K.
  4. Observe the immediate “Connection failed” error.
  5. Check Developer Tools → Console to see the SSLV3_ALERT_HANDSHAKE_FAILURE error.

Expected Behavior

AI Chat should work via HTTP/2 without connection errors, as it did in previous versions.

Screenshots / Screen Recordings

vscode-app-1766066706889.txt (12.2 KB)

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.2.36
VSCode Version: 1.105.1
Commit: 55c9bc11e99cedd1fb93fbb7996abf779c583150
Date: 2025-12-18T06:25:21.733Z
Electron: 37.7.0
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 24.6.0

For AI issues: which model did you use?

All models (Claude 3.5 Sonnet, GPT-4o, etc.)

For AI issues: add Request ID with privacy disabled

Request ID: d0872b26-fbe7-4ebf-9105-dbeed22e4d9f
ConnectError: [internal] 1116693872384:error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE:../../third_party/boringssl/src/ssl/tls_record.cc:486:SSL alert number 40

at ezc.$streamAiConnect (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:12375:453365)
at async vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:585:89270
at async Object.run (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:12423:10221)
at async o (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:8815:1269)
at async Promise.allSettled (index 0)
at async $zr.run (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:8815:6560)

Additional Information

Error from logs (see attached file for full trace):
ConnectError: [internal] … error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE:../../third_party/boringssl/src/ssl/tls_record.cc:486:SSL alert number 40

Network: Direct home connection (No VPN, No corporate proxy, MTU verified/correct). This issue seems specific to the arm64 build’s SSL configuration.

Does this stop you from using Cursor

Yes - Cursor is unusable

1 Like
2

Hey @Max_R

Sorry you’re dealing with this.

I’ve seen a few similar reports with this SSL handshake failure on macOS. One thing that helped a user as a short-term fix is clearing the auth cache and TLS cache:

rm -rf ~/Library/Application\ Support/Cursor
sudo pkill -9 trustd

This deletes your app data, including extensions, themes, snippets, and installation-related data. Export your profile first to preserve this data.

Fair warning: this needed to be repeated daily for the user, so it’s definitely not ideal. But if it gets you unblocked, that would also help confirm there’s a related bug we need to dig into.

Let me know if that helps or if you’re still stuck.

2 Likes
3

Hey @Colin, thanks for the suggestion.

It worked! After clearing the cache (rm -rf ...) and killing trustd, the Chat is functioning correctly with HTTP/2 enabled.

However, as you mentioned, needing to do this daily (and losing all extensions/settings every time unless backed up) is a huge friction point. It makes the IDE extremely inconvenient to use long-term.

Since this confirms the issue is related to trustd/SSL cache corruption on macOS, could you please prioritize a proper fix in the next build? Maybe a way for Cursor to handle certificates more gracefully without requiring a full app reset?

I’ll monitor if it breaks again tomorrow and let you know.

1 Like
4

Hey @Max_R

Thanks for following up.

I’ll chase this down on my side – if it happens again tomorrow, do you mind trying the steps 1 by 1 (start with killing trustd) and see if doing only one of them helps?

1 Like
5

Thanks @Colin, I appreciate you looking into this.

Sure, if (or when) it breaks again, I will try only sudo pkill -9 trustd first and let you know if that’s enough to fix it without wiping the Application Support folder.

One critical detail regarding the full wipe:
I realized that wiping ~/Library/Application Support/Cursor also completely deletes the local Chat History. This is a major issue because I lose context for ongoing tasks, and re-creating those dialogues burns a lot of tokens (and $) daily.

So finding a fix that doesn’t require deleting the app data is super important. Fingers crossed that just killing trustd will be the magic bullet next time!

6

Having the same error on win11 on the latest stable Cursor. Http1.1/1.0 works. Previously (a month-two) http/2 (default mode) worked with no issues at all.

image
image841×898 34.4 KB

1 Like
7

Helped removing that old sh?t. Thanks!

8

Hey @Colin, bad news.

It happened again today (new day). As requested, I tried only killing trustd (sudo pkill -9 trustd) and restarting Cursor, but it did NOT help.

I am getting the exact same error immediately:
ConnectError: ... SSLV3_ALERT_HANDSHAKE_FAILURE ... SSL alert number 40
(Request ID: 33a1b027-a59a-4eaa-b06a-f1ebe633a68f)

This confirms that just resetting the macOS trust daemon is insufficient. The issue seems to be embedded in the corrupted files within ~/Library/Application Support/Cursor.

I really don’t want to wipe my Application Support folder again (and lose my chat history/tokens/settings) for the second day in a row. Is there any specific file inside that folder I could try deleting instead of nuking everything? Or a proper fix coming soon?

1 Like
9

@Max_R Thanks for testing! I’ve filed a ticket and gathered a few other reports. The symptoms are pretty consistent:

  1. Cursor works normally for a while on HTTP/2
  2. Connections start failing with the SSL handshake error (visible in Network diagnostics, error popups)
  3. The only fix (besides downgrading to HTTP/1.1) is nuking ~/Library/Application Support/Cursor
  4. Works again… until it doesn’t

@rumor If you’re on Windows, try a clean reinstall by removing these files/folders (from the troubleshooting guide):

Windows: Run these commands in Command Prompt:

rd /s /q "%USERPROFILE%\AppData\Local\Programs\Cursor"
rd /s /q "%USERPROFILE%\AppData\Local\Cursor"
rd /s /q "%USERPROFILE%\AppData\Roaming\Cursor"
del /f /q "%USERPROFILE%\.cursor*"
rd /s /q "%USERPROFILE%\.cursor"
10

Are you seriously suggesting switching to HTTP/1.1 or deleting the entire history on which you also earned a commission as an intermediary between AI models instead of providing an actual solution?
The forum is flooded with this issue and Cursor team are doing nothing about it.

1 Like
11

Hey @pavds

I’m suggesting them as temporary fixes while we dig into the root cause, not as permanent solutions.

I’ve flagged this thread internally to make sure it stays on the team’s radar.

12

try change dns servers

13

Hey, @Colin, are there any updates on that? I had to use the HTTP/1.1 solution, and sometimes it’s so slow that it prevents me from productive coding. I really like Cursor, but this issue is forcing me to investigate other IDEs, unfortunately.