PackAsTool: Copilot CLI binary not included in NuGet tool package (cross-platform) #2067

Activity

1. github-actions commented on Jul 23, 2026

   

   github-actionsbot

   on Jul 23, 2026 – with GitHub Actions

   Contributor

   More actions

   Investigation

   I investigated this issue by examining the .NET SDK build targets at dotnet/src/build/GitHub.Copilot.SDK.targets.

   What the code does

   The _RegisterCopilotCliForCopy target (line 146–163) registers the Copilot CLI binary as a ContentWithTargetPath item with CopyToOutputDirectory="PreserveNewest". This works correctly for regular dotnet build and dotnet publish scenarios — the binary is copied to bin/runtimes/{rid}/native/ at build time.

   The bug

   However, ContentWithTargetPath items are not included in the .nupkg tool layout when PackAsTool=true. The NuGet pack process for dotnet tools only packages the build output, not ContentWithTargetPath items that are dynamically injected via a .targets file in the consuming project. The CLI binary ends up in the build output directory but is never written into the .nupkg, so when the tool is installed on another machine (especially a different OS/RID) the binary is simply absent.

   A secondary issue noted by the reporter is also real: the build targets download only the CLI binary for the current build host RID — even if RuntimeIdentifiers lists multiple RIDs. Cross-platform tool packaging (e.g., building on Linux for a tool that should run on Windows) is therefore not supported by the current design.

   Root cause

   The SDK was designed to download and copy the CLI binary at build time into the output directory. This approach works for applications but breaks for dotnet tool packages (PackAsTool=true) and cross-platform publishing scenarios, because:

   1. ContentWithTargetPath/CopyToOutputDirectory items are not included in the NuGet tool package layout.
   2. Only the host-platform binary is downloaded, so multi-RID cross-compilation is not supported.

   Classification

   This is a bug. The SDK does not document any limitation around PackAsTool, and the current implementation silently produces a broken tool package. The fix would require either shipping the CLI binaries as proper runtimes/{rid}/native/ NuGet package assets (as the reporter suggests, similar to libgit2sharp/SkiaSharp), or adding explicit support for the PackAsTool path in the build targets.

   Warning

   Firewall blocked 1 domain

   The following domain was blocked by the firewall during workflow execution:

   • awmgmcpg

   To allow these domains, add them to the network.allowed list in your workflow frontmatter:

   network:
     allowed:
       - defaults
       - "awmgmcpg"

   See Network Configuration for more information.

   Generated by Bug Handler for #2067 · 19.8 AIC · ⌖ 5 AIC · ⊞ 4.5K · ◷
2. github-actions

   added

   bug

   on Jul 23, 2026
3. kondv commented on Sep 8, 2026

   

   kondv

   on Sep 8, 2026

   Contributor

   More actions

   Root cause is narrower than the runtime-asset redesign suggested above: tool packages are built from the publish layout, but the SDK registered its CLI runtime assets only for build output, so packing without a rebuild dropped them. #2557 registers the same assets for publish as well. Verified end to end with a locally built SDK consumed by an external PackAsTool project outside the repo — unpatched main produced a package with zero runtimes/*/native entries and the installed tool crashed with Copilot runtime wrapper not found, while the patched build packaged 67 native entries and the installed tool started the real CLI and completed an RPC call. pack -r <rid> and multi-RID packing already worked before the change, so the gap is specific to packing without rebuilding.

   — kondv's Copilot 🤖
4. SteveSandersonMS

   closed this as completedin #2557on Sep 10, 2026