[secondary_model] config silently reset: provider model refresh cascade drops/deletes the section without warning

What version of Kimi Code is running?

Reported on 0.38.x; mechanism verified against main @ 9a71582.

Which open platform/subscription were you using?

Third-party model configured as the secondary (subagent) model.

What issue are you seeing?

User report: the [secondary_model] section in config.toml sometimes gets reset (silently disappears), and has to be re-added by hand.

What steps can reproduce the bug?

1. Configure a refreshable provider (OAuth-managed, open-platform, or custom-registry) and a [secondary_model] pool whose default_model references one of that provider's auto-generated aliases (providerId/model-name).
2. Let a provider-model refresh run while the upstream model list has changed such that the referenced alias disappears (or delete/replace the provider via the API; re-import a registry that dropped it).
3. The [secondary_model] section is silently rewritten or deleted from config.toml — no warning, no log at user level.

What did you expect to happen?

• A provider refresh should not silently delete user configuration. Aliases referenced by [secondary_model] should be preserved the same way user-named aliases are, or the cascade should keep the entries and emit a warning instead of dropping them.
• Behavior should be consistent across clients (see below).

Root cause analysis (main @ 9a71582)

• cascadeSubagentModelPool (agent-core-v2/src/session/subagent/configSection.ts): whenever the [models] table is rewritten, pool entries referencing aliases that no longer exist are silently dropped; if the default_model alias is gone, the whole [secondary_model] section is deleted; if the pool empties, the models key is removed. Completely silent — no warning surfaced to the user.
• Automatic writers that run the cascade: the daemon (kap-server) ModelCatalogRefreshScheduler — refresh on start (on by default) + every 6h by default (services/modelCatalog/modelCatalogRefreshScheduler.ts, tunable via [model_catalog] / KIMI_CODE_MODEL_CATALOG_REFRESH_*), plus POST /providers:refresh, DELETE/PUT provider routes, and custom-registry re-imports (routes/modelCatalog.ts, modelsDevImportService.ts, discoveryService.ts).
• A refresh only rewrites config when the upstream model list actually changed (providerModelsEqual short-circuit) — which is why the reset appears to happen only "sometimes".
• Alias survival rule: refreshes rebuild the auto-generated providerId/model-name aliases from the upstream list, while user-named aliases are preserved (preserveUserProviderAliases in kimi-code-oauth/refreshProviderModels.ts).
• Inconsistency: the TUI refresh host (apps/kimi-code/src/tui/controllers/auth-flow.ts) does not cascade — it leaves dangling references behind — while the daemon host silently deletes. The TUI /provider catalog-add flow has its own pool snapshot/restore (tui/commands/provider.ts), but skips the restore when the pool's default no longer resolves.

Workarounds for affected users

1. Point [secondary_model] at a user-named alias in [models] (any name not starting with providerId/); user-named aliases survive refreshes, so the cascade leaves the pool alone.
2. Disable the daemon auto-refresh:

   [model_catalog]
   refresh_on_start = false
   refresh_interval_ms = 0
   

   (or KIMI_CODE_MODEL_CATALOG_REFRESH_ON_START=0 / KIMI_CODE_MODEL_CATALOG_REFRESH_INTERVAL_MS=0). Manual refreshes still cascade, so combine with (1).

Re-adding the [secondary_model] section after a reset is sufficient; nothing else depends on it.

Related

• #3190 — subagent thinking-effort resolution issues reported by the same user around [secondary_model] configuration.

Start with cascadeSubagentModelPool in agent-core-v2/src/session/subagent/configSection.ts, then trace the refresh callers in services/modelCatalog/modelCatalogRefreshScheduler.ts, routes/modelCatalog.ts, modelsDevImportService.ts, and discoveryService.ts. Compare this with apps/kimi-code/src/tui/controllers/auth-flow.ts and tui/commands/provider.ts. Done means provider refreshes no longer silently remove secondary_model configuration and behavior is consistent across clients, with a user-visible warning where entries cannot be retained.