Desktop app stuck on login screen after successful browser authentication

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After logging in via the browser, the browser confirms “All set! Feel free to return to Cursor.” but the desktop app still shows the Log In / Sign Up screen. The app never picks up the authenticated session, even after closing and reopening it.

Steps to Reproduce

  1. Open Cursor
  2. Click “Log In”
  3. Browser opens automatically, complete login there
  4. Browser shows “All set! Feel free to return to Cursor.”
  5. Return to the desktop app — it still shows the Log In screen

Expected Behavior

The desktop app should automatically detect the successful login and show the logged-in state.

Screenshots / Screen Recordings

{360FAB72-6B79-4F57-8A07-2D643185D183}.png
{360FAB72-6B79-4F57-8A07-2D643185D183}.png1920×1080 121 KB

Operating System

Windows 10/11

Version Information

IDE: Cursor 3.9

Additional Information

Already tried: reinstalling completely (both regular User Installer and System Installer for x64, run as administrator), completely disabling Windows Firewall for both private and public networks, checking proxy settings (none active), checking for VPN interference (tested with Radmin VPN closed). Also verified the cursor:// protocol works — manually opening it via Win+R does launch the app. None of this resolved the issue.

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report. This is a known Windows case: the web login succeeds All set!, but the desktop app doesn’t pick up the session. You’ve already tried almost everything, but it looks like you haven’t touched the main lever yet: the Http: Proxy Support setting.

By default it’s set to override, and if http.proxy is empty, Cursor won’t use the proxy at all. On Windows this often breaks the local auth callback. Try this:

  1. On the login screen, press Ctrl+Shift+, (Settings can be opened even without signing in).
  2. In Settings search, type proxy support.
  3. Change Http: Proxy Support from override to on.
  4. Fully restart Cursor and sign in again.

If the Settings UI isn’t available for some reason, you can edit it directly: open %APPDATA%\Cursor\User\settings.json and add "http.proxySupport": "on", then restart.

If that doesn’t help:

  • Run Cursor once as an administrator and try logging in again.
  • Try a different network, like a mobile hotspot. This rules out a corporate or ISP filter that silently drops callback traffic.
  • Check your antivirus or endpoint security. It can intercept localhost or HTTPS even if the firewall is off.

Detailed root cause write-up: OAuth login silently fails behind local proxy — fix is changing one default setting

Let me know what worked. If nothing did, we can dig deeper.

6

Thanks for the detailed suggestion! I tried changing http.proxySupport from override to on in settings.json, fully restarted Cursor, and attempted login again — unfortunately the issue persists. The desktop app still shows the Log In screen after the browser confirms “All set! Feel free to return to Cursor.”

I also tried:

  • Running Cursor as administrator
  • Attempting to test on a different network (mobile hotspot via iPhone), but ran into connectivity issues getting the hotspot itself to reach the internet properly, so wasn’t able to fully complete that test
  • Confirmed Windows Firewall is still fully disabled (both private/public networks)
  • No proxy or VPN active (Radmin VPN fully closed via Task Manager)

Would appreciate any further ideas — happy to try more diagnostics or share additional logs/screenshots if helpful.

7

Thanks for going through all the steps and writing everything up in detail. Since proxy support on, running as admin, and disabling blockers didn’t help, and cursor:// works via Win+R, it means the handler is registered, so we need to dig deeper. Let’s narrow it down.

  1. Gather console logs. Try to log in, then open Help > Toggle Developer Tools, go to the Console tab, and send whatever errors show up during or after login. Lines mentioning cursor-socket, access token, or auth are especially useful. This will show whether the login flow reaches the app at all, or if the UI just doesn’t update.

  2. Do a full clean reinstall and remove the profile folders too (a normal reinstall doesn’t touch them, which is why previous attempts didn’t help):

    • Fully close Cursor
    • Uninstall via Windows Settings > Apps
    • Manually delete these folders (back them up first just in case):
      • %LOCALAPPDATA%\Programs\cursor\
      • %APPDATA%\Cursor\
    • Download the latest version from Cursor · Download and reinstall

  3. A couple questions: is this a work or corporate PC with managed policies (MDM or Group Policy)? And what exact Cursor version are you on (Help > About)?

If you can, please finish the test on a different network too, like a mobile hotspot. That rules out an ISP or network filter that silently blocks callback traffic.

Send the results from steps 1 and 2. The console logs and the behavior after a clean reinstall should make it clear where to look next.

8

Thanks for narrowing it down. Unfortunately I wasn’t able to get to the developer console — pressing Alt doesn’t reveal a menu on the login screen, and F12 / Ctrl+Shift+I don’t open anything either.

I did do a full clean reinstall, including manually deleting both %LOCALAPPDATA%\Programs\cursor and %APPDATA%\Cursor before installing the latest version fresh (installer: CursorSetup-x64-3.9.16.exe). Unfortunately the issue is exactly the same — browser confirms “All set!” but the desktop app stays on the Log In screen.

To answer your questions: this is a personal PC used for study and personal use, not a work/corporate machine — no MDM or Group Policy that I’m aware of.

I wasn’t able to fully test on a different network either — tried a mobile hotspot via iPhone but ran into connectivity issues getting the hotspot itself online.

Let me know what else I can try or check.

9

Thanks for going through everything on the list and writing it up in such detail. Since the standard steps didn’t help, and cursor:// works via Win+R, that means the handler is registered. The issue is that the callback or poll traffic isn’t reaching the app. Let’s grab logs another way and narrow it down.

Logs from disk since Developer Tools won’t open

  1. Try to log in, get to All set!, then return to the app.
  2. Open %APPDATA%\Cursor\logs. Inside you’ll see folders named by date and time. Open the newest one.
  3. Send main.log from there and the contents of the subfolder with renderer or window logs. Lines about auth, access token, cursor-socket, poll, plus any network errors like ERR_..., timeout, refused are the most useful.

As an alternative, run Cursor from PowerShell with verbose logging so we can capture console output:

& "$env:LOCALAPPDATA\Programs\cursor\Cursor.exe" --verbose

Then send whatever prints during the login attempt.

A couple questions

  • What antivirus or security software are you using? A lot of them like Kaspersky, ESET, Avast or AVG web shield, Bitdefender can intercept HTTPS or localhost traffic even if the firewall is off. That can silently break the callback. If you have one, try fully quitting it temporarily, not just the firewall, but also web or SSL inspection, then try logging in again.
  • Check the hosts file C:\Windows\System32\drivers\etc\hosts. Do you see any entries related to cursor.com or cursor.sh?

Also, if you can, please test on another network like a proper hotspot or different Wi-Fi. That quickly rules out network filtering.

Send the logs from step 1 and your antivirus info. From that we’ll see whether the login is reaching the app at all, or if the UI just isn’t updating.

10

Thanks for the guidance on getting logs from disk. Here’s what I found:

main.log:

error #1: https://api2.cursor.sh/updates/api/update/win32-x64/cursor/3.9.16/... - error undefined net::ERR_CONNECTION_RESET
update#isLatestVersion(): failed to check for updates
Error: net::ERR_CONNECTION_RESET

renderer.log (during the login attempt):

2026-07-06 16:11:08.629 [error] [aborted] read ECONNRESET: ConnectError: [aborted] read ECONNRESET
    at async Object.availableDocs (...)
2026-07-06 16:11:08.634 [error] Error fetching user privacy mode: [aborted] read ECONNRESET
2026-07-06 16:11:08.636 [error] Error fetching user pricing info: [aborted] read ECONNRESET
2026-07-06 16:11:08.638 [error] [aborted] read ECONNRESET: ConnectError: [aborted] read ECONNRESET
    at async Object.availableModels (...)
2026-07-06 16:11:08.641 [error] [aborted] read ECONNRESET: ConnectError: [aborted] read ECONNRESET
    at async Object.getEmail (...)
    at async gnt.getEmailAndSignUpType (...)
2026-07-06 16:11:47.484 [error] Failed to fetch: TypeError: Failed to fetch

So it looks like the actual account/email fetch after login (getEmailAndSignUpType) is the specific call that’s failing with ECONNRESET — this seems to be exactly where the login flow breaks down. The browser-side OAuth completes fine, but every subsequent API call the app makes (pricing info, privacy mode, email/signup type, model list, docs) gets reset.

Ping test:

ping api2.cursor.sh
100% packet loss (all 4 requests timed out)

TCP port test:

Test-NetConnection api2.cursor.sh -Port 443
TcpTestSucceeded: True

So the TCP handshake on 443 succeeds, but something resets the connection afterward (likely during/after TLS, or right after the response starts).

Hosts file: completely clean, no entries for cursor.com or cursor.sh.

sfc /scannow: ran as admin, no integrity violations found.

Important detail I should mention: I’m running a “lite”/debloated Windows build (Defender was stripped out — Virus & Threat Protection doesn’t even appear in Windows Security, only Firewall & Device Security show up). This might be very relevant since these builds sometimes remove or alter networking components (TLS libraries, WinHTTP, root certificates, etc.) that could affect Electron apps specifically, while leaving basic TCP connectivity and standard browser HTTPS unaffected.

I don’t have any third-party antivirus, VPN, or proxy active. Firewall fully disabled on both network profiles. Radmin VPN fully closed via Task Manager. Tried testing on a different network too but couldn’t get a working mobile hotspot connection to complete that test.

Given all this — especially the consistent ECONNRESET on every app-initiated API call right after a successful browser login — would you say this points to something specific I could check/fix on this Windows build (missing root certs, a broken WinHTTP/Schannel component, etc.), or is a clean reinstall of a standard (non-debloated) Windows the most realistic fix at this point?

11

Great job with the logs. That’s exactly what we need to narrow this down.

Your conclusion is correct: OAuth in the browser works, but every follow-up call the app makes like getEmailAndSignUpType, pricing, privacy mode, and so on fails with ECONNRESET. Because of that, login can’t finish since the app can’t fetch the account data.

Here’s what’s going on: in Cursor 3.9.16 these requests go through a new connection path that uses HTTP/2 by default. If HTTP/2 traffic gets reset in your environment, all those calls drop and login gets stuck. The browser still works because it uses its own TLS stack, not the system components.

Try forcing HTTP/1.1. Since Settings and Dev Tools won’t open on the login screen, edit settings.json directly:

  • Fully close Cursor.
  • Open %APPDATA%\Cursor\User\settings.json.
  • Add:
    {
  "cursor.general.disableHttp2": true
}
  • Fully quit and start it again, restart the process, not Reload Window, then try logging in.

If this removes the ECONNRESET errors, the issue is the HTTP/2 path, and it’s a known 3.9.x regression with no ETA for a fix yet.

If it doesn’t help, your point about a debloated or lite Windows build with Defender removed matters. Those builds often break network or TLS components like Schannel, WinHTTP, root certificates. HTTP/2 in Node or Electron can fail because of that, even if normal browser traffic works. In that case, the most realistic fix is a standard non debloated Windows install or restoring the missing network components.

As a stopgap, you can roll back to 3.8.24. It still uses the old network path from before this transport change. You’ll miss updates, but login should work.

Let me know if disableHttp2: true fixes it. That decides what to check next.

12

Thanks so much for all the help digging into this — really appreciate the detailed troubleshooting. Given everything we found (the debloated/lite Windows build missing Defender and likely other networking components, the consistent ECONNRESET on every app API call, HTTP/2 issues), I think a clean reinstall of a standard Windows build is the most realistic path forward rather than continuing to chase it on this setup.

I’ll do a full Windows reinstall when I get a chance and follow up if the issue persists afterward. Thanks again for the thorough help!