Built-in Browser / Design Mode: IdentityServer login fails with CSRF (cookies not persisted) — works in Chrome

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Built-in Browser / Glass / Agents Window + Design Mode

Describe the Bug

Login in the Cursor built-in browser always fails against an ASP.NET Core IdentityServer with the CSRF error page (/error/csrf — “There was a problem with the form you submitted”), even with correct credentials and a fresh form.

The same OIDC login flow works in Google Chrome.

This is not a missing IdentityServer / IdP client configuration issue. Chrome proves the IdP setup is fine. No window.open popup OAuth is involved — this is a normal full-page redirect + form POST login.

Expected: Top-level navigation to IdentityServer should accept Set-Cookie (including HttpOnly + SameSite=Strict antiforgery cookies), send them on the login POST, and complete OIDC back to the local app (https://localhost:…/signin-oidc). Design Mode should then work on the authenticated local app.

Actual:

  • Login form POST → CSRF error
  • Session / antiforgery cookies for the IdentityServer host are not reliably stored or sent in the Cursor Browser cookie jar
  • Simple document.cookie writes can work, but server Set-Cookie for HttpOnly/Strict cookies does not behave like Chrome
  • CDP cookie APIs (Network.getCookies / Network.setCookie / Storage.clearDataForOrigin) are denied — agents cannot repair the session
  • Writing cookies into ~/.config/Cursor/Partitions/cursor-browser/Cookies does not affect the live Glass browser session

Steps to Reproduce

  1. Run a local HTTPS app that challenges OIDC to an ASP.NET Core IdentityServer (antiforgery cookies with SameSite=Strict; Secure; HttpOnly).
  2. Open https://localhost:<port>/ in Cursor Browser.
  3. On the IdentityServer login page, submit username/password.
  4. Observe redirect to /error/csrf.
  5. Repeat in Chrome with the same URL → login succeeds.

Expected Behavior

First-party top-level navigations in the built-in browser should persist and send cookies like Chromium/Chrome (including HttpOnly + SameSite=Strict), so standard enterprise OIDC form login and Design Mode work.

Screenshots / Screen Recordings

N/A (CSRF error page on IdentityServer after login POST)

Operating System

Linux (Ubuntu 24.04)

Version Information

Cursor 3.17.19 (Linux x64)

Regression note: login in Cursor Browser worked ~1–2 weeks ago. This machine upgraded through 3.16.x → 3.17.19 in that window (Glass / Agents Window changes).

Additional Information

Impact: Design Mode is unusable for authenticated enterprise apps behind OIDC/CSRF login. Related community reports cover popup OAuth (Google/MSAL); this report is specifically redirect-based form login + SameSite=Strict antiforgery cookies.

Please treat cookie persistence/sending in the built-in browser as a regression and align with Chrome for first-party top-level navigations. Optionally expose safe CDP cookie APIs for the embedded browser so agents can diagnose/fix sessions.

5

Hey @Alexander_Finkbeiner, thanks for the detailed report.

We rebuilt this exact flow to test it (top-level redirect into an IdP that sets a Secure, HttpOnly, SameSite=Strict antiforgery cookie, then a same-site form POST) in the built-in browser on Linux, and the cookie was stored and sent correctly, so the login completed. That points at something specific to your browser profile state or the certificate trust for your IdentityServer host rather than cookie handling in general.

A couple of things to try:

  1. In the browser tab, open the “…” menu and run Clear Cookies, Clear Cache, and Clear Certificates, then retry the login in a fresh tab.

If it still fails after a full reset, could you share:

  • the exact Cursor version where the login last worked
  • whether the IdentityServer is on localhost or a separate host, and whether you see a certificate warning page for it in the built-in browser

One note on the CDP side: cookie APIs like Network.getCookies and Network.setCookie are intentionally not available to agents in the built-in browser for security reasons, so that part is expected behavior.

7

Hey Colin — thanks for the pointer.

We cleared the built-in browser state (Cookies, Cache, and related security/network state for the Glass cursor-browser partition) and retried. Login against our IdentityServer works again in the Cursor browser on 3.18.9 (Linux).

So this looks consistent with your read: profile/session state, not a general failure of antiforgery cookie handling. We don’t have a precise root cause beyond that (we couldn’t inspect HttpOnly cookies via agent CDP — as you noted, those APIs are intentionally blocked).

A few details that may still be useful:

  • IdP host: separate from the app (public CA cert; no cert warning observed after the reset).
  • App: https://localhost:… with a dev self-signed cert.
  • Flow is classic top-level OIDC redirect + form POST (no window.open).
  • Same flow continued to work in Chrome throughout.

If it regresses, we’ll capture whether a cert interstitial appears and which Clear action is required. Happy to re-test anything on your side.

Thanks again.