`/login` does not switch the default model back to Kimi Code OAuth when an API-key model is active

What version of Kimi Code is running?

0.29.1

Which open platform/subscription were you using?

Kimi Code OAuth subscription and a Kimi Platform API key (.com中国站). The issue occurs when switching from the API-key platform back to Kimi Code OAuth.

Which model were you using?

kimi-k3

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After switching from Kimi Code OAuth to a Kimi Platform API key through /login, selecting Kimi Code (OAuth) in /login later appears to complete successfully, but the active model and persisted default model remain on the API-key provider.

There is no error message. Because the OAuth credentials already exist, the CLI reports that it is already logged in and refreshes the model configuration, but it does not switch back to the OAuth-backed model. New sessions continue to use the API-key model.

The only workaround I initially found was to log out of the API-key provider first and then select Kimi Code OAuth again. Using /model to select and persist kimi-code/k3 also works.

What steps can reproduce the bug?

1. Log in to Kimi Code (OAuth) through /login and use an OAuth-backed model such as kimi-code/k3.
2. Run /login again and select a Kimi Platform API key option.
3. Enter a valid API key and select an API-backed model.
4. Start a new session or restart Kimi Code. Confirm that the API-backed model is active.
5. Run /login and select Kimi Code (OAuth) again. Keep the existing OAuth credentials; do not log out first.
6. Observe that login/config refresh completes, but the active model and persisted default model remain on the API-key provider.
7. Start another new session and observe that it still uses the API-backed model.
8. Log out of the API-key provider, then select Kimi Code OAuth again. The default now switches to the OAuth-backed model.

What is the expected behavior?

When the user explicitly selects Kimi Code (OAuth) from the /login platform picker, the OAuth-backed model should become the active and persisted default model, consistently with the API-key login path, which makes the selected API model the default.

If /login is intended only to configure credentials and not switch models, both login paths should behave consistently and the UI should direct the user to /model.

Additional information

I traced the behavior to the interaction between the login and configuration paths:

• The Kimi Platform API-key login path sets the selected API model as default_model.
• When an OAuth token already exists, the OAuth login path provisions config with preserveDefaultModel: true.
• The preservation logic accepts an existing default model owned by a non-managed provider, so the API-backed default is retained.
• After login, the TUI reloads and activates config.defaultModel, which is still the API-backed model.

This also explains why logging out of the API-key provider first works: removing that provider clears the API-backed default, leaving no valid default to preserve during the subsequent OAuth login.

I plan to submit a focused PR with a regression test and link it to this issue.

Start at the /login OAuth path and its config provisioning around preserveDefaultModel, then compare it with the API-key login path that sets default_model. Add the regression test described in the issue and verify that selecting Kimi Code (OAuth) activates and persists the OAuth-backed model without logging out first.