Allow a workspace to opt out of user-level MCP servers for reproducible AI environments
- Dominant language
- TypeScript
- Stars
- 193k
- Forks
- 42.4k
- PR merge metrics
- PR metrics pending
Description
VS Code already lets a workspace scope several agent-customization inputs to itself, ignoring the user-level equivalents:
- `chat.agentFilesLocations`
- `chat.agentSkillsLocations`
- `chat.instructionsFilesLocations`
- `chat.hookFilesLocations`
There is no equivalent for MCP servers. User-level MCP configuration (`mcp.json` in user scope, or servers added via `chat.mcp.*` outside the workspace) is always merged into the servers available to the agent in a given workspace, with no way for the workspace to opt out.
This means two developers opening the same repository can have a different set of MCP tools available to the agent, purely based on what they've personally configured outside the project. For teams building reproducible AI harnesses (e.g. checked-in `.vscode/mcp.json` defining the exact toolset a repo's agent workflows depend on), this breaks determinism: prompts, skills, and instructions can be pinned to the workspace, but the tools those instructions assume are present cannot.
This also creates an inconsistency: agents, skills, instructions, and hooks all support workspace-only resolution via their `*Locations` settings, but MCP — arguably the most behavior-affecting of these inputs, since it changes what actions the agent can take — does not.
**Ask:** a way for a workspace to exclude user-level MCP servers from resolution, so only workspace-defined servers are available, mirroring the existing `*Locations` pattern used for agents/skills/instructions/hooks. Not requesting a specific setting shape — just parity with the resolution model VS Code already ships for these other customization types.
This would help repositories that want:
- Only workspace-defined MCP servers active, regardless of what's configured locally.
- Personal MCP configuration to have no effect on project agent behavior.
- Consistent onboarding — a fresh checkout behaves the same as a machine with years of accumulated personal MCP config.
- CI and local dev environments to see the same MCP toolset.
Related: #254931 (per-server enable/disable at user/workspace scope) addresses fine-grained control over individual named servers, but doesn't provide a bulk mechanism to disable all user-scope resolution for a workspace.
Contributor guide
Assessment
This issue has not been assessed yet.