[Question / Potential bug] Inconsistent models listing with Microsoft Agent Framework (.NET) + Copilot SDK

[forestmaxime]

Hi,

I've added an integration with Microsoft Agent Framework (.NET) inside a WinForms application and I've experienced inconsistent listing of CopilotClient models using the ListModelsAsync function.

Context

I'm using a GH user that was invited to a GH organization which got assigned a Copilot seat. I have a suspicion that the models (1 model only: gpt-4.1) returned are from my regular GH user which has no Copilot seat/license assigned to it.

OS

Windows

NuGet Packages

• Microsoft.Agents.AI (1.0.0)
• Microsoft.Agents.AI.GitHub.Copilot (1.0.0-preview.260402.1)
• GitHub.Copilot.SDK (0.2.1)

How I achieve getting wrong list of models

1. Start and complete the Auth Device Flow with GH using the GH Copilot public client ID to obtain a GH token
2. Store the valid GH token
3. Create a CopilotClient with CopilotClientOptions (GithubToken, UseLoggedInUser = false) and start it.
4. Obtain the list of models by calling await client.ListModelsAsync()
5. Only gpt-4.1 is returned, expected the same models available through VS Code.

Questions

• Am I using the correct auth flow to get the proper GH token which has access to the Copilot seat assigned from my organization?
• Is there ways to call an HTTP endpoint in order to get the list of models instead of instanciating a CopilotClient. I have seen that VS Code codebase calls https://api.github.com/copilot_internal/* endpoints which I've read would be against ToS to call.

Maybe a bug maybe not...

A colleague found an interesting route that could maybe explain the 1 model returned. When the CLI gets launched with --no-auto-update it picks up an old version in his C:/users/[username]/.copilot\pkg\win32-x64\0.0.403. When the parameter --no-auto-update isn't there it picks up this version C:\Users\[username]\.copilot\pkg\universal\1.0.14. He tested it manually by launching the CLI from the bundled copilot.exe inside our WinForm app with PowerShell and he was able to reproduce the same error which resulted in only getting 1 model (gpt-4.1) returned.

[github-actions]

Thanks for the detailed report! I've investigated the relevant code paths and can explain what's happening.

What I found

The --no-auto-update behavior is intentional

In dotnet/src/Client.cs (line 1164), the SDK always passes --no-auto-update to the CLI:

args.AddRange(["--headless", "--no-auto-update", "--log-level", options.LogLevel]);

This is by design — the SDK ships a bundled CLI binary (fetched via the NuGet package at runtimes/<rid>/native/copilot.exe) and intentionally pins it to prevent auto-updates, ensuring predictable behavior.

Root cause: outdated SDK/CLI version

Your colleague's observation points directly at the answer. The bundled CLI in GitHub.Copilot.SDK v0.2.1 is an older version that only returns gpt-4.1. Newer CLI versions (like 1.0.14) support more models. Because --no-auto-update prevents the bundled binary from upgrading itself, you will only ever get models supported by the CLI version bundled in your SDK package.

Solution: upgrade the NuGet package to the latest version of GitHub.Copilot.SDK. Each newer SDK release ships a newer bundled CLI.

If you need to use a specific CLI binary, you can also provide CliPath in CopilotClientOptions to point to any CLI executable (including a manually installed one):

var options = new CopilotClientOptions
{
    GitHubToken = yourToken,
    CliPath = @"C:\Users\<user>\.copilot\pkg\universal\1.0.14\copilot.exe"
};

Auth flow question

Using the GitHub Device Flow with the Copilot public client ID to obtain a token is a supported approach. The SDK accepts any valid GitHub token in GitHubToken — you just need to ensure the token has the appropriate Copilot scopes and that your account (or the org-assigned seat) is accessible under that token. The UseLoggedInUser = false setting correctly tells the CLI not to use stored gh CLI credentials and to rely exclusively on the token you provide.

---

Label applied: question — the behavior described is working as intended; the limited model list is a consequence of running an older SDK/CLI version, not a bug in the implementation.

Generated by Bug Handler for issue #1075 · ● 486.7K · ◷

[forestmaxime]

I've done some more investigating on my end with AI (Copilot CLI obviously!) on the copilot-sdk repo as I had a something in mind that I wanted to validate. My obj folder had accumulated a bunch of versions of Copilot (0.0.403, 0.0.409, 0.0.411, 1.0.2, 1.0.17). For some odd reason it picked up the .411 version and never updated it to latest 1.0.17 in my bin.

Here's what I found out:

• Root cause identified: extracted copilot.exe kept the archive timestamp, so MSBuild could skip copying the newer CLI into the output folder.
• The wrong obj folder was not being chosen; versioned cache lookup was correct.
• A locked copilot.exe in bin was another contributing problem during updates.
• Old cached CLI folders in obj could accumulate and make the situation harder to diagnose.

Fixes:

• touch extracted binary after download/extract
• detect locked output binary early and show candidate PIDs
• clean stale cached CLI folders during dotnet clean

I've attached a patch file from the code generated by Opus 4.6 that you can look up on how we could improve the flow for MSBuild. After a bunch of integration tests on the fly using AI and reviewing the generated code myself and asking Opus 4.6 if it was confident which it was at 99% that it would fix the issue. Let me know if any of this could make sense and explain issues I've been getting.
copilot-cli-fixes.patch