Describe the feature or problem you'd like to solve
Today there is no clean way to launch copilot while ignoring the MCP definitions a repository ships in ./.mcp.json or .github/mcp-config.json — you can only disable MCPs at a per-name granularity via --disable-mcp-server <name> (repeatable), which requires knowing every name the repo defines and re-typing them on every launch.
This matters in a few real situations:
-
A repo's MCP config silently shadows my user-level config. See the related bug report (#3379) where .mcp.json in a repo overrode my user-level playwright MCP (which was correctly configured with --browser msedge) with a default-browser version that tried to launch chrome. I couldn't fix this without:
- Editing
.mcp.json (a shared tracked file in the repo — I shouldn't commit that change)
- Or temporarily renaming/moving it
- Or remembering to type
--disable-mcp-server playwright --disable-mcp-server <other-server-1> --disable-mcp-server <other-server-2> ... every time I launch copilot in that repo.
None of these are reasonable workflows.
-
The repo's MCP definitions require dependencies I don't have installed, blocking the CLI from starting cleanly.
-
I trust my own user-level MCP config but not necessarily the MCP servers a freshly-cloned repo brings in (security/supply-chain consideration). Today the only mitigation is reviewing/editing every cloned repo's .mcp.json before first launch.
A prior CLI session also reached the same dead end while researching options — the closest workarounds we could find were:
- Launching from a different cwd (
copilot -C $HOME) and then /cwd-ing in, which is awkward and fights the CLI's workspace-awareness.
- Wrapping
copilot in a shell alias that hard-codes every repo MCP name to disable, which doesn't scale across repos.
Proposed solution
Add a CLI flag (suggested name: --disable-repo-mcps) that prevents the CLI from loading MCP definitions from any repository-scoped config file. Only built-in MCPs and user-level MCPs ($HOME/.copilot/mcp-config.json) would be considered.
Example:
copilot --disable-repo-mcps
Additional refinements worth considering:
- Persist as a session setting the way
--experimental does, so users who always want this behavior in certain environments can set it once.
- Show repo MCPs as disabled in
/mcp with a note like (skipped: --disable-repo-mcps), so it's discoverable.
- Allow opt-in re-enablement of specific repo MCPs via something like
--enable-mcp-server <name> for symmetry with the existing --disable-mcp-server <name>. (Optional; the headline flag alone covers most cases.)
- Companion env var (e.g.,
COPILOT_DISABLE_REPO_MCPS=1) for users who want it set per-shell without editing aliases.
Example prompts or workflows
Workflow 1 — my user-level MCP setup is canonical and I never want repos to override it:
alias copilot='copilot --disable-repo-mcps'
...and now cd-ing into any cloned repo just works with my own MCP toolchain, ignoring whatever the repo happens to ship.
Workflow 2 — I want to quickly check what a repo defines without it actually loading:
cd some-repo
copilot --disable-repo-mcps
/mcp # shows repo-defined entries grayed out / skipped
Workflow 3 — troubleshooting #3379-style naming conflicts:
copilot --disable-repo-mcps # confirm the user-level config works in isolation
copilot # bring repo MCPs back in to reproduce the conflict
Additional context
- Related bug: #3379 — MCP naming conflict where
/mcp UI lists user-level entry but runtime uses repo-level settings. The frustration trail referenced above came from trying to work around exactly that bug without a --disable-repo-mcps-style flag.
- The existing
--disable-builtin-mcps flag is a partial precedent for scope-based disabling; this would be its repo-scope counterpart.
- Affected version: 1.0.49-6.
Describe the feature or problem you'd like to solve
Today there is no clean way to launch
copilotwhile ignoring the MCP definitions a repository ships in./.mcp.jsonor.github/mcp-config.json— you can only disable MCPs at a per-name granularity via--disable-mcp-server <name>(repeatable), which requires knowing every name the repo defines and re-typing them on every launch.This matters in a few real situations:
A repo's MCP config silently shadows my user-level config. See the related bug report (#3379) where
.mcp.jsonin a repo overrode my user-level playwright MCP (which was correctly configured with--browser msedge) with a default-browser version that tried to launch chrome. I couldn't fix this without:.mcp.json(a shared tracked file in the repo — I shouldn't commit that change)--disable-mcp-server playwright --disable-mcp-server <other-server-1> --disable-mcp-server <other-server-2> ...every time I launchcopilotin that repo.None of these are reasonable workflows.
The repo's MCP definitions require dependencies I don't have installed, blocking the CLI from starting cleanly.
I trust my own user-level MCP config but not necessarily the MCP servers a freshly-cloned repo brings in (security/supply-chain consideration). Today the only mitigation is reviewing/editing every cloned repo's
.mcp.jsonbefore first launch.A prior CLI session also reached the same dead end while researching options — the closest workarounds we could find were:
copilot -C $HOME) and then/cwd-ing in, which is awkward and fights the CLI's workspace-awareness.copilotin a shell alias that hard-codes every repo MCP name to disable, which doesn't scale across repos.Proposed solution
Add a CLI flag (suggested name:
--disable-repo-mcps) that prevents the CLI from loading MCP definitions from any repository-scoped config file. Only built-in MCPs and user-level MCPs ($HOME/.copilot/mcp-config.json) would be considered.Example:
Additional refinements worth considering:
--experimentaldoes, so users who always want this behavior in certain environments can set it once./mcpwith a note like(skipped: --disable-repo-mcps), so it's discoverable.--enable-mcp-server <name>for symmetry with the existing--disable-mcp-server <name>. (Optional; the headline flag alone covers most cases.)COPILOT_DISABLE_REPO_MCPS=1) for users who want it set per-shell without editing aliases.Example prompts or workflows
Workflow 1 — my user-level MCP setup is canonical and I never want repos to override it:
...and now
cd-ing into any cloned repo just works with my own MCP toolchain, ignoring whatever the repo happens to ship.Workflow 2 — I want to quickly check what a repo defines without it actually loading:
Workflow 3 — troubleshooting #3379-style naming conflicts:
Additional context
/mcpUI lists user-level entry but runtime uses repo-level settings. The frustration trail referenced above came from trying to work around exactly that bug without a--disable-repo-mcps-style flag.--disable-builtin-mcpsflag is a partial precedent for scope-based disabling; this would be its repo-scope counterpart.