Built-in browser returns 'denied' for the loopback-network permission, which blocks Okta FastPass sign-in

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Okta FastPass sign-in fails in Cursor’s built-in browser. The page shows: “Okta FastPass requires network permission. Unable to sign in. The browser is blocking communication with Okta Verify.”

Okta Sign-In Widget 7.49.0 checks Local Network Access by querying the loopback-network permission first. On identity-provider hosts, Cursor’s preload overrides navigator.permissions.query and returns granted for local-network-access and local-network, but not for loopback-network. That query falls through to the session permission handler, which doesn’t allow loopback-network, so it returns denied. The widget then throws CHROME_LOCAL_NETWORK_ACCESS_DENIED_ERROR before it tries to reach Okta Verify.

Steps to Reproduce

  1. In Cursor’s built-in browser, open an Okta-protected SAML sign-in URL on https://<org>.okta.com/.
  2. Choose Okta FastPass. The error card appears.
  3. Open DevTools on that page and run:
    (await navigator.permissions.query({name: 'loopback-network'})).state
    The result is 'denied'.

Console error:

Uncaught (in promise) CHROME_LOCAL_NETWORK_ACCESS_DENIED_ERROR: Chrome Local Network Access permission was denied for FastPass.
    at g (ChallengeViewUtil.js:96:9)
    at ChallengeViewUtil.js:113:7
    at ChallengeViewUtil.js:138:34
    at BrowserFeatures.ts:108:5

Expected Behavior

On the identity-provider hosts where Cursor’s preload already returns granted for local-network-access and local-network, it should return granted for loopback-network too. The browser view session’s permission handlers should also allow loopback-network. With both changes, the Okta widget would go on to contact Okta Verify.

Operating System

MacOS

Version Information

Version: 3.22.12
VS Code Extension API: 1.128.0
Commit: 3a92974361033b2051526321308c2740fe5912c0
Date: 2026-09-26T04:55:12.125Z
Build Type: Stable
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
OS: Darwin arm64 25.5.0 (macOS 26.5.1)

Additional Information

  • out/vs/platform/browserView/electron-main/preload-browser.js overrides navigator.permissions.query on identity-provider hosts (.okta.com, .duosecurity.com, .login.microsoftonline.com, and others). It returns granted only when descriptor.name is local-network-access or local-network.
  • out/vs/workbench/contrib/composer/browser/preload-webview-browser.js has the same override with the same two names.
  • In out/main.js, the browser view session’s setPermissionRequestHandler and setPermissionCheckHandler allow only ["pointerLock","clipboard-sanitized-write","local-network"].
  • No file under out/ mentions loopback-network.
  • Okta Sign-In Widget 7.49.0 (BrowserFeatures.getChromeLNAPermissionState) queries loopback-network first. It falls back to local-network-access only if that query throws.

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

Hey @Avi_Berkowitz, thanks for the detailed report! Your analysis is spot on, and this is an issue we’re tracking.

For now, finish Okta sign-ins in your regular browser. Either right-click the link in Agent chat and choose Open in External Browser, or open the app URL in Chrome or Safari directly. FastPass should work there as usual.

I’ll post here when there’s an update.

8

Thank you. If this is helpful, one observation:

  1. Historically, it worked without issue
  2. Starting about a week or two ago, it would fail, but would then work on page refresh
  3. Now it doesn’t work at all