Error_not_logged_in

[Isabela_Dranka]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

ERROR_NOT_LOGGED_IN after every chat message on multiple devices

Hi Cursor team,

I’m experiencing a persistent authentication issue that started on 06/17/2026 afternoon and has not been resolved since.

Symptoms

• I can log in successfully.

• The Cursor UI shows me as logged in.

• As soon as I send a message in Chat, the request fails with:

  • ERROR_NOT_LOGGED_IN
  • Authentication error
  • If you are logged in, try logging out and back in.

• After every message, I am effectively forced to log in again.

Request ID
f4a1a2b7-9524-4676-b252-e2162cafe340
0f14281e-d647-466c-83b2-7081ee9f9e72

Troubleshooting already attempted

• Logged out and back in multiple times.
• Deleted Cursor credentials from Keychain (macOS).
• Reinstalled Cursor.
• Tested with and without VPN.
• Verified system date and time.
• Cleared local authentication/cache data.
• Updated to the latest Cursor version.

Important finding
The exact same issue occurs on a completely different machine:

• MacBook (primary machine)
• Windows PC

Since the problem reproduces across different operating systems and installations, it appears to be account-related or a backend authentication/session issue rather than a local environment problem.

Stack trace excerpt

ERROR_NOT_LOGGED_IN

Authentication error
If you are logged in, try logging out and back in.

ActionRequiredError: Authentication error
If you are logged in, try logging out and back in.

runAgentLoop
streamFromAgentBackend
getAgentStreamResponse
submitChatMaybeAbortCurrent

Could someone please check whether there is an issue with my account authentication, session state, or token refresh process?

Thank you.

Steps to Reproduce

Open Cursor.
Sign in successfully.
Open any chat (new or existing).
Type a message and send it.
Wait for the request to be processed.
The request fails immediately with:
ERROR_NOT_LOGGED_IN
Authentication error
If you are logged in, try logging out and back in.
The issue occurs on every subsequent message.

Expected Behavior

The message should be processed normally and receive a response.

Actual behavior

Every message fails with ERROR_NOT_LOGGED_IN.
Cursor still appears logged in through the UI.
Logging out and back in does not resolve the issue.
The problem persists across application restarts, reinstalls, different Cursor versions, macOS and Windows.

Operating System

MacOS

Version Information

Version: 3.8.11 (Universal)
VS Code Extension API: 1.105.1
Commit: e56ad3440df06d22ca7501e65fd518e905486ef0
Date: 2026-06-18T01:40:18.333Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

For AI issues: which model did you use?

Auto, Composer 2.5 fast

For AI issues: add Request ID with privacy disabled

f4a1a2b7-9524-4676-b252-e2162cafe340
0f14281e-d647-466c-83b2-7081ee9f9e72

Additional Information

I tested multiple Cursor versions and the issue persists across all of them:

Latest stable version available at the time of testing
Previous version downloaded from the GitHub releases page
Fresh installations on both macOS and Windows

The behavior is identical in all cases:

Login succeeds
The UI shows me as authenticated
Sending any chat message results in:
ERROR_NOT_LOGGED_IN
Authentication error
If you are logged in, try logging out and back in.

Because the issue reproduces across:

Multiple Cursor versions
macOS and Windows
Fresh installations
Different local authentication stores

I suspect this may be related to my account state, authentication session, token refresh flow, or a backend-side issue rather than a local installation problem.

Does this stop you from using Cursor

Yes - Cursor is unusable

[deanrie]

Hey, thanks for the detailed report. I dug into this, and from the backend side your account looks totally fine and is actively authenticating. Requests go through successfully, and we haven’t seen any auth denials on our side in the last few days. So this isn’t an account-level block.

What’s actually happening: the ERROR_NOT_LOGGED_IN error is thrown client-side while the agent is running, not by the backend. This looks like an intermittent break during short-lived token refresh. The IDE caches the session, so the UI shows “logged in”, but the per-request token is temporarily unavailable right when the request is sent. The two request IDs you shared never reached our backend at all, which confirms the problem happens before the request is sent.

Things to try:

1. Fully Sign Out via Cursor Settings (not the button in the prompt that shows the error), then fully quit Cursor and sign back in.
2. Test without proxy or VPN, or on a different network. Your traffic is going through a cloud egress IP, and a proxy or firewall that intermittently strips the Authorization header to our API causes exactly this symptom. This is worth digging into further. Even when you tested “without VPN”, the requests were still going through the cloud egress.
3. Update Cursor to a version newer than 3.8.11.

If it still fails on every message after that, grab a fresh Request ID right at the moment of the error (Chat context menu in the top right > Copy Request ID) and send it here. The previous two don’t show up in our logs, and a fresh one will help us pinpoint exactly where the chain breaks.

[Isabela_Dranka]

Thanks for looking into this.

I collected additional information from the Cursor DevTools console and found several authentication-related errors that occur at the exact moment the chat request fails.

Latest Request ID:

6e5427fa-2396-43f6-8ce2-219a4a002ea6

Console output shows:

ConnectError: [unauthenticated] Error
ERROR_NOT_LOGGED_IN

Additionally, I consistently see:

ExperimentRefreshService: StatSig bootstrap from server failed

and

method: "BootstrapStatSig"
service: "aiServer.v1.AnalyticsService"

Other details from the logs:

client_version: 3.8.11
channel: stable
platform: darwin
requestId: not-found

The error appears before any chat request reaches the backend, which seems consistent with your observation that previous request IDs never appeared in your logs.

I also tested:

• macOS corporate machine

• Personal Windows PC

• Home Wi-Fi

• Mobile hotspot

The issue reproduces in all environments.

Given the DevTools output, could the problem be related to StatSig bootstrap, token refresh, or another authentication dependency failing before the agent request is created?

I’m happy to provide additional console logs if needed.

I’m attaching DevTools screenshots showing the client-side ConnectError: [unauthenticated], ExperimentRefreshService: StatSig bootstrap from server failed, and requestId: not-found logs that happen at the same time as the chat authentication error.

[deanrie]

Thanks for the fresh Request ID and logs, they’re pretty telling.

The new one is still coming in with requestId: not-found, which means the request still isn’t reaching our backend. Even more importantly, BootstrapStatSig is also failing with [unauthenticated]. That’s a basic startup call and it’s not related to chat. If even that doesn’t go through, it means the client isn’t attaching a valid auth token to any outgoing request, not just chat messages. This is fully client-side and happens before the request is sent. That matches the fact that the previous Request ID didn’t show up in our logs.

The fact that it now reproduces even on a mobile hotspot makes the proxy or VPN theory less likely. So let’s check two things on the client:

1. Launch Cursor with extensions disabled: run cursor --disable-extensions in Terminal. If an extension like a network or proxy interceptor is stripping the Authorization header, that would explain both unauthenticated and requestId: not-found across all services at once. If settings sync brings the same extensions to both machines, it could reproduce on both macOS and Windows.
2. In Cursor Settings, confirm the account email shown there matches on both machines, and that it’s the account you expect to be using.

One small detail that helps: on our side, this account is regularly making successful requests, including today. If every single message is failing for you with no exceptions, let me know, because that doesn’t line up. It’ll help narrow down where the mismatch is coming from.

If everything works after --disable-extensions, then it’s one of the extensions and we can figure out which one. Let me know how it goes.

[Isabela_Dranka]

I think I found a very important clue.

I reproduced the issue again and captured the DevTools logs before and after the failure while running Cursor with --disable-extensions.

Pattern:

1. Sign out

2. Sign back in

3. Everything works normally

4. Approximately 8 chat messages succeed

5. Authentication suddenly breaks

6. The entire client starts returning unauthenticated errors

At the moment it fails, DevTools shows:

Failed to refresh authentication
scheduling next attempt

ConnectError: [unauthenticated]

After that, multiple unrelated requests start failing:

availableModels
getEmail
getTeams
getUserPricingInfo
getUsageLimitStatusAndActiveGrants

All of them return:

ConnectError: [unauthenticated]

This looks less like an initial login problem and more like the client successfully authenticates, but later fails when trying to refresh or renew authentication.

The failure is reproducible:

• Sign in

• ~8 successful messages

• Authentication refresh fails

• Entire client becomes unauthenticated

I’m attaching screenshots from DevTools showing the transition from a working session to the authentication refresh failure.

[deanrie]

This is really helpful debugging, especially the --disable-extensions pattern. I can see the DevTools screenshots showing the switch from a working session to Failed to refresh authentication and then a cascade of [unauthenticated].

Your test changes the picture. Since the issue still happens with --disable-extensions and on a mobile hotspot, we can likely rule out extensions and proxy or VPN. The key part is Failed to refresh authentication / scheduling next attempt. The first ~8 messages go through, then the token refresh fails, and after that the client stops attaching a valid token to requests. That explains requestId: not-found and [unauthenticated] even on non-chat calls like BootstrapStatSig, getEmail, and getTeams. This happens client-side, before the request is sent.

I’m passing this to the engineers for a deeper look. I can’t share an ETA, but your repro steps are great and that helps a lot.

To push this over the line, a couple questions:

1. After you hit [unauthenticated], does signing out via Cursor Settings and signing back in always give you a working window again of about ~8 messages? I want to confirm the pattern is stable.
2. Can you open DevTools > the Network tab (not Console) at the moment it fails and find the actual token refresh or auth request? We need its URL, HTTP status, and response body. Console shows the result, but that request will tell us if the server rejects it or if the client never sends it.

A screenshot of that Network request plus your confirmation for item 1 would give us the exact point where the chain breaks.

[Isabela_Dranka]

Thanks for taking a look.

I ran another test with --disable-extensions enabled and attached additional screenshots from both Console and Network.

A few observations:

• The issue still reproduces with --disable-extensions.

• This time authentication failed after about 3 successful messages (previously it was around 8).

• Signing out via Cursor Settings and signing back in restores functionality temporarily, but the problem eventually comes back.

• The number of successful messages before failure is not fixed. I’ve seen both ~8 messages and ~3 messages before the auth state breaks.

In the Console, I continue to see:

Failed to refresh authentication
scheduling next attempt

ConnectError: [unauthenticated]

followed by failures across multiple unrelated services:

availableModels
getEmail
getTeams
getUserPricingInfo
getUsageLimitStatusAndActiveGrants

all returning:

ConnectError: [unauthenticated]

In the Network tab, I was not able to find an obvious token refresh request, but I did notice:

POST https://api2.cursor.sh/auth/logout
401 Unauthorized

at the time the client was already in the broken auth state.

One thing that may explain why successful requests still appear in your logs:

• Sign in

• A few messages work normally

• Authentication refresh fails

• Client becomes unauthenticated

• I sign out and sign back in

• A few messages work again

So the account is able to authenticate successfully, but after some period of use the client appears to lose its authenticated state and starts returning [unauthenticated] across multiple services.

I’ve attached screenshots showing:

• The transition from a working session to auth failure

• Failed to refresh authentication

• The cascade of [unauthenticated] errors

• The Network tab at the time of failure

  Quick update:

  I thought the issue had been resolved because I was able to send several messages successfully without being logged out.

  However, the problem came back again shortly afterwards with the same authentication failure.

  So the behavior is currently intermittent:

  • Sometimes I can send multiple messages successfully.

  • Eventually the client enters the same unauthenticated state.

  • DevTools again shows the same authentication refresh failures and unauthenticated errors.

  This makes me think the issue may be timing-related or tied to the auth refresh process rather than a fixed message limit.

  

[Isabela_Dranka]

Just following up since the issue is still happening.

I completely understand that these investigations take time, but since Cursor is my primary development tool and the problem has been ongoing for several days, is there any temporary workaround the team recommends while engineering investigates?

Also, given the evidence collected so far (Failed to refresh authentication, reproducible across machines, networks, and with --disable-extensions), would resetting all auth sessions/tokens associated with my account be worth trying from your side?

I’m happy to continue collecting logs if needed.

[deanrie]

Thanks for keeping the logs coming, it really helps move the investigation forward.

About the workaround. We don’t have a full fix yet. The most reliable temporary option is what you already found: full Sign Out in Cursor Settings (not VS Code settings), quit the app, then sign in again. That gives you a clean working window until refresh breaks again. Also try turning on “Disable HTTP/2” App Settings, Cmd+Shift+, then search for HTTP/2 and run Cursor Settings (not VS Code settings) > Network > Run Diagnostics. The auth-refresh request is what’s failing, and on some networks disabling HTTP/2 stabilizes that exact request, so it might help in your case.

About resetting sessions or tokens. Important detail: based on the logs, the failure happens on the client side before the request reaches our backend your Request IDs never show up in backend logs at all. So resetting the backend session probably won’t solve the root issue because it’s reusing a stuck local token state. What does make sense on your side: sign in to the web dashboard at cursor.com, sign out there too to invalidate the saved session, then sign in again in the IDE. That forces a clean token issuance.

Your tests already narrow it down a lot: it reproduces with --disable-extensions, on a mobile hotspot, and on two machines. The key point is Failed to refresh authentication, after which the client stops attaching a valid token to all requests. I passed the repro to engineering for a deeper look, but I can’t share an ETA yet.

You’ve already confirmed the pattern of temporary recovery after re-login 3 to 8 messages, varies, so that’s enough. What we still need is the actual refresh request in Network. Last time you couldn’t find it, so when it fails, open Network and filter by auth or refresh not the chat request and catch the token refresh call. We need its URL, HTTP status, and response body. The auth/logout 401 you saw is a result of the broken state, not the refresh itself. A screenshot of the refresh request will show the exact point where the chain breaks.

[Isabela_Dranka]

Thanks for support!

I ran the Network Diagnostics while the IDE was still showing me as logged in.

I’m attaching both the screenshot and the full diagnostic output.

One thing that stood out:

• Authentication check succeeds (200)

• DNS and SSL checks succeed

• But API, Ping, Chat and Agent all fail with [unauthenticated]

This seems consistent with the client remaining in a logged-in state while authenticated API requests are no longer carrying a valid token.

I checked the Network settings after your suggestion and noticed that HTTP Compatibility Mode was already set to HTTP/1.0 when these failures occurred.

So the diagnostic results I attached were collected while HTTP/2 was already effectively disabled.

Cursor Network Diagnostic Results

FAILED (4): API, Ping, Chat, Agent

DNS: Success
Logs:
[2026-06-24T17:49:56.009Z] Host: api2.cursor.sh
[2026-06-24T17:49:56.009Z] Servers: fe80::ea45:8bff:fe86:ea58,192.168.15.1
[2026-06-24T17:49:56.009Z] Resolved to 44.218.74.220 in 3ms
[2026-06-24T17:49:56.072Z] Resolved to 44.218.74.220 in 60ms
[2026-06-24T17:49:56.080Z] Resolved to 44.218.74.220 in 3ms
[2026-06-24T17:49:56.082Z] Resolved to 44.218.74.220 in 2ms
[2026-06-24T17:49:56.084Z] Host: api2.cursor.sh
[2026-06-24T17:49:56.084Z] Servers: system
[2026-06-24T17:49:56.084Z] Resolved to 44.218.74.220, 44.209.194.48, 98.86.86.191, 54.92.228.128, 34.236.52.0, 54.85.133.41, 34.206.126.176, 34.225.242.53 in 2ms
[2026-06-24T17:49:56.084Z] Resolved to 44.218.74.220, 44.209.194.48, 98.86.86.191, 54.92.228.128, 34.236.52.0, 54.85.133.41, 34.206.126.176, 34.225.242.53 in 0ms
[2026-06-24T17:49:56.084Z] Resolved to 44.218.74.220, 44.209.194.48, 98.86.86.191, 54.92.228.128, 34.236.52.0, 54.85.133.41, 34.206.126.176, 34.225.242.53 in 0ms
[2026-06-24T17:49:56.085Z] Resolved to 44.218.74.220, 44.209.194.48, 98.86.86.191, 54.92.228.128, 34.236.52.0, 54.85.133.41, 34.206.126.176, 34.225.242.53 in 0ms
[2026-06-24T17:49:56.085Z] Result: true

SSL: Success
Logs:
[2026-06-24T17:49:55.999Z] Start
[2026-06-24T17:49:56.432Z] URL: https://api2.cursor.sh/
[2026-06-24T17:49:56.432Z] Status: 200
[2026-06-24T17:49:56.432Z] IP: 44.218.74.220
[2026-06-24T17:49:56.432Z] Issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M01
[2026-06-24T17:49:56.432Z] Name: api2.cursor.sh
[2026-06-24T17:49:56.432Z] AltName: DNS:api2.cursor.sh, DNS:prod.authentication.cursor.sh, DNS:*.api2.cursor.sh
[2026-06-24T17:49:56.432Z] DNS Time: 3ms
[2026-06-24T17:49:56.432Z] Connect Time: 147ms
[2026-06-24T17:49:56.432Z] TLS Time: 141ms
[2026-06-24T17:49:56.432Z] Result: true in 433ms

API: Error: [unauthenticated] Error
Logs:
[2026-06-24T17:49:55.999Z] Start
[2026-06-24T17:49:56.488Z] Error: ConnectError: [unauthenticated] Error

Ping: Error: [unauthenticated] Error
Logs:
[2026-06-24T17:49:55.999Z] Sending ping 1
[2026-06-24T17:49:56.498Z] Error: ConnectError: [unauthenticated] Error

Chat: Error: [unauthenticated] Error
Logs:
[2026-06-24T17:49:56.000Z] Starting streamSSE
[2026-06-24T17:49:56.498Z] Error: ConnectError: [unauthenticated] Error

Agent: Error: [unauthenticated] Error
Logs:
[2026-06-24T17:49:56.000Z] Starting stream
[2026-06-24T17:49:56.000Z] Pushing first message
[2026-06-24T17:49:56.499Z] Error: ConnectError: [unauthenticated] Error

Marketplace: Success
Logs:
[2026-06-24T17:49:55.997Z] Host: marketplace.cursorapi.com
[2026-06-24T17:49:56.242Z] Response in 245ms
[2026-06-24T17:49:56.242Z] Response: 200
[2026-06-24T17:49:56.242Z] Response Type: cors
[2026-06-24T17:49:56.242Z] Server: null
[2026-06-24T17:49:56.242Z] Result: OK in 245ms

Authentication: Success
Logs:
[2026-06-24T17:49:55.998Z] Host: prod.authentication.cursor.sh
[2026-06-24T17:49:56.437Z] Response: 200 in 439ms

Authentication UI: Success
Logs:
[2026-06-24T17:49:55.999Z] DNS lookup: authenticator.cursor.sh
[2026-06-24T17:49:56.027Z] Resolved authenticator.cursor.sh to 172.64.152.23 in 25ms

Cursor Tab: Success
Logs:
[2026-06-24T17:49:55.999Z] DNS lookup: api3.cursor.sh
[2026-06-24T17:49:56.025Z] Resolved api3.cursor.sh to 104.18.18.125 in 23ms

Agent Endpoint: Success
Logs:
[2026-06-24T17:49:55.999Z] DNS lookup: agent.api5.cursor.sh
[2026-06-24T17:49:56.063Z] Resolved agent.api5.cursor.sh to 100.30.166.181 in 61ms

Codebase Indexing: Success
Logs:
[2026-06-24T17:49:55.999Z] DNS lookup: repo42.cursor.sh
[2026-06-24T17:49:56.060Z] Resolved repo42.cursor.sh to 52.7.224.202 in 57ms

Downloads: Success
Logs:
[2026-06-24T17:49:55.999Z] Host: downloads.cursor.com
[2026-06-24T17:49:56.475Z] Response: 403 in 476ms

CDN: Success
Logs:
[2026-06-24T17:49:55.999Z] Host: cursor-cdn.com
[2026-06-24T17:49:56.319Z] Response: 404 in 320ms

[deanrie]

Thanks for the diagnostics it fits the picture well. The authentication endpoint prod.authentication.cursor.sh returns 200 DNS and SSL look good but API Ping Chat and Agent fail with unauthenticated. This matches what we expected the network layer and auth domain are reachable but no valid token gets attached to the API requests. So the issue is on the client before the request is sent not on the backend.

A couple of points.

1. On HTTP/2 I see Compatibility Mode was already set to HTTP/1.0 during the outage so we checked that option and it did not help. Okay lets move forward.

2. One more workaround worth trying for a cleaner token is to go to the web dashboard cursor.com sign out there too this clears the saved session then log back into the IDE. A normal re-login from the IDE alone reuses the stuck local token state while signing out via web forces a fresh token.

3. What we still need most is the refresh request from the Network tab at the time of failure. Last time we missed it. When you see Failed to refresh authentication again open Network not Console and filter by auth or refresh we need the token refresh request not the chat one. Grab the URL HTTP status and response body from it. auth/logout 401 is just a result of the broken state not the refresh itself. A screenshot of that request will show exactly where the chain breaks.

Investigation on the engineering side is ongoing but I cant give an ETA yet. Let me know how the web dashboard sign out goes and whether you can catch the refresh request.

[Isabela_Dranka]

I tried again with DevTools open, the Network tab, and Preserve Log enabled.

This time the behavior was slightly different:

• I started a brand new chat.

• The agent successfully began working.

• It searched the codebase, explored files, and even started generating a response.

• Then the authentication error appeared and the response was interrupted.

I carefully checked the Network tab again and I still couldn’t find any obvious auth/refresh request before the failure.

At this point I’m wondering if the refresh request is exposed under a different endpoint name or if it isn’t visible in the standard DevTools Network panel.

I’ve attached another screenshot showing the Network tab at the time of failure.

Is there a specific endpoint name, RPC method, or service I should be looking for? I haven’t been able to identify any request that looks like a token refresh.

Request ID: c5684190-107b-4e9b-bb9f-dfb257372a68
{“error”:“ERROR_NOT_LOGGED_IN”,“details”:{“title”:“Authentication error”,“detail”:“If you are logged in, try logging out and back in.”,“isRetryable”:false,“additionalInfo”:{},“buttons”:,“planChoices”:,“analyticsMetadata”:{“actionRequired”:“login”}},“isExpected”:true}
Authentication error If you are logged in, try logging out and back in.
ActionRequiredError: Authentication error If you are logged in, try logging out and back in.
at H2_ (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:11960:27337)
at fEc (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:11960:26488)
at bNb (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:11961:11416)
at Object.classify (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:11961:15921)
at j2_ (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:11961:5707)
at async Z1m.runWithSharedTurnRunner (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:11961:15273)
at async TH.runAgentLoop (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:21241:3042)
at async Znh.streamFromAgentBackend (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:24418:13682)
at async Znh.getAgentStreamResponse (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:24418:22527)
at async nRe.submitChatMaybeAbortCurrent (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:12046:2087)

[Stefano_Carfagna]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Request ID: ced282cf-d4d5-462f-ac9a-9ed41f4e6537
{“error”:“ERROR_NOT_LOGGED_IN”,“details”:{“title”:“Authentication error”,“detail”:“If you are logged in, try logging out and back in.”,“isRetryable”:false,“additionalInfo”:{},“buttons”:,“planChoices”:,“analyticsMetadata”:{“actionRequired”:“login”}},“isExpected”:true}
If you are logged in, try logging out and back in.
Authentication error If you are logged in, try logging out and back in.
ActionRequiredError: Authentication error If you are logged in, try logging out and back in.
at JHk (vscode-file://vscode-app/c:/Users/stefano/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:12056:27415)
at Nsu (vscode-file://vscode-app/c:/Users/stefano/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:12056:26566)
at aKy (vscode-file://vscode-app/c:/Users/stefano/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:12057:11930)
at Object.classify (vscode-file://vscode-app/c:/Users/stefano/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:12057:16437)
at HHk (vscode-file://vscode-app/c:/Users/stefano/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:12057:5824)
at async oTh.runWithSharedTurnRunner (vscode-file://vscode-app/c:/Users/stefano/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:12057:15789)
at async fj.runAgentLoop (vscode-file://vscode-app/c:/Users/stefano/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:24528:3041)
at async Hcp.streamFromAgentBackend (vscode-file://vscode-app/c:/Users/stefano/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:24547:13853)
at async Hcp.getAgentStreamResponse (vscode-file://vscode-app/c:/Users/stefano/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:24547:22878)
at async L4e.submitChatMaybeAbortCurrent (vscode-file://vscode-app/c:/Users/stefano/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:12144:2399)

Steps to Reproduce

open cursor
try to ask to agent

Expected Behavior

it dosent work cause login error
but i can login online whitout problem

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.9.16 (user setup)
VS Code Extension API: 1.105.1
Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80
Date: 2026-06-27T06:41:01.941Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.19045

For AI issues: which model did you use?

None

Additional Information

I cannot use cursor on windows desktop

Does this stop you from using Cursor

Yes - Cursor is unusable

[deanrie]

Hey, thanks for the new run. The Request ID payload (isExpected: true + ActionRequiredError) matches the previous ones. This is still the same client-side drop before the request is sent to the backend.

About why you can’t find the refresh request in the Network tab, that’s not on you. The token refresh happens in Cursor’s main host process, not in the workbench window that DevTools Network shows. So in the Network tab you only see renderer requests (poll?uuid, full_stripe_profile, rgstr, etc.), and the refresh call won’t show up there at all.

What will actually help instead of the Network tab is logs:

• Cmd+Shift+P > Developer: Open Logs Folder or Developer: Show Logs...
• Reproduce the issue and wait for Failed to refresh authentication / scheduling next attempt
• Find entries around that time in the main log and in the auth channel. You should see the response or error code from the refresh call there, which is what we need.

Attach that log snippet, or the whole file, and it’ll show exactly where the chain breaks.

One more thing from my last message. Did you try signing out via the web dashboard on cursor.com, not just from the IDE, then logging back in from the IDE? That forces a fresh token to be issued, unlike re-login only in the IDE. I’m curious if that changes how long it works before failing.

Engineering is still investigating, I can’t share an ETA yet. Let me know how it goes with the logs and the web sign-out.

[Isabela_Dranka]

Interesting update:

I’m currently on Cursor 3.8.24 and I haven’t been able to reproduce the authentication issue anymore.

I’ve been testing with longer conversations, agent runs and code review tasks that previously failed consistently or got interrupted by ERROR_NOT_LOGGED_IN.

One notable change is that my Pro subscription was cancelled and the account is currently on the free tier, although I’m not sure whether that is relevant or just coincidental.

Other than that, the environment is unchanged:

• same machine

• same network

• same installation

I’m going to keep using it normally over the next few days and monitor whether the issue comes back.

[deanrie]

@Isabela_Dranka thanks for the update, that’s good news. Glad 3.8.24 has been clean so far. The detail about switching from Pro to free might be a coincidence, but I’ll note it in the investigation. It’s possible the refresh gap is somehow related to subscription state. Please keep an eye on it for a couple more days during long sessions and agent runs. If it doesn’t come back, it’s probably gone. If it happens again, message me right away.

@Stefano_Carfagna this looks like the same issue discussed in this thread: after Failed to refresh authentication, the token stops attaching to requests, even though the UI still shows you as logged in. This happens on the client side before the request is sent, so your Request ID never reaches the backend.

Things to try:

1. Do a full Sign Out via Cursor Settings, not the button in the error toast, then fully quit Cursor and sign in again.
2. Also go to the web dashboard at cursor.com and sign out there too. That invalidates the saved session and forces a fresh token. Re-logging in only from the IDE can reuse a stuck local token.
3. Turn on Disable HTTP/2 in App Settings. Open settings with Cmd+Shift+, or Ctrl+Shift+, then search for HTTP/2. On some networks this makes the auth refresh request more stable.

If it still drops, the most useful thing is logs. The Network tab won’t help because refresh runs in the host process, not the workbench window:

• Run Ctrl+Shift+P then Developer: Open Logs Folder or Developer: Show Logs...
• Reproduce the issue and wait for Failed to refresh authentication / scheduling next attempt
• Find entries around that time in the main log and the auth channel. It should include the response code or the error from the refresh call

Attach that snippet or the whole file. It’ll show exactly where the chain breaks. We’re tracking this issue, but I can’t share a precise ETA for a fix yet.

[Isabela_Dranka]

One additional note from the customer experience side:

I ended up cancelling my Pro subscription during this investigation because the authentication issue made the product effectively unusable for my workflow for several days.

I understand bugs happen and I appreciate all the help from the team here, but I thought it was worth mentioning as a real-world impact of this issue.

Also, before my free usage limit was exhausted, the Billing page showed around US$24 in credits remaining and indicated they would be automatically applied to usage. After hitting the free limit, those credits disappeared entirely. I’m not sure if that’s expected behavior after cancelling Pro or if it’s related to billing state, but I wanted to mention it as well.

[deanrie]

@Isabela_Dranka, thanks for coming back with details. It sucks that the bug left you without a working tool for a few days, that’s real impact. Glad it’s clean on 3.8.24. If it comes back, post here right away, and if you can, include the log around Failed to refresh authentication Ctrl+Shift+P / Cmd+Shift+P > Developer: Open Logs Folder.

About the missing ~$24 credits, that’s an account-specific billing issue and I can’t check it from the forum. Best next step:

Account and billing questions are handled by our team at [email protected]. They’ll be able to look into your specific situation.

Send them what you wrote here, the credit amount, the note about auto-apply, and that they disappeared after you hit the free limit. They’ll check your account balance state.

[123451 (937464028)]

I’ve been unable to log in for the past fifty minutes, what’s going on?

[aoi-ue]

we have been stuck since last friday and cursor has not been responding. i cant even cancel my subscription.

Request ID: fbf7f60c-6c75-4514-8535-e4b2e466d82d

Hey, thanks for the screenshots. The 401s on cursor.com in the browser (not just the IDE) confirm this is account-specific. Your token isn’t validating anywhere, and since the clock sync didn’t help, it needs a direct lookup we can’t do from the forum. You’ve already done the right thing by emailing [email protected]. That’s where this gets handled. They work through requests in order, so it may take a little while over the weekend, but they’ll get back to you and check your specific account. No n…