[ENHANCEMENT] maintain the selection of mode and models per project

[avlis]

Problem (one or two sentences)

when using the extension in multiple vscode windows with different project folders (local or remote via remote-ssh), changing the active mode and model affects all windows.

Context (who is affected and when)

Hi All, great extension, keep up the good work!
I use this extension with local models only. some on lemonade server, some with lmstudio, some on mac with olmx. all that works fine.
But in my use case, I often have multiple vscode windows open, some local, some remote via with remote-ssh.
Depending on the project, I use different models on each mode, or even the same model but with a different context size.

With current code, every time I change the mode and/or model I want to use on a particular task, it affects all other vscode windows. not sure when it reads the central configuration, maybe not instantly, but if I reload the window it does change the mode and model to the last one selected on any window.

Desired behavior (conceptual, not technical)

each window (that will have a different folder open, local or remote) should mantain its own selection of mode and models.

I have added some functionaly that resolves this, by creating a .roo/profiles.json file on each project, and this way I can have each window using different mode and models. the list of available models is still central, so I don't have to reconfigure the models on each new project.

Constraints / preferences (optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

when using multiple vscode windows with different project folders open (local or remove via ssh), each window should persist an independent mode and model selection. the locked model for all modes should also be respected.

Proposed approach (optional)

I have implemented some code that persists the model selection on a .roo/profiles.json file, like:

{
	"activeMode": "architect",
	"architect": "home-qwen35-80BA3B-128k",
	"code": "remote-qwen35-122BA10B-256k",
	"ask": "home-qwen35-9B-32k",
	"lockedProfile": "home-qwen35-9B-32k"
}

lockedProfile is only present if the lock icon is selected.
all profile configuration is still central and shared by all projects.

Trade-offs / risks (optional)

No response

[roomote-v0]

I've analyzed this issue and here's my proposed implementation plan:

Problem

Currently, two pieces of state are stored at the extension level (shared across all VS Code windows):

1. Active mode (mode) - stored in globalState via ContextProxy.updateGlobalState("mode", ...)
2. Mode-to-API-config mapping (modeApiConfigs) - stored inside the providerProfiles object in VS Code secrets via ProviderSettingsManager

This means changing the active mode or its associated API profile in one window affects all other windows.

Note: lockApiConfigAcrossModes is already stored in workspaceState (per-workspace), so that part is fine.

Proposed Approach

Move the per-workspace state to workspaceState (which VS Code already scopes per-workspace/folder), while keeping provider profile definitions shared globally:

1. Move mode to workspaceState

• In ClineProvider.ts, change updateGlobalState("mode", ...) to context.workspaceState.update("mode", ...)
• When reading mode, prefer workspaceState and fall back to globalState for backward compatibility on first open
• Update getState() / getStateToPostToWebview() accordingly

2. Move modeApiConfigs to workspaceState

• Add setWorkspaceModeConfig(mode, configId) and getWorkspaceModeConfigId(mode) methods to ProviderSettingsManager that read/write a workspace-scoped mapping (e.g., workspaceState key "modeApiConfigs")
• Update ClineProvider.handleModeSwitch() and related code to use these workspace-scoped methods instead of the global ones
• Keep the existing global modeApiConfigs in providerProfiles as a fallback for workspaces that haven't set per-workspace preferences yet

3. Keep provider profile definitions global

• The actual API configurations (provider settings, API keys, model selections) remain in the shared secrets storage - no changes needed here
• This means users don't need to reconfigure API credentials per project

4. Migration

• On first load in a workspace with no workspace-scoped mode/config, seed from the global state (current behavior preserved)
• No breaking changes for existing users

Benefits

• Uses VS Code's built-in workspaceState scoping rather than custom file-based storage
• Each window/workspace independently tracks its active mode and mode-to-profile mapping
• Provider profiles (API keys, model configs) remain shared globally - no duplication
• Backward compatible with existing setups
• The existing lockApiConfigAcrossModes feature (already workspace-scoped) continues to work as-is

Files to Modify

• src/core/webview/ClineProvider.ts - mode read/write, handleModeSwitch
• src/core/config/ProviderSettingsManager.ts - add workspace-scoped modeApiConfigs methods
• src/core/config/ContextProxy.ts - mode state handling
• Related test files

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