[ENHANCEMENT] It would be great if the configuration profile were linked to the project

[AseWhy]

Problem (one or two sentences)

It would be great if the configuration profile were linked to the project

Context (who is affected and when)

I have a corporate AI that I can use for corporate projects. But when switching between modes, it defaults to the last profile used. This isn’t very convenient (I have to stop it, switch profiles, and restart it).

Desired behavior (conceptual, not technical)

It would be great if there were a project-based configuration like this. For new projects, global profile settings could be used (for example, this profile by default for one mode, and a different one for another).

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)

No response

Proposed approach (optional)

No response

Trade-offs / risks (optional)

No response

[roomote-v0]

I have analyzed this issue and here is my proposed implementation plan:

Problem

Currently, provider profiles (API configurations) and mode-to-profile mappings are stored globally in VS Code's SecretStorage via ProviderSettingsManager. This means switching between projects (workspaces) does not change which profile is active -- the last-used profile persists regardless of which project is open. Users who work on corporate projects with a corporate AI provider and personal projects with a different provider must manually switch profiles each time they change context.

Current Architecture

• ProviderSettingsManager stores all profiles and a modeApiConfigs map (mode -> profile ID) in a single global SecretStorage key.
• ClineProvider manages the active profile via currentApiConfigName in global state.
• When switching modes, the system loads the saved profile for that mode from the global modeApiConfigs map.
• A "sticky profile" feature saves a task's active profile to task history metadata.

Proposed Approach: Workspace-Level Mode-to-Profile Overrides

Rather than duplicating the entire profile system per workspace, I propose adding a workspace-scoped override layer for mode-to-profile mappings:

1. Add a workspace-scoped modeApiConfigs override -- Store a per-workspace modeApiConfigs map in workspaceState (already available via context.workspaceState). This maps mode slugs to profile IDs, just like the global modeApiConfigs.

2. Profile resolution order -- When switching modes, resolve the profile in this order:

   • Workspace-level modeApiConfigs (if a mapping exists for the current mode)
   • Global-level modeApiConfigs (existing behavior, used as fallback)

3. Add a "default profile" per workspace -- Optionally store a workspace-level defaultApiConfigName in workspaceState that overrides the global currentApiConfigName when opening a new task in that workspace.

4. UI additions -- Add a workspace-scoped settings section (or a toggle in the existing profile/mode selector) that allows users to:

   • Set which profile each mode should use in this workspace
   • Set a default profile for the workspace
   • Option to "use global defaults" (no workspace override)

5. Files to modify:

   • src/core/config/ProviderSettingsManager.ts -- Add methods like setWorkspaceModeConfig(mode, configId) and getWorkspaceModeConfigId(mode) that read/write from workspaceState.
   • src/core/webview/ClineProvider.ts -- Update handleModeSwitch() and activateProviderProfile() to check workspace overrides before falling back to global mappings.
   • src/core/webview/webviewMessageHandler.ts -- Add message handlers for workspace-level profile configuration.
   • WebView UI -- Add settings UI for per-workspace profile-mode mappings.

Benefits

• Non-breaking: Falls back to global behavior when no workspace override exists (new projects use global defaults, as requested).
• Lightweight: Reuses existing profile infrastructure; only the mode-to-profile mapping is workspace-scoped.
• No profile duplication: Profiles themselves stay global (shared across workspaces), only the selection of which profile to use is workspace-specific.

Open Questions

• Should the workspace override apply to the "default active profile" as well, or only to mode-specific mappings?
• Should there be an explicit "workspace profile settings" UI panel, or should this be integrated into the existing mode selector dropdown?
• Should workspace settings be exportable/importable (e.g., via a .roo/workspace-profiles.json file in the project)?

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

[AseWhy]

@roomote

"Should the workspace override apply to the "default active profile" as well, or only to mode-specific mappings?" - Essentially, you should use the global settings if no project settings have been specified
"Should there be an explicit "workspace profile settings" UI panel, or should this be integrated into the existing mode selector dropdown?" - Let's create a dropdown menu in the provider settings with the label “Use as default for new projects.” It will list all available modes. If a mode is removed, the selection reverts to “none.”
"Should workspace settings be exportable/importable (e.g., via a .roo/workspace-profiles.json file in the project)?" - I doubt it—why would you want to export personal profile settings if they're actually tied to projects on the same machine?

[roomote-v0]

Thanks for the feedback @AseWhy! I've seen your comment and will proceed with the implementation based on your guidance:

1. Fallback to global settings when no workspace-specific config exists
2. Integrate into the existing mode settings UI rather than a separate panel - adding a way to set workspace-level profile overrides per mode
3. No export/import - workspace profile mappings stay local to the machine

I'll open a PR to share progress shortly.

[AseWhy]

@roomote

I edited the comment:
"Should there be an explicit "workspace profile settings" UI panel, or should this be integrated into the existing mode selector dropdown?" - Let's create a dropdown menu in the provider settings with the label “Use as default for new projects.” It will list all available modes. If a mode is removed, the selection reverts to “none.”

[roomote-v0]

I've seen your updated comment and will explore a potential implementation for adding a "Use as default for new projects" dropdown in the provider settings that lists all available modes (reverting to "none" if a mode is removed). I'll open a PR to share progress.

[roomote-v0]

Opened a draft PR with my attempt at addressing this: #12228

The implementation adds workspace-scoped mode-to-profile overrides. A new "workspace pin" button in the profile dropdown lets you pin a profile to the current mode for the workspace. When no workspace override exists, it falls back to the global settings. Feedback welcome!

[roomote-v0]

Opened a draft PR with my attempt at addressing this: #12229

The PR adds a "Default for modes" multi-select dropdown in the provider settings. You can check/uncheck which modes should use a given profile as their default. If a custom mode is removed, it just disappears from the list. Feedback welcome!

[founderaideps]

Your “configuration profile linked to project” issue is the same project-scope problem Aideps handles.

A packet should bind repo/project, model/tool profile, allowed context, run identity, and audit trail so corporate settings don’t drift across projects.

If useful, I can sketch what that packet/config binding would look like.

[AseWhy]

@founderaideps

Thanks for the suggestion, but I'd prefer to see this functionality built directly into Roo Code out of the box, without relying on external tools like Aideps.