Same here on 3.16.29 (macOS, stable). Adding data rather than another +1, because in my setup this isn’t cosmetic — the servers genuinely don’t connect.
Setup: one .code-workspace with ~30 folders. Five of them ship a .cursor/mcp.json defining a remote MCP server. Same URL for all five, but each sends a different Authorization header, because each repo maps to a different project in the upstream service.
What actually loads:
| Workspace folder (index) |
Visible in Customize |
Agent can call tools |
| 0 |
yes |
yes |
| 15 |
yes |
yes |
| 24 |
no |
no |
| 25 |
no |
no |
| 27 |
no |
no |
All five files are the same shape, valid JSON, unique server names, no ${env:} interpolation in the three broken ones. So it isn’t “first root only” — root 15 works fine while 24, 25 and 27 don’t. I can’t see a pattern that explains which ones survive.
The scope dropdown in Customize → MCPs also lists fewer entries than I have folders, so I can’t even select the broken folders to inspect them. And because the row never renders, there’s no toggle and no Authenticate button to click — the usual “disable and re-enable it” advice has nothing to act on.
Why this breaks my workflow specifically
The per-folder scoping is the feature. Each repo’s key grants write access to that repo’s project only. That’s deliberate: an agent working in one product repo must not be able to write into another product’s project. Repo-level rules and skills reference each server by name and say “never use the global one for this repo.”
So the two suggested workarounds both fail for me:
- Move them to
~/.cursor/mcp.json. This hands every repo write access to all five projects at once and puts five near-identical tool sets in front of the agent, which then picks the wrong one. It converts a safety boundary into a coin flip. Not something I’m willing to ship to my team.
- Open each folder in its own window. This is the actual workaround I’m using, and it means abandoning the multi-root workspace for exactly the tasks where I need it. Cross-repo work now needs two windows and a manual context switch.
The net effect is that three of my five repos have silently lost their MCP tooling, and the failure mode is the bad kind: nothing errors, the tools are simply absent, so an agent following the repo’s own rules just reports the server isn’t configured.
What would help most, roughly in order:
- Make project servers connect in multi-root workspaces again, even if the Customize UI stays broken a bit longer. Working tools with no UI beats a UI with no tools.
- Surface a load error somewhere reachable. If a folder’s
mcp.json is skipped, MCP Logs should say which folder and why, instead of the entry vanishing.
- Populate the scope dropdown from the workspace folder list, so a folder with a config can never be unselectable.
Many thanks in advance for fixing this issue.
