Mismatched model names between cli and vs code

[akoken]

Describe the bug

There is an inconsistency in how custom agent model names are parsed/validated between the Copilot CLI and the VS Code Copilot Chat extension.

When configuring a custom agent with the model name set to "GPT-5.3-Codex (copilot)", VS Code Copilot Chat accepts it and functions perfectly. However, running the Copilot CLI throws a warning stating the model is not available.

It appears the CLI has a stricter or outdated list of acceptable model aliases like "gpt-5.3-codex" instead of the capitalized display names VS Code accepts.

The following agents have warnings:
 • /Users/my-user/.config/.copilot/agents/coder.agent.md: model "GPT-5.3-Codex (copilot)" is not available; will use current model instead

Affected version

GitHub Copilot CLI 0.0.420

Steps to reproduce the behavior

1. Create a custom agent configuration file at ~/.config/.copilot/agents/coder.agent.md.
2. Add the following to the file:

---
name: coder
model: "GPT-5.3-Codex (copilot)"
---
You are a coding assistant.

3. Open VS Code Copilot Chat and verify the agent works without errors.
4. Open a terminal and run github-copilot-cli
5. Trigger the custom agent (type /agent).

Expected behavior

Both the Copilot CLI and VS Code Copilot Chat should share the same validation logic and allowed aliases for model names. If a model string is valid in VS Code, the CLI should accept it without throwing a fallback warning.

Additional context

No response

[tstager]

It would be nice if this was fixed soon. Its really annoying.

[MetalHexx]

Yes, the lack of cohesion in the agent frontmatter expectations between both tools is problematic. This tool is important for model routing to subagents in orchestration scenarios. Because of this mismatch, we're forced to choose one harness or the other. An unknowing engineer could accidentally use the wrong harness with our orchestration system and end up spending A LOT of tokens accidentally given your new pricing model in June. Seems like a good idea to prioritize a fix before then. Your agents should simply work the same in both harnesses.