MCP headers config ignored when server has OAuth discovery

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When an MCP server has OAuth discovery endpoints (RFC 9728), Cursor ignores the headers configuration and always attempts OAuth authentication. This occurs in both plugin mcp.json and global mcp.json configurations.

Steps to Reproduce

  1. Configure an MCP server with headers (in either plugin or global mcp.json):
{
  "mcpServers": {
    "my-server": {
      "url": "https://example.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${env:MY_API_KEY}",
        "Content-Type": "application/json"
      }
    }
  }
}

  1. The server at example.com has OAuth discovery at /.well-known/oauth-authorization-server

  2. Toggle the MCP server on in Cursor

  3. Observe: Cursor requests /.well-known/oauth-authorization-server and attempts OAuth - it never sends the configured Authorization header

Expected Behavior

When headers is configured in mcp.json (plugin or global), Cursor should use those headers for MCP requests instead of attempting OAuth discovery.

Actual (buggy) behavior:
Cursor:

  1. Checks OAuth discovery endpoints first
  2. If OAuth discovery returns 200/302, uses OAuth flow
  3. Never uses the configured headers
  4. The Authorization header is never sent to /mcp/

Operating System

Linux

Version Information

Version: 2.6.21
VSCode Version: 1.105.1
Commit: fea2f546c979a0a4ad1deab23552a43568807590
Date: 2026-03-21T22:09:10.098Z
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Linux x64 6.8.0-106-generic

For AI issues: which model did you use?

N/A

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

Evidence from Server Logs:
Only OAuth discovery requests received - no POST requests with Authorization header:

GET /.well-known/oauth-authorization-server → 302
GET /.well-known/oauth-protected-resource/mcp → 200

No POST /mcp/ requests with Authorization: Bearer … header appear in logs.

Impact:

This breaks API key authentication for servers that also support OAuth. Users cannot use headers config when their server has OAuth endpoints. For the moment, we’re going to try a workaround on the MCP server side and create an alternative endpoint, /api/mcp that’ll return a 404 for OAuth discovery, which will hopefully force Cursor to use the configured headers .

Related bug:

This compounds with the Remote SSH OAuth token sync issue that we filed earlier (see MCP OAuth Token Not Used After Successful Authentication ) – Remote SSH users cannot use OAuth (tokens don’t sync to remote host), and now cannot use headers either.

Does this stop you from using Cursor

No - Cursor works, but with this issue

1 Like
5

Hey, great bug report, it’s super clear.

This is a confirmed bug. When the MCP server responds to the OAuth discovery endpoints, Cursor starts the OAuth flow before it sends the POST with your Authorization header. There’s no logic like “if Authorization is already in the headers, skip OAuth.” We’ve seen the same root cause in a similar report: Remote MCP with expired bearer token triggers misleading OAuth error

The team is aware of the issue. There’s no ETA yet, but your report helps with prioritization, especially since it expands the scope to valid headers plus OAuth discovery, not just an expired token.

Your workaround with an alternate /api/mcp endpoint that returns 404 for OAuth discovery is the most reliable option right now.

Let me know if the workaround doesn’t work, or if anything changes.

7

Hi Dean, glad to hear that you found the report useful. We got the /api/mcp endpoint to work with the Authorization header, but not before uncovering another bug related to overly aggressive OAuth probing which deviates from the OAuth RFC. Here’s that bug: *** Cursor MCP client probes OAuth even when server signals OAuth unavailable***

Have a nice weekend!

1 Like
8

I am going to +1 this issue. Ever since upgrading to v3, our header-auth-based MCP server no longer connects with Cursor. We have tried several workarounds, but it looks like the OP has correctly identified the bug in this case.

@deanrie You mentioned no ETA, but please, prioritize this.

9

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I successfully setup a github MCP server to provide access to the github ‘projects’ tools (30 days ago) and it was working correctly. I returned to working on this project a few days ago and find I now get an error in cursor settings:

2026-04-10 09:01:40.742 [info] [V2] Handling CreateClient action
2026-04-10 09:01:40.742 [info] [V2 FSM] connection:connect_start: conn=idle,auth=unknown -> conn=connecting,auth=unknown
2026-04-10 09:01:42.203 [info] No stored client information found
2026-04-10 09:01:42.206 [info] Using redirect URL
2026-04-10 09:01:42.207 [warning] Transient error connecting to streamableHttp server: Incompatible auth server: does not support dynamic client registration
2026-04-10 09:01:42.207 [warning] Connection failed: Incompatible auth server: does not support dynamic client registration
2026-04-10 09:01:42.207 [warning] [V2 FSM] connection:connect_failure: conn=connecting,auth=unknown -> conn=failed,auth=unknown
2026-04-10 09:01:42.207 [info] CreateClient completed, connected: false, statusType: error

Steps to Reproduce

Create an MCP entry with a github personal access token as follows:

    "github-projects": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/x/projects",
      "headers": {
        "Authorization": "Bearer ghp_my_key”
      }
    },

Expected Behavior

Cursoe should authenticate with the github MCP server should provide the github projects tools.

Operating System

MacOS

Version Information

Version: 3.0.13
VSCode Version: 1.105.1
Commit: 48a15759f53cd5fc9b5c20936ad7d79847d914b0
Date: 2026-04-07T03:05:17.114Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin x64 24.6.0

For AI issues: which model did you use?

N/A

Additional Information

I think this may be a similar issue:

Does this stop you from using Cursor

No - Cursor works, but with this issue