Enterprise-managed custom model is listed in /model but cannot be selected

[jorgegarciarey]

Describe the bug

An Enterprise-managed custom model configured through an OpenAI-compatible provider is shown in the interactive /model picker, but cannot be selected.

The picker displays the entry as:

<custom model display name> (preview) (custom)

Selecting the entry and pressing Enter leaves the previously active model unchanged. No error message is displayed.

The model itself is available and can be selected successfully when its full catalog model ID is supplied directly using the --model command-line option. This indicates that the model configuration, Enterprise policy, entitlement, and provider connectivity are valid.

The failure appears to be limited to the interactive /model picker.

Affected version

GitHub Copilot CLI 1.0.88

Steps to reproduce the behavior

1. Configure an Enterprise-managed custom model using an OpenAI-compatible provider.
2. Make the model available to an organization.
3. Start GitHub Copilot CLI.
4. Run /model.
5. Select the custom model entry.
6. Press Enter.

Expected behavior

The custom model should become the active model for the current session, just as it does when its catalog ID is passed with copilot --model <catalog-model-id>.

Additional context

• The model appears under Other models in the /model picker.
• The picker displays - for Context and Reasoning for this model.
• Selecting it with Enter leaves the previous model active and shows no error.
• Starting Copilot CLI with the model's full catalog ID via --model selects and uses it successfully.
• This is related to Enterprise custom models with slash in the provider model ID can't be selected from /model picker (ID is served URL-encoded as %2F) #4953, which reports a similar picker-selection failure for Enterprise custom models whose provider model IDs contain URL-encoded slashes. In this case, the behavior is reproduced without relying on a URL-encoded provider model ID, which suggests a broader issue in the picker path for Enterprise-managed custom models.

Environment:

• OS: macOS
• Architecture: arm64
• Terminal: Ghostty
• Shell: zsh

[andyfeller]

Thanks for raising this, @jorgegarciarey!

I've been able to confirm this and working on a fix as well as reviewing how this regressed. 🙇

[thiagocharao]

We're seeing the same behavior on our Enterprise configuration — an Enterprise-managed custom model (OpenAI-compatible provider) shows up in the /model picker but selecting it via Enter silently leaves the previous model active, --model <catalog-model-id> does not work.

May or may not be the same root cause, but worth mentioning: when the request does go through against the custom model via VS Code, we get a 400 back from the provider that looks like a content-negotiation / Accept-header issue:

Sorry, your request failed. Please try again.

Client Request Id: a1174e63-9bfe-453d-8429-4bd3b4070ad4
GH Request Id: F3B0:2E667B:553842:5B1151:6AB53812

Reason: Request Failed: 400 {"error":{"message":"{\n  \"code\" : \"391902\",\n  \"message\" : \"Unsupported Accept header null is specified. Result set format must be JSON.\"\n}","code":"invalid_request_body"}}

The Unsupported Accept header null ... Result set format must be JSON part suggests the request reaching the provider is missing an Accept: application/json header. Flagging in case it's related to the picker path not fully wiring up the custom-model request the way --model does.

Also on CLI 1.0.88, macOS.