Cross-IDE Plugin Discovery¶

Cross-IDE plugin discovery has one CLI install write to a shared per-user path every IDE reads, collapsing repeated installs but widening supply-chain blast radius.

The file-system contract¶

Cross-IDE plugin discovery is a one-way file-system contract. The install surface (a CLI, a package manager, an MDM channel) writes plugin manifests to a well-known per-user path. Every consumer (IDE, headless agent, second IDE) reads that path on startup and on filesystem-change events. No coordination protocol runs between them — the path is the protocol.

graph LR
    A[copilot plugin install] --> B[~/.copilot/installed-plugins/]
    B --> C[VS Code]
    B --> D[Headless agent]
    B --> E[Future consumer]

The writer does not need to know what consumers exist, and consumers do not coordinate with each other. The same convention underlies ~/.config/, ~/.local/share/, and the GnuPG agent's ~/.gnupg/ — shared state held in a stable path rather than a coordination protocol (XDG Base Directory Specification).

Reference implementation: VS Code 1.120 + Copilot CLI¶

VS Code 1.120 (released May 13, 2026) auto-discovers plugins installed through the GitHub Copilot CLI: "Agent plugins installed with the GitHub Copilot CLI are picked up automatically by VS Code, so a single copilot plugin install covers both surfaces" (VS Code 1.120 release notes).

The on-disk layout is documented:

The CLI writes to ~/.copilot/installed-plugins/<marketplace>/<plugin>/ for marketplace installs.
Direct-from-Git installs land under a _direct bucket, for example ~/.copilot/installed-plugins/_direct/github--moda-linter--copilot-plugin/.
VS Code surfaces discovered plugins in the Agent Plugins - Installed view alongside marketplace-installed plugins (VS Code agent-plugins docs).

Before 1.120, you had to install the plugin separately in each IDE or set chat.plugins.paths by hand. The contract did not change the plugin format. It changed which surface owns the install.

What the contract does not override¶

Auto-discovery reads the install state. It does not grant execution. Two gates still apply in the reference implementation:

chat.plugins.enabled must be on for agent plugins to run, and an administrator can manage this setting at the organization level. A CLI install does not bypass an org policy that disables agent plugins (VS Code agent-plugins docs).
Workspace Trust still gates execution: "if the workspace is untrusted in VS Code, it is also untrusted in the Agents window, and agents will not run in either place" (VS Code Trust and safety).

The contract covers install state, not authorization. Each consuming surface stays responsible for its own runtime gates.

Where the contract breaks¶

Cross-IDE discovery is a per-user, per-machine convention. It depends on every consumer agreeing to read the same path. As of late 2025 the contract is partial:

JetBrains, Eclipse, and Xcode Copilot plugins added custom-agent and skill support in November 2025, but they install through the JetBrains Marketplace and equivalents — they do not read ~/.copilot/installed-plugins/ (GitHub Changelog). A team with mixed IDEs still needs a parallel install path for the surfaces that do not take part.
Direct-from-Git installs hit known discovery bugs. copilot plugin install owner/repo sets cache_path to the repo root and skips .github/plugin/plugin.json (copilot-cli issue #2390). The shared install surface passes CLI bugs into every consuming IDE on the same machine.
Trust scope mismatch: the path is per-user. On a multi-tenant or shared-workstation machine (lab, classroom, kiosk), one user account may stand for several trust contexts. Cross-surface discovery couples them in a way that is wrong when each IDE session stands for a different role.

Supply-chain implication¶

A single install surface concentrates supply-chain risk. PromptArmor demonstrated marketplace-plugin injection attacks that hijack agent sessions; SentinelOne documented marketplace skills that redirect dependency installs. With per-IDE installs, a poisoned plugin only reaches the surface where you installed it. With CLI-as-shared-install-surface, one copilot plugin install reaches every consuming agent on the machine.

The fix is not to abandon the contract. Treat the CLI install as the single audit point. Pin plugin versions, prefer organization-managed marketplaces, and review every installed-plugins/ entry the way you would an extension installed in every IDE on the machine.

Designing for the contract¶

Tools that take part as either writer or reader of a cross-IDE install surface need three things:

A documented per-user path. It stays stable across versions, you can derive it without invoking the install surface, and it sits under an XDG-compliant base directory.
A manifest format the consumer parses without running the writer. VS Code reads ~/.copilot/installed-plugins/ without running the Copilot CLI — discovery is filesystem-only.
A clear split between install state and execution authorization. The path says what is installed; whether to run it stays the consumer's policy decision.

Example¶

The layout written by copilot plugin install is the contract VS Code reads. A marketplace install and a direct-from-Git install land in different sub-trees but use the same parent path:

~/.copilot/installed-plugins/
├── github/                                    # marketplace name
│   └── moda-linter-copilot-plugin/
│       ├── plugin.json
│       ├── agents/
│       └── skills/
└── _direct/                                   # direct-from-Git bucket
    └── github--moda-linter--copilot-plugin/
        ├── plugin.json
        ├── agents/
        └── skills/

After copilot plugin install github/moda-linter/copilot-plugin, the plugin appears in the Agent Plugins - Installed view in VS Code without a separate VS Code install step. Any other consumer that adopts the contract reads the same files — that is the whole point.

Key Takeaways¶

A shared-install-surface contract is a one-way file-system convention: writer puts manifests at a stable per-user path, every consumer reads them without coordination.
VS Code 1.120 + Copilot CLI is the reference implementation — ~/.copilot/installed-plugins/<marketplace>/<plugin>/, with _direct for Git installs.
Auto-discovery is install-state-only — runtime gates (chat.plugins.enabled, Workspace Trust) still apply.
The contract is partial in late-2025 multi-IDE fleets: JetBrains, Eclipse, and Xcode Copilot plugins do not yet read the path.
Concentrating installs concentrates supply-chain risk — treat the CLI install as the single audit point, pin versions, prefer org-managed marketplaces.