Skip to content

ACP: expose the model list as a category:model config option (session/new returns only mode and allow_all) #4880

Open

Description

@sahina

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:

  1. 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.
  2. 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.
  3. 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.

Additional context

Minimal reproduction (Node 24):

import { spawn } from 'node:child_process'
const c = spawn('copilot', ['--acp', '--no-auto-update'], { stdio: ['pipe', 'pipe', 'inherit'] })
const send = (o) => c.stdin.write(JSON.stringify(o) + '\n')
let buf = ''
c.stdout.on('data', (d) => {
  buf += d
  for (const line of buf.split('\n').slice(0, -1)) {
    const m = JSON.parse(line)
    if (m.id === 1) send({ jsonrpc: '2.0', id: 2, method: 'session/new', params: { cwd: process.cwd(), mcpServers: [] } })
    if (m.id === 2) { console.log(Object.keys(m.result), m.result.configOptions.map((o) => o.id)); c.kill() }
  }
  buf = buf.slice(buf.lastIndexOf('\n') + 1)
})
send({ jsonrpc: '2.0', id: 1, method: 'initialize', params: { protocolVersion: 1, clientCapabilities: { fs: { readTextFile: false, writeTextFile: false } }, clientInfo: { name: 'probe', version: '0' } } })

Prints [ 'sessionId', 'modes', 'configOptions' ] [ 'mode', 'allow_all' ].

Version: GitHub Copilot CLI 1.0.85. ACP SDK used by the client: @agentclientprotocol/sdk 1.4.0.

Activity

  1. Xzese commented on Oct 3, 2026

    @Xzese

    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:

    session/new keys: ["configOptions", "modes", "sessionId"]
    configOptions ids: ["mode", "allow_all"]
    model config: []
    

    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.

    Prepared with GPT-6.1-Sol in the Codex agent.

  2. patniko commented on Oct 26, 2026

    @patniko
    Collaborator

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions