Repository navigation
[v2] Consolidate runtime discovery, acquisition, and embedding #2524
Description
Summary
Complete a coherent model for locating, acquiring, packaging, and embedding the Copilot runtime across all SDKs.
These items are planned work carried forward from #1934. Existing work may satisfy part of the required outcome; verify and build on it rather than reopening completed implementation. Do not omit remaining work without concrete new evidence and maintainer agreement.
Why this work exists
The original Rust build.rs was forked between in-process and out-of-process modes for backward compatibility. In-process operation needed the .node native binary, which was available from @github/copilot on npm but was not included in the GitHub CLI release. Depending on npm for that binary was not considered viable long term.
Rust and Go also used build-time flags to choose whether the in-process binary was embedded because it duplicated the Copilot SEA executable already embedded in the application bundle.
Python independently performed executable resolution through PATH (introduced by commit 05dd60e), which could select an arbitrary system installation rather than the runtime expected by the SDK.
Required outcomes
- Python does not implicitly select an executable through
PATH; it uses the SDK-managed runtime or an explicitly configured path. - The underlying runtime build and publishing process publishes the required raw native binaries as separate GitHub Release assets.
- SDKs acquire pinned, checksum-verified runtime artifacts from
github/copilot-cliGitHub Releases rather than depending on@github/copilotnpm artifacts. - Obsolete Rust and Go compile-time choices for embedding the in-process native library versus the executable runtime are removed.
- Packaging converges on a minimal bootstrap executable plus the required native dynamic library without duplicating the full SEA/native runtime payload.
- All supported platforms, offline/development scenarios, explicit overrides, checksums, and cache replacement behavior are covered.
Implementation preparation
- Determine exactly which outcomes Launch managed SDK servers through the Rust runtime wrapper #2395, Use Copilot CLI releases for Node runtime #2463, and Use GitHub Releases for SDK runtime artifacts #2505 already satisfy.
- Complete rather than duplicate applicable in-progress work.
- Identify and link any missing release assets or changes required from
github/copilot-cli. - If a remaining change is compatible with v1, it may land there as groundwork while remaining part of this tracked outcome.
- Preserve backward compatibility where it does not conflict with the intended v2 cleanup, and document any runtime-version requirements.
Historical context
- [Tracking] In-process (FFI) items to be cleaned up #1934
- Commit
05dd60e - Launch managed SDK servers through the Rust runtime wrapper #2395
- Use Copilot CLI releases for Node runtime #2463
- Use GitHub Releases for SDK runtime artifacts #2505
Completion
Deliver the required outcomes across affected SDKs with a documented artifact contract and platform coverage. Any outcome considered obsolete or infeasible requires concrete evidence and explicit maintainer agreement before it is removed from scope.
Activity
github-actions commentedon Sep 4, 2026
This issue is a tracking/assessment item for the SDK v2 effort (sub-issue of #2522), asking the team to evaluate and consolidate runtime discovery/acquisition/embedding decisions across repos rather than describing a single bug, feature request, question, or doc gap. It doesn't fit the automated bug/enhancement/question/documentation classifications, so it hasn't been routed to a handler. A human maintainer should review and triage it directly.
SteveSandersonMS commentedon Sep 4, 2026
Reconciliation with landed/in-flight work
I checked latest
main(0921029) and the in-flightroji-unify-runtime-artifactsbranch (#2505, currently open, all review threads resolved, approved, CI green as of this writing) before making any change, to avoid duplicating work.Already satisfied:
copilot-runtime[.exe]wrapper staged besideruntime.node, retaining the rootcopilotSEA only for residual/in-process compatibility. I verified the currentgithub-copilot-<version>-<platform>.tgzrelease asset (e.g.github-copilot-1.0.82-linux-x64.tgzfromgithub/copilot-cliv1.0.82) containsprebuilds/<platform>/copilot-runtimeandprebuilds/<platform>/runtime.nodebut not the root SEA — so this asset is already the coherent minimal pair the required outcome describes.github/copilot-cli(github-copilot-<version>-<platform>.tgzper platform +SHA256SUMS.txt), confirmed on the v1.0.82 release. No outstandingcopilot-clichange is needed for this outcome.@github/copilotnpm: Node.js/Rust/Java(partial) via Use Copilot CLI releases for Node runtime #2463 (merged); Python/.NET/Go and the remaining Java (codegen + smoke tests) via Use GitHub Releases for SDK runtime artifacts #2505 (open, not yet merged — see below).In flight, not duplicated: #2505 completes Python/.NET/Go Release-based acquisition and removes Java's last npm dependency. I did not touch any of the files it modifies (
python/copilot/_cli_download.py,_cli_version.py,_ffi_runtime_host.py,.github/workflows/*,java/**,dotnet/src/build/*,go/cmd/bundler/*,go/internal/embeddedcli/*). It should simply be merged; I have no evidence it needs changes.What I delivered
#2528 (draft, closes this issue): removes the Python SDK's remaining implicit
PATH-search fallback (shutil.whichin_start_cli_server, added by05dd60e/#793). This is independent of #2505's scope (acquisition/download), is not touched by that PR, and directly satisfies the outcome "Python does not implicitly select an executable throughPATH." Includes a regression test and passes ruff/ty/pytest with no new failures versusmain.Remaining outcome needing a maintainer decision
Rust
bundled-in-processCargo feature and Gocopilot_inprocessbuild tag (the compile-time choices for embedding the in-process native library) are still present onmainand are not touched by #2505. The original justification (#1934) was avoiding duplication with the embedded SEA payload. My inspection above shows that justification may already be moot: the Release-backedcopilot-runtime+runtime.nodepair is already the single minimal payload used for both out-of-process and in-process modes post-#2395/#2463/#2505, so there's no longer an extra "SEA vs. dylib" duplication to avoid by gating embedding at compile time.However, removing these flags is a real user-facing build/dependency change, not a pure cleanup:
copilot_inprocesstag is also the switch that opts an app into requiring CGO (fordlopen/ffihost); making in-process capability unconditional would make CGO mandatory for all Go SDK consumers, including ones who never use in-process.bundled-in-processfeature similarly gates thelibloadingdependency and the extra embedded dylib size for consumers who never enable it.go/cmd/bundler/main.go,go/internal/embeddedcli/*, andrust/build.rs/rust/build/*— the same files Use GitHub Releases for SDK runtime artifacts #2505 is actively finishing. Changing them concurrently risks needless conflicts with a PR that's already reviewed and near merge.Requesting maintainer input: should this flag removal proceed as a breaking build-configuration simplification once #2505 lands (making CGO/libloading unconditional for Go/Rust in-process support), or should the compile-time opt-in be kept intentionally as a size/dependency trade-off now that the duplication concern is resolved? I'd like explicit direction before changing default build requirements for existing consumers. Once decided, I (or whoever picks this up) can implement it as a focused follow-up PR against the then-current
mainwithout conflicting with #2505.Links
github/copilot-cliv1.0.82 release assets (raw native binaries + checksums, already published): https://github.com/github/copilot-cli/releases/tag/v1.0.82minyitang commentedon Oct 13, 2026
Explicit artifact selection acceptance criterion
Proposed compatible groundwork PR: SDK: support exact native-library paths for in-process loading.
Current .NET in-process resolution treats
COPILOT_CLI_PATHas an entrypoint-directory hint and searches siblings/prebuilds. Providing one native library can therefore select another; a missing requested library can still lead to an existing sibling. This does not establish that today's CLI-path contract promised exact native selection, so prefer an additive typed library-path override rather than silently reinterpreting every CLI path.Explicit native-file selection should load only that file and fail on missing/invalid/incompatible artifacts, with no sibling or bundled fallback. Preserve default discovery when absent and the existing one-library-per-process restriction. Agree precedence against legacy environment configuration and the runtime/version/asset-root contract before implementation.
Tests: two different sibling builds, missing requested file beside a valid sibling, relative paths/platform forms, unchanged defaults, incompatible-runtime diagnostics, same-library reuse and different-library rejection. Use separate subprocesses to test different real libraries. This fits this issue's explicit-overrides/offline-development scope; no separate discovery issue is needed.