[ENHANCEMENT] Want Codebase Indexing to be per project/workspace, not limited to global

[ScotterMonk]

Problem (one or two sentences)

I want more separation between my projects and to be able to use different indexing embeddings models and settings per project because my projects are very different in scope, size, etc.

Currently, I can't do that because codebase indexing settings are global, so:

• I have to use same settings for every project. What if I need a large embeddings model for one project and a small one for a different project?
• What if I want to use different providers?
• If I'm non-local: This increases the necessity for more resources at Qdrant, so instead of getting many small accounts, I have to get one big account. So in addition to reducing the efficacy of codebase indexing, this vastly increases the price I have to pay.

Context (who is affected and when)

See my answer in "Problem" area above.

Desired behavior (conceptual, not technical)

No need to ask me for confirmation. This is a very important feature to me.

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've analyzed this issue and here's my proposed implementation plan:

Current Architecture

• Codebase indexing settings (embedder provider, model, Qdrant URL, API keys, search thresholds, etc.) are stored in a single global object via contextProxy.getGlobalState("codebaseIndexConfig").
• There is already a per-workspace enablement toggle (isWorkspaceEnabled/setWorkspaceEnabled) stored in workspaceState, but the actual configuration (which embedder, which model, Qdrant URL, etc.) is shared globally across all workspaces.
• CodeIndexManager is already instantiated per-workspace folder (singleton map keyed by workspace path), but each instance reads the same global config via CodeIndexConfigManager.
• Secrets (API keys for OpenAI, Gemini, Ollama, etc.) are stored globally via contextProxy.storeSecret().

Proposed Approach: Per-Workspace Config Override

The idea is to introduce an optional per-workspace configuration override while keeping the global config as a default/fallback. This is the least disruptive path and gives users the flexibility the issue requests.

1. Add per-workspace config storage (keyed by workspace URI)

• Store workspace-specific overrides in workspaceState (already used for the enable toggle) using a key like codeIndexWorkspaceConfig:<folderUri>.
• When CodeIndexConfigManager._loadAndSetConfiguration() runs, it checks for a workspace-specific config first, falling back to the global config.
• Secrets would be stored with workspace-scoped keys (e.g., codebaseIndexOpenAiApiKey:<folderUri>) when a workspace override exists.

2. Extend the settings UI

• Add a toggle in the codebase indexing settings panel: "Use workspace-specific settings" (per workspace).
• When enabled, the settings form populates from the workspace config; changes save to workspace config instead of global.
• When disabled, the workspace falls back to the global config (current behavior).

3. Update CodeIndexConfigManager to accept workspace context

• CodeIndexConfigManager constructor already receives a ContextProxy. We'd add a workspace path/URI parameter and a reference to ExtensionContext.workspaceState.
• _loadAndSetConfiguration() would first check workspaceState for a workspace-scoped config, then fall back to getGlobalState("codebaseIndexConfig").

4. Update CodeIndexManager to pass workspace context

• CodeIndexManager.getInstance() already has workspacePath and context. It would pass these through to CodeIndexConfigManager so per-workspace config can be resolved.

5. Update webview message handler for per-workspace save

• The "updateCodebaseIndexConfig" handler in webviewMessageHandler.ts would need to determine whether to save to global state or workspace state based on the new toggle.
• API keys for workspace-specific configs would use scoped secret keys.

6. Migration / backwards compatibility

• Existing global config continues to work as-is (no migration needed).
• Per-workspace config is opt-in; no existing behavior changes unless the user explicitly enables workspace-specific settings.

Benefits

• Each project can have its own embedder provider, model, Qdrant URL/collection, and API keys.
• Users with multiple projects of different sizes can use different Qdrant accounts or instances per project, reducing costs.
• Fully backwards compatible -- global config remains the default.

Risks / Trade-offs

• Increased complexity in config management (two config sources to resolve).
• Secret management becomes more complex (workspace-scoped secret keys).
• Settings UI needs to clearly indicate whether the user is editing global or workspace settings.

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

[ScotterMonk]

@roomote I approve.

[roomote-v0]

I've seen the approval and will start implementing the per-workspace codebase indexing configuration. I'll open a draft PR to share progress shortly.

[roomote-v0]

Opened a draft PR with my attempt at implementing per-workspace codebase indexing configuration: #11948

The PR adds an opt-in "Use workspace-specific settings" toggle in the Code Index popover. When enabled, each workspace can have its own embedder provider, model, Qdrant URL, API keys, and search settings. Global config remains the default. Feedback welcome!