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.

Start with workspace .mcp.json discovery as exercised by copilot mcp list and copilot mcp get, then trace session startup for the default, -i, and -p entry points. Compare those paths with a run using --additional-mcp-config @.mcp.json; done means a workspace server is available in all three session modes without the extra flag.