Cursor does not refresh OAuth tokens for MCP Servers

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor does not refresh OAuth tokens for MCP Servers. In fact, it appears that Cursor is not requesting the OAuth refresh token from the MCP server. This leads to all MCP servers failing ~15min after being added with common token time-outs.

Steps to Reproduce

  1. Add an MCP Server that uses DCR/OAuth - I recommend an MCP Gateway from Arcade (MCP Gateways | Arcade Docs)
  2. Authenticate and call some tools
  3. Wait 15 min
  4. See that tool calls have failed, and cursor reports an error on the MCP connection (“needs authentication”). Reconnecting will succeed, but then time out again in ~15 minutes.

Expected Behavior

MCP Clients implementing OAuth must request refresh tokens, and update the client’s token periodically.

Operating System

MacOS
Linux

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.4.7
VSCode Version: 1.105.1
Commit: ca0f9bf806f235ea014a22712cbcbf5e88ca77e0
Date: 2026-01-20T20:52:38.077Z (22 hrs ago)
Build Type: Stable
Release Track: Early Access
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Darwin arm64 25.1.0

For AI issues: which model did you use?

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

2 Likes

Hey @Evan_Tahler_Arcade!

Thanks for raising this. This is a known limitation for Cursor (not supporting refresh tokens). I’ve added this thread to the internal ticket we have tracking requests.

1 Like

Thanks!

Is there anything we can do to help you folks out? Happy to colab/share code/best practices, etc…

We’ve confirmed in our logs that cursor’s MCP client is advertising that it does support refresh_token, this is the registration metadata is sent with Dynamic Client Registration (DCR)

{
  "redirect_uris": [
    "cursor://anysphere.cursor-mcp/oauth/callback"
  ],
  "scope": "mcp offline_access",
  "token_endpoint_auth_method": "none",
  "grant_types": [
    "authorization_code",
    "refresh_token"
  ],
  "response_types": [
    "code"
  ],
  "client_name": "Cursor"
}

It might be better in the short term not to advertise refresh_token support if it is not supported

1 Like

Thanks @Evan_Tahler_Arcade!

Looked into it a bit more after reading your post. From what I can tell, Cursor does store the refresh token when received, but doesn’t currently use it to refresh expired access tokens on the client side. So when an access token expires, users have to re-authenticate rather than having it silently refreshed.

So it kind of supports refresh tokens but not in a very helpful way. Your point about advertising support for it in grant_types is valid and I’ll pass it on to the team.

Would your tool treat Cursor differently if it doesn’t advertise it (offer a longer-lasting initial token? something else?)

I think you should continue to advertise that you accept tokens, otherwise a number of MCP servers won’t be able to connect, even though you don’t do the refresh yet. You’ll go from ~15 min of usability to 0! In our case, we won’t issue a “forever” token if you don’t support refresh, we just won’t connect over OAuth.


If it was clear that Cursor doesn’t support token refresh, we likely probably advise our users not to use DCR, and direct them to connect via an alternative authorization mechanism using long-lived API Keys in the headers:

{
  "mcpServers": {
    "mcp-arcade": {
      "url": "https://api.arcade.dev/mcp/<YOUR-GATEWAY-SLUG>",
      "type": "http",
      "headers": {
        "Authorization": "Bearer {arcade_api_key}",
        "Arcade-User-ID": "[email protected]"
      }
    }
  }
}

This is a worse method of connecting to HTTP MCP servers for a few reasons, but at least it will work for for longer than 15min!

Reasons this is worse:

  1. It’s out of spec. MCP technically disallows long-lived tokens in headers
  2. It’s harder to set up. Users need to provision an API Key and mess with JSON
  3. It’s less safe. Now, a “forever token” is listed in plain-text on the host machine, and agents can read it.

So, the best case scenario would be to really do the token refresh - it’s both the safest and easiest way for users to connect!

1 Like

We are facing this issue with our MCP Server connection to Atlassian. We need to disable/enable it (or restart Cursor) whenever the OAuth token is expired. Not a great experience being that the token expires about every 20 minutes. Please provide refresh functionality for MCP Servers in Cursor. Thanks!