Workspace .mcp.json silently skipped in non-interactive (-p) mode

[LangSensei]

Describe the bug

In non-interactive --prompt (-p) mode, MCP servers declared in the workspace-level .mcp.json are silently skipped at startup — they are never even attempted to start. copilot mcp list reports them as registered, but they do not appear in the agent's tool surface. Adding --yolo does not help (it controls tool-call permission, not server-startup gating).

The exact same configuration works correctly when:

• Running in interactive mode, or
• The same servers are placed in the user-level ~/.copilot/mcp-config.json, or
• The workspace config is passed explicitly via --additional-mcp-config @./.mcp.json.

This may be related to (but is distinct from) #2630, which reports a related-but-different surface: user-level mcp-config.json + custom-agent mcp-servers frontmatter not propagating into sub-agents / --prompt mode in v1.0.23. On v1.0.48-1 the user-level path appears to work in -p; the workspace-.mcp.json path does not.

Affected version

GitHub Copilot CLI 1.0.48-1

Steps to reproduce the behavior

1. In an empty directory, create ./.mcp.json with at least one stdio and one HTTP MCP server — anything public works, e.g.:

   {
     "mcpServers": {
       "filesystem": {
         "type": "stdio",
         "command": "npx",
         "args": ["-y", "@modelcontextprotocol/server-filesystem", "."]
       },
       "fetch": {
         "type": "stdio",
         "command": "npx",
         "args": ["-y", "@modelcontextprotocol/server-fetch"]
       }
     }
   }

   (Reproduced originally with three different servers — one HTTP and two stdio — but the behavior is independent of which servers are listed.)

2. Verify the CLI sees them:

   > copilot mcp list
   Workspace servers:
     filesystem (local)
     fetch (local)
   

3. Run a non-interactive prompt with --yolo:

   copilot -p "List every MCP tool you can actually call right now, grouped by server." --yolo --log-level info --log-dir ./logs
   

4. The agent reports that only github-mcp-server-* tools are available; tools from the workspace servers (filesystem, fetch) are missing.

5. Inspect the log file — only github-mcp-server is ever started; there is no log line attempting to start the workspace servers:

   [ERROR] Skipping disabled MCP server: computer-use
   [ERROR] Starting remote MCP client for github-mcp-server with url: https://api.enterprise.githubcopilot.com/mcp/readonly
   [ERROR] Creating MCP client for github-mcp-server...
   [ERROR] Connecting MCP client for github-mcp-server...
   [ERROR] MCP client for github-mcp-server connected, took 1141ms
   [ERROR] Started MCP client for remote server github-mcp-server
   [ERROR] GitHub MCP server configured after authentication
   

   So this is not a per-server start failure (auth, transport, command-not-found) — the workspace servers are filtered out before the start attempt.

6. Confirm by repeating step 3 with either workaround — both work end-to-end and all servers come online:

   # Workaround A: explicit additional config
   copilot -p "..." --yolo --additional-mcp-config "@./.mcp.json"
   
   # Workaround B: move the same content to user-level
   cp ./.mcp.json ~/.copilot/mcp-config.json
   copilot -p "..." --yolo
   

Config location	Interactive	-p --yolo
~/.copilot/mcp-config.json (user-level)	✅	✅
./.mcp.json (workspace, documented via copilot mcp --help)	✅	❌
--additional-mcp-config @./.mcp.json	—	✅

Expected behavior

Workspace-level .mcp.json MCP servers should be loaded in -p / --prompt mode, the same way they are loaded in interactive mode and the same way user-level servers are loaded in -p mode. At minimum, if there is an intentional trust gate that interactive mode satisfies via a TUI prompt (and which -p cannot satisfy), then either:

• -p should attempt the trust check and fall back to a non-interactive equivalent (e.g. honor --yolo / --allow-all-tools / a dedicated --trust-workspace-mcp flag), and/or
• A warning should be logged (Skipping workspace MCP server X: workspace not trusted in non-interactive mode) so the silent-skip behavior is at least diagnosable from the logs.

Today the only signal is that the agent reports the tools as missing — there is nothing in the logs naming the skipped servers.

Additional context

• OS: Windows 11 (10.0.26200), PowerShell 7
• Node: v24.3.0
• copilot mcp --help documents .mcp.json as a supported workspace config source:

  Configuration is loaded from multiple sources:
    User       ~/.copilot/mcp-config.json
    Workspace  .mcp.json
    Plugin     Installed plugins with MCP servers
  

• Repro is reliable: same .mcp.json, same cwd, same --yolo, only difference is interactive vs -p.
• Related (but distinct): Bug Report: Custom agent mcp-servers not connected in CLI sub-agent or --prompt contexts #2630 — that issue is about user-level config + custom-agent mcp-servers frontmatter not propagating to sub-agents / --prompt-as-primary on v1.0.23. The user-level path appears fixed on v1.0.48-1; the workspace path reported here is a separate gap.