Summary
The current chat.pluginLocations setting requires a discrete entry for every installed plugin. When managing plugins from a shared marketplace or local repository, this becomes tedious to maintain — any newly added plugin requires a manual settings update to become discoverable.
Proposed Change
Allow chat.pluginLocations entries to point to a parent directory, and have VS Code recursively discover all valid plugin.json files within it. A path that does not itself contain a plugin.json at its root would be treated as a plugin parent/namespace directory rather than a single plugin entry.
Example
Given a local marketplace structure like:
~/my-marketplace/
plugins/
plugin-a/
plugin.json
plugin-b/
plugin.json
plugin-c/
plugin.json
A single settings entry:
"chat.pluginLocations": [
"~/my-marketplace/plugins"
]
...should resolve all three plugins automatically, without requiring:
"chat.pluginLocations": [
"~/my-marketplace/plugins/plugin-a",
"~/my-marketplace/plugins/plugin-b",
"~/my-marketplace/plugins/plugin-c"
]
Motivation
For plugin marketplace developers distributing multiple extensions from a shared directory, the current per-plugin entry model creates a maintenance burden both for the developer (who must document every install path) and the end user (who must update settings with each new plugin they add). Parent-directory resolution would make chat.pluginLocations scale naturally with any collection-based install pattern.
This would also pair well with the existing proposal to read from ~/.copilot/installed-plugins/ ( #302152 ) — both requests share the same underlying need: reduce the surface area users have to manually manage.
Behavioral Notes
- Existing single-plugin path entries should continue to work unchanged — this is purely additive
- Discovery should be shallow (one level deep) by default to avoid unintended traversal, with an opt-in for deeper resolution if needed
- Symlinks within the parent directory should be followed to support linked/managed installs
Summary
The current
chat.pluginLocationssetting requires a discrete entry for every installed plugin. When managing plugins from a shared marketplace or local repository, this becomes tedious to maintain — any newly added plugin requires a manual settings update to become discoverable.Proposed Change
Allow
chat.pluginLocationsentries to point to a parent directory, and have VS Code recursively discover all validplugin.jsonfiles within it. A path that does not itself contain aplugin.jsonat its root would be treated as a plugin parent/namespace directory rather than a single plugin entry.Example
Given a local marketplace structure like:
A single settings entry:
...should resolve all three plugins automatically, without requiring:
Motivation
For plugin marketplace developers distributing multiple extensions from a shared directory, the current per-plugin entry model creates a maintenance burden both for the developer (who must document every install path) and the end user (who must update settings with each new plugin they add). Parent-directory resolution would make
chat.pluginLocationsscale naturally with any collection-based install pattern.This would also pair well with the existing proposal to read from
~/.copilot/installed-plugins/( #302152 ) — both requests share the same underlying need: reduce the surface area users have to manually manage.Behavioral Notes