Cursor Sign-In Domains: What to Allowlist Before October 30

The sign-in page is moving. Cursor sign-in now runs on accounts.spacex.ai and accounts.x.ai, replacing authenticator.cursor.sh as the sign-in page. The Cursor app, the website and your SSOSingle Sign-On. One company login (usually via SAML or OIDC) instead of a separate password per tool. Press Enter for the full definition. tiles keep working, and nobody gets logged out.

So for most people this is invisible. The group it reaches is anyone behind a firewall or proxy allowlist, Zscaler being the example Cursor gives, because those networks only let through the hosts someone has written down. If accounts.spacex.ai or accounts.x.ai are blocked on your network, sign-in falls back to the old page for now, which is why nobody is locked out yet.

The fallback is the part that makes this easy to miss. Everything works today on a network that blocks the new hosts, so nothing prompts anyone to fix it, and the first signal is probably a wave of failed sign-ins on the 30th. Cursor recommends adding the domains as soon as you can, so your users get the new sign-in page from day one.

Cursor's advice is to prefer wildcards, so you do not have to update the list later. Five patterns cover the new sign-in hosts and the related auth hosts behind them.

The last three rows are the ones a network reviewer is likely to query, since grok.com and grokipedia.com do not look like Cursor hosts. The reasons sit in Cursor's own list: grokusercontent.com serves user-generated Grok content, and Grokipedia shares Grok accounts, so its auth host belongs to the same sign-in system. Put that sentence in the change ticket and it will probably save a round of questions.

If your policy will not allow wildcards, Cursor lists a minimum set of hosts instead. Six entries is a short ticket, though the wildcard route is the one Cursor recommends, and it is the one that saves you a second change request if another auth host turns up.

• accounts.x.ai
• accounts.spacex.ai
• auth.x.ai
• auth.grok.com
• auth.grokusercontent.com
• auth.grokipedia.com

None of this replaces the existing Cursor entries. These are unchanged and still required for Cursor itself: .cursor.sh (which includes authenticator.cursor.sh), .cursor-cdn.com, .cursorapi.com, and .cursorvm.com with .*.cursorvm.com. Keep them where they are and add the new ones alongside. The wider proxy and SSL inspection picture is in enterprise network configuration.

Less than the domain list might suggest. The firewall is the only required change, and Cursor's notes for IT are mostly a list of what stays the same.

One small job is worth doing at the same time. If your team has bookmarks or internal docs that point to authenticator.cursor.sh, update them to accounts.spacex.ai and accounts.x.ai. That is, I'd say, the easiest item to forget, since an onboarding page with the old link will keep working right up until the fallback goes away.

If login fails and your network uses an allowlist, the fix runs through IT rather than through Cursor settings.

1. 1Have IT add the domains above to the firewall or proxy allowlist.
2. 2Retry sign-in from accounts.spacex.ai or accounts.x.ai.
3. 3Or retry from your existing IdP or authenticator.cursor.sh.

Before October 30 the old page is still a working route, so a user who is stuck can usually get in while the ticket is open. After that date the allowlist is the only route, which is the real argument for doing it this week rather than waiting for the first report.