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.

10

Any update on this? Ran into this today

11

Hey, this is a known bug and we’re tracking it. The root cause is that the enabled state and project approval for MCP servers are scoped to the workspace path, and a new worktree window has a different path, so it treats itself as a new workspace. On top of that, OAuth callback routing is tied to the current window’s workspaceId, so even with saved tokens, the new window goes through the flow again.

We don’t have a reliable non-manual workaround for OAuth MCP in worktree agents yet. I can’t share a fix timeline right now. When I have an update, I’ll reply here in the thread.

If you don’t mind, to round out the picture: which MCP reproduces this best, and what Cursor version are you on Cursor > About?

12

This is exactly the kind of issue that makes worktree agents hard to trust for real daily use.

For parallel agents, the setup cost has to be close to zero. If every new worktree needs manual OAuth repair, people will naturally fall back to one longrunning session, even if separate worktrees would be cleaner architecturally.

13

We use an internal MCP, but it uses Oauth like any other mcp with oauth, basically any mcp tool that doesn’t use PATs will need to be reauthed any time a new worktree is created.

14

@opti21 @Jason_Luo1 thanks for chiming in, it helps us understand how widespread this is.

This is a known bug and we’re tracking it internally. The root cause is that the enabled state and project approval for MCP servers are scoped by workspace path, but the OAuth callback routing is tied to the workspaceId of the current window. A new worktree window has a different path, so it treats itself as a new workspace and runs the OAuth flow again, even if the tokens are already saved. This affects any OAuth-based MCP. PAT-based ones aren’t impacted, and @opti21 called that out correctly.

Right now there isn’t a reliable non-manual workaround for OAuth MCP in worktree agents, and I can’t share a fix timeline yet. Once I have an update, I’ll post it in this thread.

15

Any update on this ? I am facing same issue with agent cli as well, even if the mcp is authenticated as user globally, it is not taking it.

16

This is an issue for me as well - having to re-auth MCPs for sibling worktrees of the same repository is a killer limitation of the cli harness.

Any update?

17

This issue is absurd. It’s late 2026, and we still can’t trust agent setups. Does it make sense to re-enable and authenticate the agent every time we open a new one?

Worktrees are my default setting for obvious reasons: isolation and parallelism.

19

Hey, thanks for flagging this, and thanks to @Ligo_George and @conner_at_vantage too, including the cases with the CLI harness.

This is a known issue we’re tracking. The reason is that the enabled state and project approval for MCP servers are tied to the workspace path, and a new worktree window has a different path, so it behaves like a new workspace. On top of that, OAuth callback routing is tied to the current window’s workspaceId, so even if tokens are saved, the new window runs the OAuth flow again. This affects any OAuth-based MCP, PAT-based MCPs aren’t impacted, and the same root cause explains the CLI behavior.

There isn’t a reliable non-manual workaround for OAuth MCPs in worktrees yet, and I can’t share a timeline for a fix right now. Once there’s an update, I’ll post it here in the thread.

20

Can’t we have the option to have a worktree work path identical to Claude Code which has it inside the project workspace at .claude/worktrees?

21

Hey @Adrien, thanks for the idea. A configurable worktree location, including an option inside the project like .claude/worktrees, is a reasonable request, and I’ve passed it to the team as feedback. If you want, please open a separate thread for this in Feature Requests with a description of the behavior you’d like to see. That makes it easier to track separately from this thread, which is mainly about OAuth MCP.

One note so there aren’t any false expectations. Moving the worktree inside the project by itself won’t fix the OAuth MCP issue from this thread. The reason isn’t the physical folder path. It’s that the enabled state and project approval for MCP are scoped by workspace path, and OAuth callback routing is tied to the workspaceId of the current window. A new worktree window still gets a different workspace and goes through the OAuth flow again.

That’s a separate issue we’re tracking, and the status is still the same. I can’t share a timeline yet, but I’ll post here once there’s an update.

22

Same issue here with the cursor-agent CLI, which is what third-party harnesses use (T3 Code starts one cursor-agent acp process per thread, in a fresh git worktree). Adding CLI-specific detail and a minimal repro, because the token side turns out to be simpler than the IDE side described above.

Root cause in the CLI (2026.10.01-e373342, macOS)

  • The agent resolves the project root as the git top-level of the cwd. For a worktree, that’s the worktree path, not the main checkout.
  • MCP OAuth tokens are read from and written to ~/.cursor/projects/<slug(project root)>/mcp-auth.json. There is no user-level fallback, and a login from the Cursor app isn’t used.
  • So each worktree is a new project. On first connect, the agent writes only clientInfo (dynamic client registration) and no tokens, and every OAuth server reports requires_authentication.
  • The file is cached in memory per path for the life of the process and never re-read. Logging in from another terminal while an agent is running doesn’t reach it, and it needs a restart.

This matches what @nkoynov found for the SDK in topic 173938.

Minimal repro, no third-party tools

mkdir /tmp/repo && cd /tmp/repo && git init -q && git commit -q --allow-empty -m init
cursor-agent mcp login Atlassian-MCP-Server     # any remote OAuth MCP server
cursor-agent mcp list                           # Atlassian-MCP-Server: ready
git worktree add -q /tmp/repo-wt -b wt
cd /tmp/repo-wt && cursor-agent mcp list        # Atlassian-MCP-Server: requires_authentication

Afterwards, ~/.cursor/projects/private-tmp-repo-wt/mcp-auth.json contains only clientInfo for each server.

Tokens are portable

If ~/.cursor/projects/<worktree slug>/mcp-auth.json is a symlink to an authenticated file before the agent starts, every OAuth server is ready in the worktree immediately. Refreshes are written back through the symlink, since the store uses a plain writeFile. For the CLI at least, nothing ties the tokens to the original folder. The blocker is only where the agent looks for them.

I’m using that as a workaround: a wrapper around cursor-agent links each project’s mcp-auth.json to one shared file before exec. It relies on undocumented storage, though. It also races when several agents run at once: each process keeps its own in-memory snapshot and writes the whole file, so a rotated refresh token (Atlassian rotates them) can be overwritten by a stale one. The T3 Code maintainers closed the matching report as upstream for those reasons (pingdotgg/t3code#19552). They said they’d pass through a supported setting if Cursor adds one.

What would fix it, in order of preference:

  1. A user-level MCP token store keyed by server URL, shared by the CLI, SDK, and app, with a per-project override only when needed.
  2. Failing that, key the token file by the repository’s git common dir instead of the worktree top-level, so all worktrees of a repo share one login.
  3. At minimum, a supported setting or environment variable for the auth file path, such as CURSOR_MCP_AUTH_FILE, so harnesses can point every session at one store.
  4. Re-read the auth file, or watch it, when a server is needsAuth, so a login takes effect without restarting the agent.

With 1–3, the store should also lock and re-read the file before writing refreshed tokens, so concurrent agents don’t overwrite each other’s rotated refresh tokens.

24

Hi @deanrie, any update on this? I’m hitting the same bug in the CLI and in the Cursor SDK, and there’s one SDK detail I haven’t seen in this thread yet.

Setup

  • macOS 26.5.2
  • Cursor app 3.24.12
  • Cursor CLI 2026.10.16-e3cb207
  • @cursor/sdk 1.0.35, local runtime
  • OAuth MCPs in ~/.cursor/mcp.json: Figma, Slack, and our company’s internal MCP server. Linear too, but I’m moving it to an API key.

What happens

I log in with /mcp or agent mcp login and the server shows as ready. Then I run the agent in a different folder and every OAuth server needs login again. Here’s agent mcp list in three folders on my machine, run a few minutes apart:

Folder Figma Internal Linear Slack
~ ready requires_authentication needs approval needs approval
another project folder requires_authentication requires_authentication requires_authentication requires_authentication
/tmp requires_authentication requires_authentication requires_authentication requires_authentication

I run a lot of parallel agents, each in its own worktree or folder. I now have 255 ~/.cursor/projects/*/mcp-auth.json files. Only 14 of them hold tokens. The rest just have the clientInfo from dynamic client registration.

The SDK case

Staff already confirmed in topic 173938 that the SDK reads the same per-folder token file. What I haven’t seen mentioned is that the SDK has no way around it. It derives the auth path from the git top-level of local.cwd, and Agent.create has no option to override that. The wrapper workaround @slavco86 posted above only works when you spawn the cursor-agent binary yourself. Apps that embed the SDK in-process can’t use it, so they have no workaround at all.

Copying or symlinking the file is also unsafe for us. Our internal MCP server rotates refresh tokens and treats reuse as theft, so it revokes every token for that client. Two agents holding the same copied refresh token can log me out everywhere at once. Each SDK process also caches the file in memory per path and writes back the whole object, so an older session can overwrite newer tokens.

What would fix it

Any of these would work, best first:

  1. One MCP token store per user, keyed by server URL, shared by the app, CLI, and SDK.
  2. All worktrees of a repo share one login, keyed by the git common dir instead of the worktree path.
  3. A supported setting for the auth file path, as an SDK option (for example local.mcpAuthPath) or an env var, so every session can point at one file.

With 1 or 3, the store also needs to re-read the file before writing refreshed tokens, so parallel agents don’t clobber each other’s rotated refresh tokens.

Is any of these on the roadmap, or is there an ETA? Right now OAuth MCPs are basically unusable for me in parallel agent workflows.

25

Hey, thanks for the details, especially about the SDK. That really hadn’t come up in the thread yet.

There’s still no update for now. We’re continuing to track this issue, but I can’t share an ETA or roadmap. I passed your details to the team along with the CLI repro from @slavco86:

  • in @cursor/sdk local runtime, there’s no way to override where login comes from, so apps that embed the SDK in-process don’t really have a workaround
  • with parallel agents, a copied or symlinked auth file is risky for servers that rotate refresh tokens and revoke them on reuse
  • all three solution options you suggested

I agree with your risk assessment. Copying or symlinking a token file isn’t a supported path, and with servers that revoke tokens on reuse, I wouldn’t use it. For now, the most reliable option for parallel agents is an API key or PAT where the server supports it, like you’re already doing with Linear.

I’ll post here when there’s an update.