Repository navigation
Expose catalogue APIs in the Copilot SDK #2106
Description
Outcome
Copilot clients receive thin, generated bindings for runtime catalogue operations.
Work
- Promote stable search bindings independently of unfinished installation work.
- Fix nested-union generation and add semantic package conformance across supported languages.
- Add plan and apply bindings only after runtime operations exist.
- Add future materialisation bindings without moving download or policy logic into the SDK.
Done when
Published SDK packages preserve typed candidates, failures, handles, and protocol compatibility across languages using the exact released runtime schema.
The SDK transports operations. Runtime owns retrieval, validation, policy, planning, apply, and recovery.
Delivery status (18 September 2026)
This closed issue records the delivered typed catalogue baseline, including the accepted Java candidate-union repair #2532 and stable search transport.
Remaining original package-conformance evidence is tracked by #2389 under the active installation outcome github/copilot-ecosystem#1233. It is no longer a native child of this completed baseline.
Newly merged selection/pagination/Plugin release work is tracked separately at #2719. Future executable planning/apply release work depends on its runtime implementation. Closed baseline status is not a claim that those future operations or client installation UX have shipped. Do not revive the rejected broad decoder changes from #2486.
Activity
[-][Batch] Expose typed search, plan, and apply APIs in the Copilot SDK[/-][+]Expose typed search, plan, and apply APIs in the Copilot SDK[/+]nytron88 commentedon Jul 31, 2026
SDK-side status: blocked on a CLI release that carries the typed contract.
I checked every
@github/copilotrelease published since copilot-agent-runtime#13734 landed (2026-07-28), and none of them ships the typed catalog contract yet — so there is currently nothing for the SDK to expose.Worth stating up front, because it makes this a pure waiting problem: the SDK generates its whole RPC surface from
schemas/api.schema.jsonin the installed CLI platform package, and the generator is schema-driven with no method allowlist.client.rpc.catalog.search(...)andclient.rpc.mcp.planInstall(...)will therefore appear by themselves, in all six SDKs, as soon as the schema carries them. No SDK-side plumbing is needed.What I inspected, in
@github/copilot-darwin-arm64@<version>/schemas/api.schema.json:server.catalogmcp.planInstallCatalog*defsFor 1.0.78-0 I scanned the entire document rather than just the
servergroup — all 334rpcMethodstrings and all 1024 definitions — matchingsearch|plan|install|apply|catalog|registry|discover|finder|market. Results:catalognamespace anywhere;models.getBuiltInCatalogis a model catalog and unrelated.server.mcpis still exactlyconfig.{list,add,update,remove,enable,disable,reload}plusdiscover. NoplanInstall.Catalog*definitions and zeroAgentFinder*definitions.plugins.install, which is a different contract: it installs plugins (not MCP servers from a catalog) and it is a single-call install with no plan/review/apply split.Could someone confirm which CLI release will carry #13734's schema? Once it is published, the SDK side is a dependency bump plus a regenerate, and I will pick it straight up.
In the meantime I am deliberately not hand-writing the request/response types. Hand-mirrored types drifting from the runtime contract is precisely the failure this issue exists to prevent, so approximating the shapes now would make things worse rather than unblock anything.
[-]Expose typed search, plan, and apply APIs in the Copilot SDK[/-][+]Expose catalogue APIs in the Copilot SDK[/+]