Bug Report
Summary
When starting a new Copilot CLI session in a directory containing a .mcp.json file, the workspace MCP servers are not loaded at startup. Running /mcp reload after the session starts causes them to appear correctly. This makes the workspace config feature unreliable for terminal-based workflows.
Version
1.0.10
Steps to Reproduce
- Create a
.mcp.json in a project directory (using the mcpServers key format)
- Open a new terminal session in that directory
- Start Copilot CLI from that directory
- Run
/mcp show — workspace servers are missing
- Run
/mcp reload
- Run
/mcp show again — workspace servers now appear correctly
Expected Behavior
.mcp.json in the current working directory should be loaded at startup, the same way ~/.copilot/mcp-config.json is. The CLI already knows its CWD at launch — there's no reason to defer loading workspace config.
Actual Behavior
Workspace configs (.mcp.json, .vscode/mcp.json) are only loaded after an IDE lock file establishes workspace context. In a pure terminal workflow (no VS Code or IDE open), this context is never established at startup — meaning workspace MCP servers silently don't load until /mcp reload is run manually.
Root Cause (from source inspection)
Looking at app.js in ~/.copilot/pkg/universal/1.0.10/, workspace config loading appears to be gated on IDE lock file presence (the mechanism used to detect an attached VS Code/IDE workspace). In a terminal-only session, no lock file exists at startup, so the workspace folder is unknown and .mcp.json is skipped.
The global config (~/.copilot/mcp-config.json) does not have this gating and loads correctly at startup.
Why This Matters
This behavior makes .mcp.json effectively broken for terminal-first developers. The whole point of workspace-local MCP config is to commit it to the repo so the team doesn't have to manually configure each server — but if it silently doesn't load, developers won't notice until something fails.
Workaround
Run /mcp reload at the start of every session. Functional but annoying.
Environment
- macOS Sequoia
- Copilot CLI
1.0.10
- Terminal-only workflow (no IDE attached)
Bug Report
Summary
When starting a new Copilot CLI session in a directory containing a
.mcp.jsonfile, the workspace MCP servers are not loaded at startup. Running/mcp reloadafter the session starts causes them to appear correctly. This makes the workspace config feature unreliable for terminal-based workflows.Version
1.0.10Steps to Reproduce
.mcp.jsonin a project directory (using themcpServerskey format)/mcp show— workspace servers are missing/mcp reload/mcp showagain — workspace servers now appear correctlyExpected Behavior
.mcp.jsonin the current working directory should be loaded at startup, the same way~/.copilot/mcp-config.jsonis. The CLI already knows its CWD at launch — there's no reason to defer loading workspace config.Actual Behavior
Workspace configs (
.mcp.json,.vscode/mcp.json) are only loaded after an IDE lock file establishes workspace context. In a pure terminal workflow (no VS Code or IDE open), this context is never established at startup — meaning workspace MCP servers silently don't load until/mcp reloadis run manually.Root Cause (from source inspection)
Looking at
app.jsin~/.copilot/pkg/universal/1.0.10/, workspace config loading appears to be gated on IDE lock file presence (the mechanism used to detect an attached VS Code/IDE workspace). In a terminal-only session, no lock file exists at startup, so the workspace folder is unknown and.mcp.jsonis skipped.The global config (
~/.copilot/mcp-config.json) does not have this gating and loads correctly at startup.Why This Matters
This behavior makes
.mcp.jsoneffectively broken for terminal-first developers. The whole point of workspace-local MCP config is to commit it to the repo so the team doesn't have to manually configure each server — but if it silently doesn't load, developers won't notice until something fails.Workaround
Run
/mcp reloadat the start of every session. Functional but annoying.Environment
1.0.10