after update from cursor 3.19 to 3.20 , could not use any model , and also in test of network , none worked , 1.1,1.0,2.0 none , so i logged out to log back in and test now , i can’t also log back in , even though i can login fine on the web . but not the IDE , click return to cursor after sign-in , and nothing happens !
Steps to Reproduce
update from 3.19 to 3.20 on arch OS
Expected Behavior
nothing working , can’t re-login so can’t troubleshoot further
Hey, thanks for the report and the new screenshots. They give an important clue.
The diagnostics didn’t fail completely. Green checks (passing) are DNS, Authentication UI, Cursor Tab, and Agent Endpoint. Red checks with Failed to fetch are Marketplace, Authentication (this is a separate check, not the same as Authentication UI), Downloads, and CDN. So your machine can reach some of our domains, but not others. The IDE login is most likely failing because the Authentication check is failing.
This kind of partial result usually points to an issue with specific domains, like network, DNS, proxy, firewall, or SSL inspection, not a full network outage. A terminal curl test can show if an endpoint is reachable outside Cursor, but it doesn’t prove the full app authentication flow will work. If you’re using a proxy, also try Cursor in HTTP/1.1 mode and fully restart the app.
Here’s what to check in order. Please tell me at which step anything changes.
If you have a VPN, a per app firewall (OpenSnitch, Portmaster, etc), or an allowed apps list or split tunneling, temporarily disable it (or test on a phone hotspot), then fully quit and reopen Cursor and click Log In. If your firewall uses per application rules, check if there’s a separate allow rule for the new Cursor binary (after updates the file changes).
Cursor Settings > Network > Required Domains > Copy Domains, then add those domains to the allowlist in your firewall, proxy, or VPN. Main groups are *.cursor.sh, *.cursor-cdn.com, *.cursorapi.com (and for Grok Bot also *.cursorvm.com and *.*.cursorvm.com).
Cursor Settings > Network > HTTP Compatibility Mode > switch to HTTP/1.1, fully restart Cursor, then run Network Diagnostics again. In proxy setups, some transport paths can fail even if some services work.
In your terminal, run this and tell me what status code you get:
404 is a useful sign that the endpoint is reachable from the terminal, but it still doesn’t prove the full auth flow works in the app. If curl fails completely, your VPN or network is blocking it.
5. Let me know how you installed Cursor on Arch (AUR package, AppImage, or something else) and whether the email in the IDE matches your forum email.
i do use vpn and portmaster , but have used it with cursor for years now , because i have cursor excluded from both the vpn and portmaster . i even have now tested with complete shutdown of portmaster and vpn , issue persist , with the 3.19 i can login , from 3.20.10 or the new .17 issue persist .
rebooted system , router etc , everything else works perfectly except cursor 3.20 above
Thanks for the detailed test. The curl with 404 plus read ECONNRESET in Diagnostics is exactly what helps narrow this down. From your screenshot I see DNS, Authentication UI, Cursor Tab, and Agent Endpoint are green, but HTTP/2, SSL, API, Ping, Chat, and Agent fail with read ECONNRESET.
A 404 from curl means your machine can reach us. But the app itself gets ECONNRESET connection reset on encrypted channels. A reset that hits the app but not curl usually means something is breaking the app’s encrypted or HTTP/2 connections. The two most common causes are a local app firewall like Portmaster, especially after an update when the binary changed, and a network or proxy that doesn’t handle HTTP/2 well. In that case curl works, but Cursor’s gRPC streams don’t.
First, a quick HTTP/2 test:
Cursor Settings > Network > HTTP Compatibility Mode > switch to HTTP/1.1, fully restart Cursor, then run Diagnostics again. If ECONNRESET goes away on HTTP/1.1, it’s a network or proxy issue, not Portmaster.
If that doesn’t help, let’s check Portmaster. Two important details:
Closing Portmaster from the tray or UI does not stop it. The core service portmaster-core keeps running as a system service and filters at the kernel level. To actually disable it for a test run:
sudo systemctl stop portmaster
If you have a separate Portmaster DNS service, stop that too. Then fully quit Cursor and open it again.
An update replaces the Cursor binary. Your old Portmaster exception and any VPN split tunnel are tied to the old file and won’t match the new 3.20 binary, so the new binary can be treated as unknown and blocked even if it looks like an exception exists. That matches what you’re seeing, DNS is green but TLS connections fail.
What to check:
In Portmaster, open Network Monitor and find the Cursor process. Check if it has blocked connections. Look for a gray bar or red dot and Applied Setting. If yes, set it to Allow or create a fresh allow rule for the new 3.20 binary.
In Terminal run env | grep -i proxy and tell me if it prints anything.
In Cursor Settings, find Http: Proxy Support, set it to on, then fully restart Cursor.
Main confirmation step: if you fully stop the Portmaster service using systemctl, not just closing the window, and also disable VPN, then try HTTP/1.1, and the problem still stays, tell me. That changes the picture and then we’ll dig deeper with logs.
