bug(cli): /model lists discontinued qwen-oauth coder-model even when OAuth is not configured

[callmepopo]

What happened?

In Qwen Code CLI 0.18.0, running /model shows the discontinued built-in Qwen OAuth model as the first selectable entry even when the user is not using OAuth and has no OAuth model provider configured:

1. [qwen-oauth] coder-model (Discontinued)
   Discontinued — switch to Coding Plan or API Key
2. [openai] ...

This is confusing for users who have already switched to API Key / OpenAI-compatible providers. It makes the UI look like an old Qwen OAuth account is still logged in or still configured locally, even though the active auth type is openai.

Local configuration was verified as follows:

• ~/.qwen/settings.json has security.auth.selectedType = "openai"
• modelProviders only contains openai providers
• no local OAuth/token/credential file was found under ~/.qwen
• no shell environment variable such as QWEN_DEFAULT_AUTH_TYPE=qwen-oauth was present

The behavior appears to come from the built-in model registry rather than user configuration:

• ModelRegistry registers qwen-oauth / QWEN_OAUTH_MODELS unconditionally
• user modelProviders.qwen-oauth is ignored/skipped
• getAllConfiguredModels() returns all auth types and explicitly orders qwen-oauth first
• ModelDialog calls config.getAllConfiguredModels() and renders the discontinued item
• selecting the item is already blocked with the discontinued warning, so it is visible but unusable

Related but not identical:

• bug(vscode): Qwen OAuth coder-model not marked as Discontinued in VS Code extension model picker #3745 covers the VS Code extension not marking the model as discontinued. This report is about the CLI /model dialog still listing an unusable discontinued OAuth model for users who are not configured for OAuth.
• fix(acp): discontinued qwen-oauth still returned in authMethods, trapping users on JetBrains IDEs #4637 covers ACP/JetBrains auth dead-end behavior. This report is about the interactive CLI model picker UX.

What did you expect to happen?

If Qwen OAuth is discontinued and the user is not currently configured for OAuth, /model should not list [qwen-oauth] coder-model as an available model option.

A better behavior would be one of:

1. Hide discontinued registry models from the CLI model picker by default, especially when no OAuth runtime snapshot is active.
2. Move discontinued OAuth entries to a separate migration/auth notice instead of showing them as model options.
3. Provide a documented setting to hide discontinued built-in auth providers from /model.

The model picker should show only usable configured models, or at least not put an unusable discontinued model as the first option.

Client information

Client Information

Qwen Code CLI: 0.18.0
Node.js: v22.18.0
npm: 10.9.3
OS: macOS 26.5.1
Architecture: arm64
Install source: npm package @qwen-code/qwen-code

Login information

Using API Key / OpenAI-compatible configuration via ~/.qwen/settings.json:

• security.auth.selectedType = "openai"
• custom modelProviders.openai entries are configured
• API keys are referenced through environment keys and are intentionally omitted here

Anything else we need to know?

This is not a request to restore Qwen OAuth. The issue is that the CLI model selector presents a discontinued, unusable built-in model as if it were still part of the user's available model list, which leads users to look for a non-existent OAuth account/logout state.

[qwen-code-ci-bot]

This appears related to the broader discontinued Qwen OAuth cleanup across UI surfaces:

• bug(vscode): Qwen OAuth coder-model not marked as Discontinued in VS Code extension model picker #3745 - VS Code extension model picker not marking Qwen OAuth as discontinued (same root cause, different surface). A fix was merged in fix(vscode): mark Qwen OAuth coder-model as Discontinued in model picker #3948 for the VS Code side only.
• fix(acp): discontinued qwen-oauth still returned in authMethods, trapping users on JetBrains IDEs #4637 - ACP/JetBrains auth dead-end from discontinued OAuth still returning qwen-oauth in authMethods (closed; different API surface but same underlying discontinued-provider registration issue).

The CLI ModelDialog / getAllConfiguredModels() path was not covered by the VS Code fix in #3948, so this likely needs a separate CLI-side change to filter or deprioritize discontinued registry models when the user is not configured for OAuth.

[qwen-code-ci-bot]

Triage

• Type: Bug — discontinued qwen-oauth model shown in /model picker despite user having no OAuth config
• Labels: type/bug, category/cli, scope/model-switching, priority/P2
• Reproduction: Clear — user on CLI 0.18.0 with selectedType = "openai", no OAuth credentials, /model still lists [qwen-oauth] coder-model (Discontinued)
• Related: bug(vscode): Qwen OAuth coder-model not marked as Discontinued in VS Code extension model picker #3745 (VS Code discontinued marker), fix(acp): discontinued qwen-oauth still returned in authMethods, trapping users on JetBrains IDEs #4637 (ACP/JetBrains auth dead-end), Qwen OAuth Free Tier Policy Adjustment #3203 (OAuth free tier policy)

中文说明

• 类型: Bug — 用户未配置 OAuth 时，/model 选择器仍将已停用的 qwen-oauth 模型列为可选
• 标签: type/bug, category/cli, scope/model-switching, priority/P2
• 复现: 清晰
• 相关: bug(vscode): Qwen OAuth coder-model not marked as Discontinued in VS Code extension model picker #3745, fix(acp): discontinued qwen-oauth still returned in authMethods, trapping users on JetBrains IDEs #4637, Qwen OAuth Free Tier Policy Adjustment #3203

---

Reproduction — Confirmed ✅

Reproduced on CLI 0.18.0 (installed build) with selectedType = "openai" and a single openai provider configured. No OAuth credentials, no QWEN_DEFAULT_AUTH_TYPE env var.

  ╭──────────────────────────────────────────────────────────────────────────────────────────────────╮
  │                                                                                                  │
  │ Select Model                                                                                     │
  │                                                                                                  │
  │ › 1. [openai] qwen3.7-max (Runtime)                                                              │
  │      Runtime model                                                                               │
  │   2. [qwen-oauth] coder-model (Discontinued)                                                     │
  │      Discontinued — switch to Coding Plan or API Key                                             │
  │   3. [openai] GPT-4o (gpt-4o)                                                                    │
  │                                                                                                  │
  ╰──────────────────────────────────────────────────────────────────────────────────────────────────╯

Entry #2 ([qwen-oauth] coder-model (Discontinued)) should not be listed. The user has no OAuth config and the entry is already blocked from selection — it's purely visual noise that confuses users.

Root Cause

Three layers compound the issue:

1. ModelRegistry constructor (packages/core/src/models/modelRegistry.ts:85): unconditionally registers QWEN_OAUTH_MODELS — this.registerAuthTypeModels(AuthType.QWEN_OAUTH, QWEN_OAUTH_MODELS). The qwen-oauth models are always in the registry regardless of user config.

2. getAllConfiguredModels() (packages/core/src/models/modelsConfig.ts:258): when called without arguments, iterates ALL AuthType values and explicitly forces qwen-oauth to the front of the order. No filtering by whether the user is actually configured for that auth type.

3. ModelDialog (packages/cli/src/ui/components/ModelDialog.tsx:208): calls config.getAllConfiguredModels() unfiltered. Its authTypeOrder array also puts QWEN_OAUTH first. The discontinued badge and selection-block are present, but the entry still renders.

Fix Direction

The presentation layer (ModelDialog) is the right place to filter. Two clean options:

• Option A: Skip non-runtime qwen-oauth entries from the dialog when the user's active auth type is not qwen-oauth and no runtime OAuth snapshot exists. This is a ~5-line change in availableModelEntries computation.
• Option B: Filter in getAllConfiguredModels() by passing the user's configured auth types. More invasive — other callers (ACP agent, subagents) may need the full list.

Option A is the minimal change. The core API stays intact, and the filter is localized to the one UI that renders the picker.

The existing test at modelsConfig.test.ts:1648 ("should return empty array when no models are registered") asserts qwen-oauth models are always present in getAllConfiguredModels() — this is fine for the API, but confirms the UI needs its own filter.

中文说明

复现 — 已确认 ✅

CLI 0.18.0（安装版），selectedType = "openai"，配置了一个 openai provider，无 OAuth 凭据。/model 选择器中出现了 [qwen-oauth] coder-model (Discontinued)。

根因

三层叠加导致问题：

1. ModelRegistry 构造时无条件注册 QWEN_OAUTH_MODELS
2. getAllConfiguredModels() 默认返回所有 AuthType 的模型，并将 qwen-oauth 排在最前
3. ModelDialog 直接调用 getAllConfiguredModels() 未做任何过滤

修复方向

方案 A（推荐）：在 ModelDialog 的 availableModelEntries 计算中，当用户的 active auth type 不是 qwen-oauth 且没有 runtime OAuth snapshot 时，跳过非 runtime 的 qwen-oauth 条目。约 5 行改动，最小侵入。

方案 B：在 getAllConfiguredModels() 中按用户配置的 auth types 过滤。更彻底但影响面大，其他调用方（ACP agent、subagent）可能需要完整列表。

— Qwen Code · qwen3.7-max

[he-yufeng]

I traced this to the unconditional built-in qwen-oauth registry entry being returned by getAllConfiguredModels(). I plan to keep the discontinued entry visible only when qwen-oauth is the selected auth type, while preserving existing configured-provider ordering and adding focused model-dialog/config tests.