[BUG] Intermittent switching of API profiles

[marty-a11y]

Problem (one or two sentences)

At certain points the extension switches API profiles without my consent. It just switches. I don't know when or why, but the point is that it should NEVER switch for ANY reason, unless I click on the little selector and make a choice.

This is important for billing purposes, as we serve multiple customers, and we need to be able to confidently separate the cost for each.

Context (who is affected and when)

Anyone with multiple API configurations will suffer from this issue.

Reproduction steps

1. Have multiple API configurations
2. ???

Sorry, I really don't know when this happens. When I notice it, it's already too late every time. The extension doesn't notify about it, and the API configuration selector is too small to make it stand out.

Expected result

The API configuration NEVER changes unless the user selects one

Actual result

The API configuration may switch arbitrarily, without the user's consent or instruction

Variations tried (optional)

No response

App Version

3.53.0

API Provider (optional)

None

Model Used (optional)

N/A

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote-v0]

I've analyzed this issue and here's what I found regarding the root causes of silent API profile switching:

Analysis

There are several code paths that change the active API profile without explicit user action:

1. Mode switching triggers profile changes (most likely culprit): When the mode changes (code -> architect -> debug, etc.), handleModeSwitch() in ClineProvider.ts automatically loads and activates the mode-specific saved API config. This happens whenever the AI agent uses the switch_mode tool, when a slash command targets a different mode, or when the user manually switches modes. Each mode can have a different saved provider profile, so switching modes silently switches the API profile too.

2. Task history restoration: When reopening a task from history (createTaskWithHistoryItem), the system restores both the mode's saved API config AND the task's specific apiConfigName, potentially changing the active profile.

3. Cloud profile sync: Background cloud organization settings updates (syncCloudProfiles) can change the active profile if the cloud-managed active profile is modified or deleted.

4. Startup validation: On webview initialization, if the stored currentApiConfigName doesn't match any existing config, it silently falls back to the first available config.

5. Auth state changes: When Roo cloud auth transitions to active-session, extension.ts overwrites the current profile with "roo" provider settings.

A lockApiConfigAcrossModes workspace setting exists (defaults to false) that prevents mode switches from changing the profile, but it only covers scenario #1 and is not well-discoverable.

Proposed Implementation Plan

I propose adding a notification system so that whenever the API profile changes programmatically (not by direct user selection in the UI), a visible notification is shown. This would address the core complaint of changes happening silently.

Specifically:

1. Add a centralized onProfileChanged event in ClineProvider.ts that fires whenever activateProviderProfile is called, including the reason for the change (mode-switch, task-restore, cloud-sync, startup-fallback, auth-state).
2. Show a VS Code information notification (e.g., vscode.window.showInformationMessage) whenever the profile changes due to a non-user-initiated action, with the message like: "API profile switched to 'X' (reason: mode changed to architect)".
3. Add an opt-in setting roo-code.notifyOnProfileSwitch (default: true) to control whether these notifications appear, so users who intentionally use mode-specific profiles can silence them.
4. Improve discoverability of lockApiConfigAcrossModes: Surface this setting more prominently in the UI near the API profile selector, perhaps as a "lock" icon toggle.

This approach avoids changing existing behavior (which some users may rely on for mode-specific profiles) while solving the core problem: users not knowing when or why the profile changed.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[marty-a11y]

It could be mode switching. But bare in mind mode switching can happen by an instruction, which doesn't give the user the oppertunity to switch back to the correct profile.

Honestly, I don't see why mode switching would cause the API profile to change. It doesn't remember which mode corresponds with which profile, and it always seems to go to like maybe a previous choice, or some arbitrary choice.

But notifying the user of such a change is NOT the solution, I just want to mention. It just shouldn't change. They are two visually separate selection buttons, and one should not arbitrarily affect the other - this would be a UI antipattern, not to mention a functional annoyance.

[thany]

@roomote This bug is probably similar (or even identical) to #12237. Do you agree? Perhaps the fix will be the same as well.

[roomote-v0]

@thany Yes, I agree -- #12222 and #12237 are closely related. Both stem from the same root cause: mode switches (whether user-initiated or AI-triggered) silently change the active API configuration/model. The lockApiConfigAcrossModes setting already addresses this for user-initiated mode switches, but it is hard to discover and does not cover all the code paths that can change the profile.

I will explore a fix that makes lockApiConfigAcrossModes the default behavior (or at minimum, much more discoverable), and ensures profile changes never happen silently regardless of the trigger. Will open a PR to share progress.

[roomote-v0]

Opened PR #12246 with my attempt at addressing this. The fix changes the default of lockApiConfigAcrossModes from false to true, so that by default, mode switches (user-initiated or AI-triggered) will no longer silently change the active API config. Also guards the cloud sync path to respect the same setting. Feedback welcome!