[Early POC] Expose the extension launch provider in the Node SDK

[jruales]

Summary

Expose the runtime's existing extension-launch-provider protocol through an optional Node SDK callback. This enables hosts such as VS Code to use runtime-discovered standalone extensions, including third-party Canvases, without implementing another extension loader.

• Add CopilotClientOptions.onExtensionLaunch and export the existing launch request/result/profile types.
• Forward extensionLaunchProvider.resolve requests to the callback.
• Await registerExtensionLaunchProvider() during start(), before callers create sessions; registration errors reject startup.
• Expose CopilotClient.supportsExtensionLaunchProvider so integrations can safely gate extension opt-in while supporting older SDK versions.
• Document launch specifications and add focused registration/forwarding/failure tests.

Ownership and scope

The callback only returns { launch: { executable, args, env } }, or {} for unsupported entrypoints. The runtime continues to own extension discovery, process creation, lifecycle, and reserved SDK/session environment variables.

This does not change the runtime or implement Canvas rendering. The VS Code prototype returns a launch specification using the selected runtime's existing extension bootstrap and renders extension-provided HTTP(S) URLs in its Integrated Browser.

Without a registered provider, the runtime rejected standalone extension activation with No extension launch provider is registered for standalone extensions. The relevant protocol already existed; this change supplies the Node SDK hookup.

Validation

• npm test -- test/client.test.ts -t 'extension launch provider': 2 passed.
• Live VS Code integration with the built SDK: extension discovery, Canvas opening, action invocation, snapshot reconciliation, and closing.
• A full test/client.test.ts run in this checkout was not green: 71 passed and 126 failed. Inspected failures report the missing local @github/copilot-sdk-darwin-arm64 runtime package. The focused tests above do not require that package.
• git diff --check passed.

Draft / discussion

Companion integration: microsoft/vscode#335640.

This is a prototype integration dependency, not a runtime fork. The public callback and capability-marker shape are proposed for review. A consuming VS Code dependency update must follow an SDK release.

[github-actions]

SDK Consistency Review — PR #2618

Scope of change: Adds a client-level extension launch provider API to the Node.js SDK only:

• CopilotClientOptions.onExtensionLaunch (callback)
• CopilotClient.supportsExtensionLaunchProvider (static capability flag)
• Automatic registerExtensionLaunchProvider registration during client.start(), with startup failing if registration is rejected
• README documentation and unit tests

Cross-SDK findings:

SDK	Generated RPC types/method	High-level client API
Node.js	✅	✅ (this PR)
Rust	✅	✅ (pre-existing: ClientOptions::with_extension_launch_provider)
Go	✅ (generated)	❌ missing
Python	✅ (generated)	❌ missing
.NET	✅ (generated)	❌ missing
Java	✅ (generated)	❌ missing

The underlying RPC schema (ExtensionLaunchProfile, ExtensionLaunchProviderResolveRequest/Result, registerExtensionLaunchProvider) is present in every language's generated layer, since it comes from the shared CLI schema — no action needed there. Rust already ships an equivalent high-level convenience wrapper. This PR brings Node.js to parity with Rust, but leaves Go, Python, .NET, and Java without an ergonomic way to register an extension launch provider (they'd need to call the generated low-level RPC method directly and implement the client-global handler wiring themselves).

Suggestion: Since this is marked @experimental, it's reasonable to land the Node.js piece first, but consider tracking follow-up work to add equivalent high-level APIs to Go, Python, .NET, and Java before the feature is stabilized, to avoid long-term feature-parity drift. Left an inline comment on nodejs/src/client.ts with per-language naming suggestions.

No other consistency issues found — the rest of the diff (README updates, type exports, tests) is Node.js-internal and consistent with existing SDK conventions.

Generated by SDK Consistency Review Agent for #2618 · copilot · sonnet50 · 28.5 AIC · ⌖ 14.2 AIC · ⊞ 8.3K · ◷

[github-actions]

Generated by SDK Consistency Review Agent for #2618 · copilot · sonnet50 · 28.5 AIC · ⌖ 14.2 AIC · ⊞ 8.3K

[github-actions]

Cross-SDK consistency: onExtensionLaunch / extension launch provider is Node.js-only

This PR wires up a client-level, high-level API for the extension launch provider feature in the Node.js SDK (CopilotClientOptions.onExtensionLaunch, CopilotClient.supportsExtensionLaunchProvider, and automatic registerExtensionLaunchProvider registration during start()).

The generated RPC primitives (ExtensionLaunchProfile, ExtensionLaunchProviderResolveRequest/Result, registerExtensionLaunchProvider) already exist in every generated layer (Go, Python, .NET, Java, Rust), since those are produced from the shared CLI schema. However, only Rust also has a matching high-level convenience API (ClientOptions::with_extension_launch_provider in rust/src/lib.rs / rust/src/extension_launch_provider.rs). Go, Python, .NET, and Java currently expose only the low-level generated RPC method/types and have no ergonomic client option to register a launch provider or a supports_extension_launch_provider-equivalent capability flag.

Suggestion: consider adding the equivalent high-level wiring to Go, Python, .NET, and Java (following each language's naming convention, e.g. with_extension_launch_provider in Python, WithExtensionLaunchProvider/SupportsExtensionLaunchProvider in Go/.NET, onExtensionLaunch/supportsExtensionLaunchProvider in Java) in a follow-up PR, so this experimental feature reaches parity across SDKs before it graduates from @experimental.