Support Copilot CLI Plugins Scoped to Project or Repository (instead of per-user)

[willmarkley]

Describe the feature or problem you'd like to solve

Support Copilot CLI Plugins Scoped to Project or Repository (instead of per-user)

Proposed solution

Today, Copilot CLI plugins are installed per user and loaded globally. This makes it difficult to enable repo/project-specific plugins for workflows, experimentation, or hybrid approaches.

The feature requested is:

• Enable support for plugin installation, discovery, and loading based on a repo or project config (for example, with .github/plugins or similar)
• Plugins defined in repo/project configs should supersede user/global plugins for that repo
• Allow plugin activation only in the context of the given repo/project (so plugins don't affect workflows outside the project)

This would bring plugin scoping more aligned with practices in other CLI tools (e.g., npm, yarn, poetry, etc.).

Example prompts or workflows

• A repository includes a .github/plugins directory defining plugins for that project, rather than the ~/.copilot/installed_plugins; upon running Copilot CLI in that repo, those plugins are activated and others are deactivated.
• User can experiment with a plugin in their fork or branch without affecting global/plugin state.

Additional context

• See docs for current plugin mechanics.
• This brings parity with other tools that allow local vs global plugin scoping, like Claude Code CLI
• Some Copilot CLI configuration is already repo- or project-local (e.g., custom agents or context), but plugins must be installed globally.