MCP servers are not enabled/authenticated in new worktree agents (OAuth), making worktrees impractical

Support Bug Reports
, ,
1

I’m running into a blocking issue with Cursor’s native “new agent in separate worktree” workflow.

What happens

When a new agent is created in a separate worktree, my MCP servers are present in config but end up not enabled and not authenticated in that new worktree context.

This happens consistently with MCP servers that use OAuth auth flow.

Why this is a problem

I rely heavily on MCP servers.
Having to manually re-enable and re-authenticate OAuth MCPs for every newly created worktree makes the worktree feature effectively unusable in daily workflow.

What I already tried

  • Local (workspace-scoped) MCP config copied into each worktree via setup script

  • Global-scoped MCP config

Neither solved the issue for newly created worktree agents.

Expected behavior

When creating a new agent in a separate worktree, MCP server state should be preserved (or restorable automatically), including:

  • enabled/disabled server state

  • OAuth auth session (or at least a seamless re-link flow without per-worktree manual setup)

Actual behavior

  • MCP servers are not enabled and/or not authenticated in the new worktree agent

  • Manual OAuth re-auth is required for each worktree

Environment

  • OS: macOS (Darwin 23.3.0)

  • Cursor feature used: native “new agent in separate worktree”

  • MCP auth type: OAuth

Request

Could Cursor support persistent MCP enablement/auth state across worktrees (or provide official bootstrap/sync behavior for worktree-created agents)?
If this is intended behavior, is there a recommended non-manual workflow for OAuth MCPs in worktrees?

5

Hey, thanks for the detailed report. The expected vs actual and the steps you tried really help.

This is a real gap in the worktree flow, and it isn’t specific to any one MCP. The root cause is that the enabled state and project approval for MCP servers are scoped by workspace path, so a new worktree window with a different path treats itself as a new workspace. The server starts disabled, and OAuth callback routing is tied to the workspaceId of the current window, so even if shared OAuth tokens are stored in the keychain, the new window still needs to go through the flow again. That’s why neither a workspace scoped .cursor/mcp.json nor the global config fully solves it. They only affect configuration, not the approval or enabled state, and not the OAuth callback routing.

Right now there’s no reliable non manual workaround for OAuth based MCP in worktree agents. I’ve filed this internally as a separate bug or improvement, separate from the previously closed multi window OAuth ticket since that one had a different scope. I can’t share an ETA yet. When I have an update, I’ll reply in the thread.

To make the ticket more complete, can you share:

  • your Cursor version (Cursor > About)
  • which MCP reproduces it best (Atlassian, Linear, Notion, GitHub, or other)
  • whether the worktree is created via Glass new agent in separate worktree, or manually via git worktree add and then opening it in Cursor
8

Thanks for confirming and for filing this separately :folded_hands:

Here are the details you asked for:

  • Cursor version: 3.2.21

  • MCPs that reproduce it best: Sentry, ClickUp

  • Worktree creation path: via New Worktree in the Cursor Agents window

Could you also share how I can track progress on this issue? Should I follow this thread for updates, or is there a public issue/reference I can subscribe to?

9

Thanks for the details.

On tracking: we don’t have a public issue tracker you can subscribe to, so the best way is to keep an eye on this thread. Once we have an update on the fix, we’ll post it here. I can’t share an ETA yet.