Add --disable-repo-mcps flag to skip loading MCPs from .mcp.json / .github/mcp-config.json #3380

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:

1. 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.

2. The repo's MCP definitions require dependencies I don't have installed, blocking the CLI from starting cleanly.

3. 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.