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

[ssolomentsev]

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

• .mcp.json workspace config not loaded at startup — requires /mcp reload #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.

[harshini2004-tech]

Reproduced on Windows - Confirming the Bug
I can confirm this issue is reproducible on Windows with Copilot CLI 1.0.80.

Test Environment
OS: Windows 10/11
Copilot CLI Version: 1.0.80
MCP SDK: Python mcp==2.0.0
Mode: Non-interactive (-p)

Steps to Reproduce
server.py

from mcp.server.mcpserver import MCPServer

server = MCPServer(name="test-server", version="1.0.0")

def test_tool() -> str:
    """Returns a message proving the MCP server is connected."""
    return "TEST-MCP-CONNECTED"

server.add_tool(
    test_tool,
    name="test_tool",
    description="Returns a message proving the MCP server is connected."
)

if __name__ == "__main__":
    import asyncio
    asyncio.run(server.run_stdio_async())

.mcp.json:

{
  "mcpServers": {
    "test-server": {
      "type": "stdio",
      "command": "python",
      "args": [
        "C:\\Users\\harshini\\mcp-test\\server.py"
      ]
    }
  }
}

Discovery Works

> copilot mcp list
Workspace servers:
  test-server (local)

Session wiring fails (without --additional-mcp-config):

> copilot --allow-all-tools -p "Use test_tool tool"
I don't have access to a tool called "test_tool" in my available toolkit.

Explicit config works (with --additional-mcp-config):

> copilot --allow-all-tools --additional-mcp-config "@.mcp.json" -p "Use test_tool tool"
● test_tool (MCP: test-server)
  └ TEST-MCP-CONNECTED

Impact
copilot mcp list correctly discovers the workspace .mcp.json server, but the server is not actually wired into the agent session for -p non-interactive mode. The same config works perfectly when passed explicitly via --additional-mcp-config @.mcp.json.

This completely breaks the primary use case of committing project-scoped .mcp.json files to repositories for team-wide use, as every user would need to manually pass the --additional-mcp-config flag or create shell wrappers.