Plugin MCP servers cannot resolve the active project directory

[konard]

Describe the bug

An MCP server loaded from an installed plugin is launched with its working directory set to the plugin installation root, and the child process receives no project/workspace path. A project-scoped MCP server therefore reads and writes the plugin installation instead of the repository passed to Copilot CLI.

This is observable with Copilot CLI 1.0.73 on Linux when using either --plugin-dir or an installed plugin.

Steps to reproduce

1. Create a plugin manifest that points at a plugin-root MCP config:

{
  "name": "cwd-probe",
  "mcpServers": "./.mcp.json"
}

2. Use this .mcp.json:

{
  "mcpServers": {
    "probe": {
      "command": "sh",
      "args": [
        "-c",
        "pwd > /tmp/plugin-mcp-pwd.txt; env > /tmp/plugin-mcp-env.txt; exec my-mcp-server"
      ]
    }
  }
}

3. Run the plugin against a different project:

copilot -C /tmp/example-project --plugin-dir /tmp/cwd-probe

4. Inspect the captured files.

Actual behavior

• PWD is /tmp/cwd-probe, not /tmp/example-project.
• The MCP child receives COPILOT_PLUGIN_ROOT and PLUGIN_ROOT, but it does not receive COPILOT_PROJECT_DIR (plugin hooks do receive that variable).
• The MCP initialize request advertises only sampling and elicitation; it does not advertise MCP roots, so the server cannot request the workspace through roots/list.
• Setting "cwd": "${workspaceFolder}" leaves the value unresolved and fails before the child starts with No such file or directory (os error 2).

The full initialization payload captured from 1.0.73 was:

{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{"sampling":{},"elicitation":{"form":{},"url":{}}},"clientInfo":{"name":"github-copilot-developer","version":"1.0.73"}}}

Expected behavior

A plugin-provided MCP server needs a supported way to resolve the active project. Any one of these would unblock project-scoped servers:

• launch plugin MCP children from the active project directory;
• pass COPILOT_PROJECT_DIR to MCP children as Copilot already does for plugin hooks; or
• expose a documented project variable / MCP roots capability that plugin MCP configuration can pass to the server.

The plugin root should remain available separately through COPILOT_PLUGIN_ROOT.

Impact

Project-scoped MCP tools can silently operate on files inside the cached plugin installation. In archcore-ai/plugin#24, the MCP tools register and return success, but document writes land under the installed plugin rather than the project, which prevents a safe Copilot plugin release.