bug(desktop): top bar active model can disagree with Settings current provider model

[Sun-sunshine06]

Summary

The desktop app can show inconsistent model state between the top bar and Settings.

In the user screenshot:

• the top bar shows the active model as opus-4-7
• but the currently active Claude Code (imported) provider card in Settings shows the model dropdown as claude-3-5-haiku-20241022
• the same provider card is also marked as 当前

This makes it unclear which model will actually be used for generation.

Why This Matters

This is not just a cosmetic mismatch.

If the UI shows one model in the top bar but another model inside the active provider card, users cannot tell:

• which model is really active
• whether generation requests are using the top-bar selection or the provider default
• whether a later generate failure is caused by provider/model state drift

This may also be related to reports where:

• test connection succeeds but real generate fails
• users believe they are using opus-4.7, but the request may be resolved differently internally
• aborted / blocked / upstream validation errors become harder to diagnose

Evidence

User screenshot shows:

• top bar: claude-code-imported · opus-4-7
• Settings -> API 服务 -> current provider card: model dropdown shows claude-3-5-haiku-20241022
• the provider card is marked 当前

Expected Behavior

The app should present a single consistent active-model state.

One of these should be true:

• the top bar and Settings always show the same resolved active model, or
• the UI clearly distinguishes between current active model and provider default model

Actual Behavior

The UI appears to show two different model values for what looks like the same active provider.

Suggested Follow-up

• audit the source of truth for active provider + active model in top bar vs Settings
• verify whether Settings is showing provider default model while the top bar shows resolved active model
• ensure model changes in either place stay synchronized
• consider adding diagnostics logging for resolved provider/model at generate time when UI state differs

[Sun-sunshine06]

Related reports that may share the same root cause or at least the same state-sync confusion:

• 正常对话时报 403 错误：Error invoking remote method 'codesign:v1:generate' #124 正常对话时报 403 错误：Error invoking remote method ''codesign:v1:generate''
• bug(desktop): macOS generation fails with Instructions are required and no visible output #134 macOS generation fails with Instructions are required and no visible output

Why this may be related:

• users believe they are generating with the top-bar model, but Settings may still show a different provider/model state
• if the actual resolved provider/model differs from what the UI suggests, upstream 403 / validation / aborted failures become much harder to interpret
• even if the root cause is not identical, this mismatch is a strong amplifier for provider-side bug reports because it obscures what request config was truly used

[github-actions]

Thanks for the clear report — this is a valid UX bug and the mismatch you described is plausible from the current code path.

From the code, the top bar and Settings model selector are driven differently at render time:

• Top bar model text comes from config.modelPrimary in store (ModelSwitcher) and displays that directly.
• Settings active-card selector also starts from config.modelPrimary, but its <select> options come from models.listForProvider(provider).

If the active model id is not present in the fetched provider model list, the selector can appear to show a different listed model even though the top bar still shows the active one.

One important note: generation currently snaps to canonical active config in main process, so request routing uses cached active provider/model (not just renderer hint), which reduces runtime drift risk.

Relevant code:

• apps/desktop/src/renderer/src/components/ModelSwitcher.tsx:29 — top bar uses config.provider/config.modelPrimary
• apps/desktop/src/renderer/src/components/ModelSwitcher.tsx:123 — top bar model label renders current model
• apps/desktop/src/renderer/src/components/Settings.tsx:388 — active Settings model state initializes from config.modelPrimary
• apps/desktop/src/renderer/src/components/Settings.tsx:401 — Settings model options loaded from models.listForProvider(provider)
• apps/desktop/src/renderer/src/components/Settings.tsx:130 — <select value={value}> renders only returned options
• apps/desktop/src/main/index.ts:544 — generate path snaps to canonical active provider/model from cached config
• apps/desktop/src/main/provider-settings.ts:220 — stale hint detection (overridden)
• apps/desktop/src/main/provider-settings.ts:221 — on override, model resolves to cfg.activeModel

Need more info:

• Which app version are you on? (v0.1.x exact patch)
• After reproducing, what are the exact values in ~/.config/open-codesign/config.toml for activeProvider and activeModel?
• In Settings for claude-code-imported, what does models.listForProvider return (first 5 ids is enough)?

This project is still pre-alpha, so some provider/model UX paths are still being hardened and may not be fully synchronized yet.

---

open-codesign Bot