Where does the bug appear (feature/product)?
Cursor IDE (Agent / Chat)
Describe the Bug
Every morning when I start using Cursor, Agent chat shows:
Authentication error
If you are logged in, try logging out and back in.
UI still looks logged in. After Sign Out + Sign In again, it works for the rest of the day. The problem comes back the next morning.
This is reproducible as an overnight / long-lived session issue, not a bad password.
Request ID
83a21c60-0790-4200-aa3d-64c3c1ddb77b
Steps to Reproduce
- Keep Cursor running overnight (do not fully quit).
- Next morning, open Agent chat and send any message.
- Observe Authentication error /
ERROR_NOT_LOGGED_IN. - Sign out + sign back in → works until the next overnight period.
Operating System
Windows 11 (Windows_NT x64 10.0.22631)
Version Information
- Cursor: 3.14.7 (stable)
- Commit:
a758f2241ca99fecf380180b6cbdbbce0f1f42c0 - Electron / layout: unifiedAgent + glass also used
Account
- Enterprise membership
- Auth via Auth0 (
signupType=Auth_0) - Corporate network / Tencent environment
Local diagnostics already completed
We ruled out the common local causes suggested in similar threads:
| Check | Result |
|---|---|
| Windows clock sync | OK — NTP synced to time.tencent.com, timezone Asia/Shanghai (+08:00), clock is correct |
| System / WinHTTP proxy | Disabled / direct (no system proxy) |
| Custom Model Base URL | Not set |
HTTP env proxies (HTTP_PROXY etc.) |
Empty |
| Network reachability | api2.cursor.sh returns 200 |
| Tokens present after re-login | cursorAuth/accessToken + refreshToken both present |
Token JWT exp after re-login |
~2026-10-04 (not short-lived expiry explaining morning failure) |
Strong evidence from local logs
Cursor process was left running from 2026-08-04 11:21.
Starting around midnight, logs show repeated:
ConnectError: [unauthenticated]
error: ERROR_NOT_LOGGED_IN
title: Authentication error
detail: If you are logged in, try logging out and back in.
In one overnight session we counted ~1538 ERROR_NOT_LOGGED_IN log hits from about 00:05 until around 10:04 (when usage / re-login resumed).
Also observed:
- Transport uses HTTP/2 to Cursor APIs
- Logs show
tls.hasCustomCA: true(corporate CA trust store present) - At window restore time:
Failed to refresh membership ... {"error":{"name":"Canceled"}} - Auth race log:
auth_ready_race_preventedwith largewaitedMsearlier in the session
This matches the known client-side auth-refresh / token-attachment breakage discussed in:
Mitigations applied locally
- Confirmed clock sync is healthy.
- Enabled
cursor.general.disableHttp2: true(HTTP/1.1 fallback) as suggested for auth-refresh instability. - Temporary workaround remains: full Sign Out → fully quit Cursor → Sign In again each morning.
Expected Behavior
Long-lived overnight sessions should successfully refresh auth and keep Agent usable the next morning without manual re-login.
Does this stop you from using Cursor?
Yes — every morning until re-login. Blocks Agent until manually fixed.
Ask for Cursor team
Please check backend/client traces for Request ID 83a21c60-0790-4200-aa3d-64c3c1ddb77b, and whether overnight token refresh is failing client-side before the request is sent (as described in the ERROR_NOT_LOGGED_IN investigation). Happy to capture Network tab auth/refresh request details on the next failure if needed.