Workspace .mcp.json detected by 'mcp list'/'mcp get' but not connected in actual agent session (interactive/-i/-p)

Bug Report

Summary

Workspace .mcp.json MCP servers are correctly detected by copilot mcp list / copilot mcp get <name> (shown as Status: Enabled, Source: Workspace), but are not actually connected/available inside an agent session (interactive default session, -i auto-prompt, or -p non-interactive prompt) unless the same config is re-passed explicitly via --additional-mcp-config @.mcp.json.

This looks like a regression of #2198 (closed as fixed in 1.0.12) — the config-loading layer (mcp list/mcp get) now works, but the session-bootstrapping layer that actually wires servers into the running agent still doesn't pick up workspace config without an explicit flag.

Version

1.0.80 (macOS 26.5 / Sequoia, arm64, terminal-only workflow, no IDE attached)

Steps to Reproduce

1. In a project directory, create .mcp.json:

   {
     "mcpServers": {
       "my-server": {
         "type": "http",
         "url": "https://example.com/mcp",
         "oauth": { "clientId": "example-client" }
       }
     }
   }
   

2. From that directory, run copilot mcp get my-server → shows Status: Enabled, Source: Workspace (.../.mcp.json).
3. From the same directory, start a session and ask it to list available MCP servers, e.g.:

   copilot --allow-all-tools -p "List the MCP servers currently available in this session (just names)."
   

   or interactively with copilot (no extra flags).
4. my-server is missing from the tools/servers actually available to the agent.
5. Re-run with the config re-passed explicitly:

   copilot --allow-all-tools --additional-mcp-config @.mcp.json -p "List the MCP servers currently available in this session (just names)."
   

   → my-server now appears correctly.

Expected Behavior

If copilot mcp get <name> reports a workspace server as Status: Enabled, that server should be connected and its tools available in the actual agent session (interactive, -i, and -p) without needing to duplicate the same file via --additional-mcp-config.

Actual Behavior

• copilot mcp list / copilot mcp get — correctly detect and report the workspace server as enabled.
• Interactive session (no flags) — workspace server not available to the agent.
• -i "<prompt>" (interactive with auto-prompt) — workspace server not available.
• -p "<prompt>" (non-interactive) — workspace server not available.
• Adding --additional-mcp-config @.mcp.json on the command line — workspace server becomes available (redundant since the CLI already found the same file via workspace discovery).

Impact

This makes committed, repo-scoped .mcp.json files (the main use case — e.g. an internal MCP server URL with repo-specific query parameters scoping it to that project) effectively non-functional out of the box for terminal workflows. Users have to manually pass --additional-mcp-config @.mcp.json every single invocation, or write a shell wrapper to auto-detect and inject it — defeating the purpose of committing project-scoped MCP config to the repo for the whole team to use transparently.

Workaround

Manually pass --additional-mcp-config @.mcp.json on every invocation (or wrap copilot in a shell function that auto-detects .mcp.json in the cwd and injects the flag).

Related

• #2198 (closed as fixed in 1.0.12) — appears to have regressed, or only fixed the mcp list/mcp get discovery layer without fixing actual session wiring.

Inizia con la discovery di .mcp.json del workspace, come verificato da copilot mcp list e copilot mcp get, quindi traccia l’avvio della sessione per gli entry point default, -i e -p. Confronta questi percorsi con un’esecuzione che usa --additional-mcp-config @.mcp.json; il lavoro è completato quando un server del workspace è disponibile in tutte e tre le modalità di sessione senza il flag aggiuntivo.