Browser not working with google SSO

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor does not let the user use google SSO to log in to an app. No matter how you do it, it will not work. This bug has existed since the release of the browser feature.

Steps to Reproduce

  1. Create a project with google authentication (e.g GitHub - mmraja83/google-auth-website: A professional, production-ready boilerplate for a web application featuring Google SSO and Email/Password Authentication. Built with React (Vite) and Python (FastAPI), designed with a "Soft Minimalism" aesthetic. · GitHub)
  2. run the app
  3. go to the generated localhost link from within the IDE (browser)
  4. try to sign in
  5. it will get stuck after clicking allow in the consent screen

Expected Behavior

It should log in to the app

Operating System

MacOS

Version Information

Version: 3.0.12
VSCode Version: 1.105.1
Commit: a80ff7dfcaa45d7750f6e30be457261379c29b00
Date: 2026-04-04T00:13:18.452Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

Additional Information

I cannot use this feature that I am paying for.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Hey, thanks for the report. This is a known limitation of Cursor’s built-in browser. It runs as a sandboxed Electron webview, which blocks window.open(). Google OAuth uses a popup-based flow, so after the consent screen nothing happens.

For now, the workaround is to open the localhost URL in a regular browser like Chrome, Safari, or Firefox. Google Sign-In should work right away.

I’ve passed this on to the team. There’s no ETA yet, but your report helps with prioritization.

Hello, this is not a workaround. Is there any workaround to be able to use this feature ?

Unfortunately, there aren’t any other options inside the built-in browser right now. The issue is that Google OAuth uses a popup window.open(), and the sandboxed Electron webview blocks it. This isn’t something you can fix with a setting, it needs changes to the browser tool itself.

It’s crazy that this is still not solved. Most of the B2B companies out there rely on Google login, and a large part of them as the primary login option. Right now I can’t even use cursor browser and its Design mode, due to this limitation. Such a shame

Hey @yjallouli, this is a known bug, and we already have an issue open for it (see above in the thread). I can’t share a fix timeline yet since the ticket is in the backlog with low priority, and follow-up reports like yours really help us reconsider that, especially given the B2B case with Google login + Design mode.

For now, the only workaround is to open localhost in a regular browser like Chrome, Safari, or Firefox. The OAuth flow works fine there. I know that’s not a real option for Design mode. If there’s any update on a fix, I’ll post it here.

During development, add “Email link (passwordless sign-in)” also as a sign-in method for localhost. It will work in Cursor Browser.

I want to add that this is also a problem for MSAL with Azure. This issue isn’t limited to Google SSO and is likely impacting a huge portion of users who use any kind of enterprise sign in solution.

@zackttaylor, good catch. The root cause isn’t specific to Google. The built-in browser blocks window.open() popups in a sandboxed Electron webview, so any popup-based OAuth flow breaks the same way, including Google, Microsoft MSAL, and many enterprise IdPs. I’ll expand the ticket scope internally so this is clearly captured. Thanks for the datapoint, the B2B impact really helps with prioritization.

No ETA for a fix yet. The workaround is the same, open the localhost URL in a system browser like Chrome, Safari, or Firefox. For MSAL specifically, if you control the app registration, you can temporarily switch from the popup flow to the redirect flow, use loginRedirect instead of loginPopup. That will work in the built-in browser until the fix lands.