Copilot CLI plugin reference: category/tags documented as plugin.json fields the CLI does not implement, and the Open Plugin Spec section is empty

[unional]

Page: https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-plugin-reference
Source: content/copilot/reference/copilot-cli-reference/cli-plugin-reference.md

Summary

Two defects on the CLI plugin reference page. They're independent — happy to split into separate issues if you'd prefer.

Both were found while building tooling that generates Copilot CLI plugin manifests from an Agent Plugins Specification v1.0.0 manifest, so the page is being read closely as a contract.

Defect 1 — category and tags are listed as plugin.json fields, but the CLI has no handling for them there

The ## plugin.json → ### Optional metadata fields table lists:

Field	Type	Description
category	string	Plugin category.
tags	string[]	Additional tags.

The shipped CLI does not recognize either field in plugin.json. Verified against @github/copilot-linux-x64 1.0.83 (the plugin loader is in prebuilds/linux-x64/runtime.node):

• The manifest validator has dedicated diagnostics for the fields it knows, including keywords:

  Plugin manifest "…": field "keywords" must be an array of strings (ignored)
  

  There is no corresponding message for category or for tags. Both fall to the generic unknown-field path:

  Plugin manifest "…": unknown field "…" (ignored)
  

• Confirmed at runtime: a plugin.json carrying category, tags, and a deliberately bogus key installs cleanly with no diagnostic about any of them.

Both fields are implemented on marketplace.json plugin entries, where they're type-checked — and strictly, a wrong type is a fatal error rather than a warning:

Failed to browse marketplace: Invalid marketplace.json:
  plugins.0.category: Expected string, received number,
  plugins.0.tags: Expected array, received string

So the fields are real, but the reference documents them in the wrong place: they belong to the catalog schema, not the plugin manifest schema. (The same table appears correctly under the marketplace.json plugin-entry fields further down the page.)

Corroborating signal that manifest-level category/tags aren't a real surface: GitHub's own marketplace catalog, github/copilot-plugins .github/plugin/marketplace.json, has 17 entries and sets category and tags zero times, while populating keywords on 15 of 17.

Suggested fix: remove category and tags from the plugin.json optional-metadata table, or annotate them as catalog-entry fields that the plugin manifest ignores. If the CLI is intended to read them from plugin.json, then this is a CLI bug rather than a docs bug and belongs in github/copilot-cli.

Why this matters: the Agent Plugins Specification manifest schema is closed (additionalProperties: false), so a manifest carrying category/tags is non-conformant. Authors reading this table conclude they must choose between spec conformance and Copilot metadata. They don't — the fields do nothing there. The page as written manufactures a dilemma.

Defect 2 — the "Open Plugin Spec support" section is an empty bullet list

Current content, verbatim:

## Open Plugin Spec support

Declaring the canonical `$schema` in `plugin.json` opts a plugin into the [Agent Plugins (Open Plugin Spec)](https://agent-plugins.org) v1.0.0 format, additively on top of standard plugin loading:


### LSP server configuration

The sentence ends in a colon, then a blank line, then the next heading. The list never renders — same in the raw source and on the published page.

This looks like a content-pipeline artifact rather than an authoring omission: the section was introduced already empty in 49eadc3f (2026-07-24, "docs: update copilot-cli content from source docs", #62433 — the sync following the 1.0.74 release that shipped Open Plugin Spec support), and has survived five subsequent syncs plus a human edit (f2bc8766, 2026-09-01).

Why this matters: that list is the only place the docs would state what "additively on top of standard plugin loading" means — specifically, what happens to Copilot's native-only manifest fields once a plugin declares the spec $schema. With it empty, that behavior is undocumented, and Defect 1 is exactly the kind of question it would answer.

Suggested fix: restore the list from the internal source, and check whether other sections synced by the same pipeline lost list content on the same date.

Scope of verification

Verified on @github/copilot-linux-x64 1.0.83 on Linux x64, against the docs as of 2026-09-07. I did not check other platform builds. The plugin loader is a stripped binary, so I can state with confidence which fields have dedicated validation messages and that neither category nor tags has any manifest-level handling; I cannot enumerate the complete known-field allow-list.