microsoft / microsoft/vscode

Allow a workspace to opt out of user-level MCP servers for reproducible AI environments

Open
#329,475 3 comments 0 reactions 1 assignee Assigned to @dmitrivMS View on GitHub
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.