Expose catalogue APIs in the Copilot SDK

[gokhanarkan]

Outcome

Copilot clients receive thin, generated bindings for runtime catalogue operations.

Work

1. Promote stable search bindings independently of unfinished installation work.
2. Fix nested-union generation and add semantic package conformance across supported languages.
3. Add plan and apply bindings only after runtime operations exist.
4. 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.

[nytron88]

SDK-side status: blocked on a CLI release that carries the typed contract.

I checked every @github/copilot release 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.json in the installed CLI platform package, and the generator is schema-driven with no method allowlist. client.rpc.catalog.search(...) and client.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:

Version	Published	server.catalog	mcp.planInstall	Catalog* defs
1.0.73 (currently pinned)	2026-07-23	absent	absent	0
1.0.76-1 (first release after #13734)	2026-07-28	absent	absent	0
1.0.76	2026-07-30	absent	absent	0
1.0.77 (latest stable)	2026-07-30	absent	absent	0
1.0.78-0 (latest incl. prereleases)	2026-07-31	absent	absent	0

For 1.0.78-0 I scanned the entire document rather than just the server group — all 334 rpcMethod strings and all 1024 definitions — matching search|plan|install|apply|catalog|registry|discover|finder|market. Results:

• No catalog namespace anywhere; models.getBuiltInCatalog is a model catalog and unrelated.
• server.mcp is still exactly config.{list,add,update,remove,enable,disable,reload} plus discover. No planInstall.
• No apply method for an install plan.
• Zero Catalog* definitions and zero AgentFinder* definitions.
• The nearest existing surface is 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.