ACP session/new reports a model that the session is not running #5363

Describe the bug

Over ACP (copilot --acp), the session/new response lists a model config option with currentValue: "claude-sonnet-5.5", but the session doesn't use that model until the client sets it explicitly with session/set_config_option. Until then:

• the session runs a different model, and
• session/set_config_option for reasoning_effort fails with -32603 "Request session.model.setReasoningEffort failed with message: This model does not support reasoning_effort configuration.", although the reported model offers reasoning_effort (low, medium, high, xhigh, max) and the response already reports reasoning_effort: "medium".

Setting model to the value session/new already reports makes the reasoning_effort change succeed. The configOptions array returned by that set_config_option is identical to the one from session/new, so a client can't tell from the protocol that anything changed.

The reproduction below needs no prompt and shows the reasoning_effort rejection. The wrong model was observed separately, in real use: in one T3 Code setup, sessions that showed claude-sonnet-5.5 recorded session.model_change events to gpt-6.1-sol in ~/.copilot/session-state/<id>/events.jsonl. ACP clients reasonably skip setting a config option that already has the value they want (T3 Code does), so they hit both whenever the user picks the model Copilot reports as current.

Affected version

GitHub Copilot CLI 1.0.105 (Homebrew, macOS arm64). Reproduced with a fresh COPILOT_HOME containing only a copied config.json, which has no model setting.

Steps to reproduce

No prompt is needed. Send these ACP frames to copilot --acp --no-custom-instructions --disable-builtin-mcps, which a short Node script can do:

1. initialize {protocolVersion: 1, clientCapabilities: {}}
2. session/new {cwd, mcpServers: []}
3. session/set_config_option {sessionId, configId: "reasoning_effort", value: "low"}
4. session/set_config_option {sessionId, configId: "model", value: <model currentValue from step 2>}
5. session/set_config_option {sessionId, configId: "reasoning_effort", value: "low"}

Output (model and reasoning_effort current values from each response):

session/new ok [["model","claude-sonnet-5.5"],["reasoning_effort","medium"]]
effort=low (no model set) ERROR {"code":-32603,"message":"Request session.model.setReasoningEffort failed with message: This model does not support reasoning_effort configuration."}
model=<reported> explicitly ok [["model","claude-sonnet-5.5"],["reasoning_effort","medium"]]
effort=low (after model set) ok [["model","claude-sonnet-5.5"],["reasoning_effort","low"]]

Expected behavior

The model session/new reports as currentValue is the model the session runs. Setting reasoning_effort right after session/new succeeds for that model, just as it does after the same model is set explicitly.

Additional context

• The session/new response also reports models.currentModelId: "claude-sonnet-5.5". I assume it is just as inaccurate, but I didn't test it separately.
• I only checked session/new. I couldn't check session/load, because a session that never received a prompt isn't saved (session/load returns -32002 Session ... not found), and I didn't send prompts.
• Workaround for ACP clients: after session/new, send session/set_config_option for model even when the value already matches.

— Opus 5.5 with Claude Code, reviewed by GPT 6.1 Sol