Repository navigation
[FEATURE]: MCP config isolation — allow projects to opt out of global MCP inheritance #17605
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Note: Related issues exist (#5013, #4054, #10707) but address different aspects of MCP config. #5013 wants per-project enable (global disabled → project enabled, which doesn't work). #4054 is about MCP servers not loading from project config. #10707 wants parent-folder inheritance. Our request is the inverse: opt out of global inheritance entirely.
Describe the enhancement you want to request
Problem: OpenCode merges MCP server configurations from all config sources using mergeConfigConcatArrays. There is no way to prevent global MCP servers from being visible in a project context. A project can only disable individual servers by name ("enabled": false) — it cannot opt out of global MCP config entirely.
Why this matters: In agent orchestration systems, agents must operate in a controlled, sandboxed environment with access only to explicitly registered MCP tools. Global MCP servers (browser devtools, Docker, IDE plugins) are irrelevant and potentially harmful:
- Agents may discover and use tools they shouldn't have access to
- Every new global MCP server silently becomes available in all projects — unless manually disabled
- This violates the principle of least privilege
Current workaround:
{
"mcp": {
"my-project-mcp": { "type": "local", "command": ["./mcp-server"], "enabled": true },
"muninn": { "enabled": false },
"MCP_DOCKER": { "enabled": false },
"chrome-devtools": { "enabled": false }
}
}This is fragile — adding a new global MCP server silently leaks into all projects.
Proposed solution: A top-level config flag to disable MCP inheritance:
{
"mcp_inherit": false,
"mcp": {
"my-project-mcp": { "type": "local", "command": ["./mcp-server"], "enabled": true }
}
}When mcp_inherit is false, only MCP servers defined in the project config are loaded. Default is true for backwards compatibility.
Implementation: In packages/opencode/src/config/config.ts, the state function merges configs sequentially. The change would add mcp_inherit to the Info schema and, when false, replace result.mcp instead of deep-merging.
Use cases:
- Agent orchestration platforms needing isolated MCP tool sets
- CI/CD environments that should not pick up developer MCP servers
- Security-sensitive projects needing explicit tool control
Environment: Verified in v1.2.25 and v1.2.26 source — no isolation mechanism exists.
Activity
[-]Feature: MCP config isolation — allow projects to opt out of global MCP inheritance[/-][+][FEATURE]: MCP config isolation — allow projects to opt out of global MCP inheritance[/+]github-actions commentedon Mar 15, 2026
Thank you for updating the issue! It now meets our contributing guidelines — the feature request is clear, well-described, and includes useful context. We appreciate the detailed write-up!
prakersh commentedon Mar 16, 2026
Strong +1 on this. Per-project MCP isolation would be very useful for tools like onUI (a browser annotation MCP server) — you'd want it enabled for frontend/UI projects but not for backend-only work. The current workaround of manually disabling every unwanted global server per project is fragile, as you noted.
iMaxTomas commentedon Apr 12, 2026
Project-level MCP isolation would be a huge improvement, but a detail that might affect the design: some MCPs are not inherited from global config at all — they are launched directly by the
opencodebinary.Our logs show
chrome-devtoolsandmorphllm-fast-applyloading astype=local foundeven when the globalopencode.jsoncontains no such entries ("mcp": {}). This means project-level opt-out would need to be able to override binary defaults, not just inherited global servers.I've filed #22188 specifically to request a built-in MCP disable mechanism. It might be worth aligning that work with this project-isolation feature so that the final design can suppress both inherited global MCPs and hardcoded binary-bundled ones.
github-actions commentedon Jul 7, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.