You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ACP: expose the model list as a category:model config option (session/new returns only mode and allow_all) #4880
Describe the feature or problem you'd like to solve
Over copilot --acp, a client has no way to list the models available to the signed-in account or to pick one for a session.
Measured on GitHub Copilot CLI 1.0.85 (macOS arm64):
session/new returns sessionId, modes and configOptions only. configOptions holds exactly two select options, mode and allow_all. There is no option with category: "model".
session/load returns the same set.
Sending /model as a prompt answers: "The model-picker dialog is only available in the interactive CLI."
--model <id> accepts any string. copilot --acp --model=not_a_real_model_xyz starts, creates a session and completes a prompt with no error, no stderr, and nothing on the wire reports which model actually ran.
So an ACP client (an editor or a desktop app embedding Copilot) can only offer a single "Copilot default" row. It cannot show the models the user's plan allows, and if it hard-codes ids it cannot tell when one silently fell back.
Proposed solution
Advertise the model list the way the ACP spec already provides for it:
Include a SessionConfigOption with type: "select" and category: "model" in session/new and session/load responses, listing the ids the account can use and currentValue set to the active model. Grouping by vendor via SessionConfigSelectGroup is fine.
Accept session/set_config_option for that option and emit config_option_update on change, so a client can switch models mid-session without respawning.
Ideally, reject an unknown --model value (or at least log it to stderr) instead of silently running the default.
This is the same shape the interactive /model picker already has; it just needs to be exposed on the ACP surface.
Example prompts or workflows
An ACP client starts copilot --acp, calls session/new, reads the model config option, shows its values in a picker, and calls session/set_config_option with the user's choice. Today step 3 yields nothing to show.
This issue is still reproducible with GitHub Copilot CLI 1.0.91 on macOS arm64.
It affects T3 Code desktop 0.0.46-nightly.20261003.2623, which supports providers through ACP. Copilot was added through T3 Code’s ACP Registry provider screen and is reported as ready and authenticated, but its model picker only shows Default.
A direct ACP probe against the exact registry-managed Copilot binary, independently of T3 Code, returned:
Both initialization variants tested returned ACP protocol version 1 and the same missing model configuration. T3 Code consumes select options with category: "model", but this response supplies none.
The merged PRs referencing this issue have not fixed the underlying Copilot behavior:
mrmans0n/alas#1380 adds launch-time --model/--effort arguments as a workaround in Alas.
F0rty-Tw0/fixture-automation#1 updates a client’s discovery parser. It explicitly notes that live Copilot testing was unavailable and discovery fails when the model catalog is absent.
Neither PR changes Copilot itself or restores the missing ACP model option. The problem remains present in 1.0.91 and prevents model discovery in T3 Code’s ACP integration.
Thanks for the report. We've shipped fixes in this area since this was filed, and we believe this may now be resolved. Could you retest on the latest release (Copilot CLI v1.0.103) and let us know whether you still see it? If we don't hear back in a couple of weeks, we may close this issue — you can always reopen it.
Triaged as part of a Copilot SDK backlog review, with help from GitHub Copilot.
Activity
Xzese commentedon Oct 3, 2026
This issue is still reproducible with GitHub Copilot CLI 1.0.91 on macOS arm64.
It affects T3 Code desktop 0.0.46-nightly.20261003.2623, which supports providers through ACP. Copilot was added through T3 Code’s ACP Registry provider screen and is reported as ready and authenticated, but its model picker only shows Default.
A direct ACP probe against the exact registry-managed Copilot binary, independently of T3 Code, returned:
Both initialization variants tested returned ACP protocol version 1 and the same missing model configuration. T3 Code consumes select options with
category: "model", but this response supplies none.The merged PRs referencing this issue have not fixed the underlying Copilot behavior:
--model/--effortarguments as a workaround in Alas.Neither PR changes Copilot itself or restores the missing ACP model option. The problem remains present in 1.0.91 and prevents model discovery in T3 Code’s ACP integration.
Prepared with GPT-6.1-Sol in the Codex agent.
patniko commentedon Oct 26, 2026
Thanks for the report. We've shipped fixes in this area since this was filed, and we believe this may now be resolved. Could you retest on the latest release (Copilot CLI v1.0.103) and let us know whether you still see it? If we don't hear back in a couple of weeks, we may close this issue — you can always reopen it.
Triaged as part of a Copilot SDK backlog review, with help from GitHub Copilot.