[ENHANCEMENT] feat: Per-workspace indexing opt-in and stop/cancel indexing controls

[JamesRobert20]

Problem (one or two sentences)

Once a user enables codebase indexing globally, opening any other project automatically starts indexing it with no per-project control (same issue reported in #10569). Additionally, there is no way to stop indexing once it starts, and disabling the toggle while indexing is in progress does not actually stop the scan — the yellow pulsing indicator persists.

Context (who is affected and when)

Any user who uses codebase indexing across multiple workspaces. This is especially severe for multi-root workspaces with local LLM providers (as described in #10569 ). The issue occurs when:

• opening a new workspace after enabling indexing globally — it auto-indexes without consent,
• wanting to cancel a long-running indexing operation mid-scan, or
• toggling off "Enable Codebase Indexing" during active indexing and seeing the indicator persist.

Desired behavior (conceptual, not technical)

1. Indexing should be opt-in per workspace — opening a new project should NOT auto-start indexing. Users should see a clear toggle to enable indexing for the current workspace, and that choice should be remembered across sessions.

2. Users should be able to stop indexing at any time via a "Stop Indexing" button. The stop should be graceful, preserving any partial index data already collected.

3. Disabling the global "Enable Codebase Indexing" toggle should immediately stop any in-progress scan, not just the file watcher.

Constraints / preferences (optional)

• The per-workspace choice should persist across IDE restarts (stored in workspaceState)
• Stopping indexing should not clear partial index data — users can clear it separately
• The stop should be graceful (complete current file, don't corrupt data)
• Aligns with the "Enhanced User Experience" roadmap goal
• Related: [BUG] Disable automatic full-workspace indexing: Multi-Root Workspaces cause local LLM DoS/Timeouts #10569

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)

Given a user has codebase indexing enabled globally
When they open a new workspace for the first time
Then indexing should NOT auto-start
And a "Enable indexing for this workspace" toggle should be visible in the CodeIndex popover

Given indexing is in progress
When the user clicks "Stop Indexing"
Then the scan should stop gracefully at the next file/batch boundary
And the status should show "Stopping..." then transition to "Standby"
But partial index data should NOT be cleared

Given indexing is in progress
When the user disables the global "Enable Codebase Indexing" toggle
Then the active scan should be aborted (not just the file watcher)
And the status indicator should stop pulsing

Proposed approach (optional)

Per-workspace opt-in via a codeIndexWorkspaceEnabled flag in workspaceState (default: false), AbortController/AbortSignal threaded through the orchestrator → scanner pipeline for cancellation, new "Stopping" state for visual feedback, and fix handleSettingsChange() to properly abort active scans.

Trade-offs / risks (optional)

Existing users with indexing enabled will need to re-enable it per workspace after this change (default is off). This is intentional — the current behavior of auto-indexing every project is the problem being solved. This supersedes the scope of #10569 .

[JamesRobert20]

Claiming

[roomote]

I've analyzed this issue and here's my proposed implementation plan, based on a thorough review of the current code indexing architecture.

Current State (Root Causes)

1. codebaseIndexEnabled is a global setting stored via ContextProxy.getGlobalState("codebaseIndexConfig"). There is no per-workspace flag -- so enabling indexing once applies to every workspace.

2. Auto-start on activation: In extension.ts, every workspace folder gets a CodeIndexManager instance that calls manager.initialize(contextProxy) at startup. If the global flag is enabled and the provider is configured, indexing starts immediately with no user prompt.

3. No cancellation mechanism: DirectoryScanner.scanDirectory() and CodeIndexOrchestrator.startIndexing() have no AbortSignal support. Once a scan begins, it runs to completion or error.

4. Disabling the toggle only stops the file watcher: handleSettingsChange() calls orchestrator.stopWatcher(), which disposes the file watcher subscriptions but does NOT abort any in-progress scanDirectory() call. The scan continues in the background and the pulsing indicator persists.

Proposed Plan

Part 1: Per-Workspace Indexing Opt-In

Storage: Add a workspace-scoped enabled flag. Since ContextProxy already wraps globalState, I'll store per-workspace preferences in a codeIndexWorkspacePreferences global state map keyed by workspace folder path (e.g., Record<string, { enabled: boolean }>). This persists across sessions without requiring a separate workspaceState API.

Files to modify:

• src/services/code-index/config-manager.ts -- Add isWorkspaceEnabled(workspacePath) and setWorkspaceEnabled(workspacePath, enabled) methods. The new check: indexing starts only if global enabled AND workspace enabled.
• src/services/code-index/manager.ts -- Update initialize() and startIndexing() to check isWorkspaceEnabled before proceeding.
• src/extension.ts -- In the workspace folder loop, skip manager.initialize() for workspaces where opt-in is false (the default).

UI changes:

• webview-ui/src/components/chat/CodeIndexPopover.tsx -- Add a per-workspace toggle (e.g., "Enable indexing for this workspace") visible when the global toggle is on. When toggled, send a new setCodeIndexWorkspaceEnabled message.
• src/core/webview/webviewMessageHandler.ts -- Handle the new message type, call configManager.setWorkspaceEnabled(), and trigger manager.initialize() or manager.stopWatcher() accordingly.

Default behavior: New workspaces default to enabled: false. Existing users who had indexing on will need to re-enable per workspace (as the issue author acknowledges is intentional).

Part 2: Stop/Cancel Indexing Controls

AbortController threading:

• src/services/code-index/orchestrator.ts -- Add a private _abortController: AbortController | null field. Create a new controller at the start of startIndexing(). Pass _abortController.signal to the scanner. Add a public abortIndexing() method that calls _abortController.abort() and sets state to "Stopping".
• src/services/code-index/processors/scanner.ts -- Accept an optional AbortSignal parameter in scanDirectory(). Check signal.aborted between file parsing iterations and between batch embedding calls. When aborted, return early with partial results (preserving already-indexed data).
• src/services/code-index/state-manager.ts -- Add "Stopping" to IndexingState type. This gives visual feedback during graceful shutdown.

Graceful stop behavior: On abort, the scanner finishes the current file (not mid-parse), skips remaining files, and returns. The orchestrator transitions from "Stopping" to "Standby". Partial index data and cache are preserved (no clearCacheFile() or clearCollection() on stop).

UI changes:

• CodeIndexPopover.tsx -- When systemStatus === "Indexing", show a "Stop Indexing" button. When systemStatus === "Stopping", show "Stopping..." (disabled). Send a stopCodeIndexing message on click.
• webviewMessageHandler.ts -- Handle stopCodeIndexing by calling manager.abortIndexing() (new method on CodeIndexManager that delegates to orchestrator.abortIndexing()).

Part 3: Fix Global Toggle to Abort Active Scans

• src/services/code-index/manager.ts -- In handleSettingsChange(), when detecting !isFeatureEnabled, call this._orchestrator.abortIndexing() (not just stopWatcher()). This uses the same AbortController mechanism from Part 2.
• The abort will cancel any in-progress scanDirectory(), transition through "Stopping" to "Standby", and stop the pulsing indicator.

Type/Interface Updates

• src/services/code-index/interfaces/manager.ts -- Add "Stopping" to the IndexingState union type.
• packages/types (if IndexingStatus is defined there) -- Add "Stopping" to the shared type.
• Update shared message types for the new webview messages (setCodeIndexWorkspaceEnabled, stopCodeIndexing).

Tests

• Unit tests for ConfigManager.isWorkspaceEnabled() / setWorkspaceEnabled().
• Unit tests for Orchestrator.abortIndexing() confirming the abort signal is respected.
• Unit tests for scanner abort behavior (partial results preserved).
• Unit tests for handleSettingsChange() confirming abort is called when disabling.
• UI tests for the new toggles/buttons in CodeIndexPopover.

Migration / Breaking Changes

Existing users with indexing enabled globally will find it disabled in individual workspaces after this change. The CodeIndexPopover will show the workspace toggle, making it easy to re-enable. This is intentional per the issue requirements.

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

[rossdonald]

Existing users with indexing enabled will need to re-enable it per workspace after this change (default is off). This is intentional — the current behavior of auto-indexing every project is the problem being solved.

This is the problem being solved for you, but for existing users who actually like this behaviour, you're breaking it for no reason. It would be good to support both behaviors.

It could have a global flag "Codebase indexing default" which can be on or off. If it is set to on, it's the current behavior and auto indexes a new workspace. If it is set to off, then it's the behavior that you're looking for and can be switched on per workspace.

[JamesRobert20]

Existing users with indexing enabled will need to re-enable it per workspace after this change (default is off). This is intentional — the current behavior of auto-indexing every project is the problem being solved.

This is the problem being solved for you, but for existing users who actually like this behaviour, you're breaking it for no reason. It would be good to support both behaviors.

It could have a global flag "Codebase indexing default" which can be on or off. If it is set to on, it's the current behavior and auto indexes a new workspace. If it is set to off, then it's the behavior that you're looking for and can be switched on per workspace.

Fair point, I added a global "Auto-enable indexing for new workspaces" toggle (defaults to ON for backward compatibility). When ON, new workspaces auto-index like before. When OFF, each workspace needs manual opt-in. Per-folder overrides still work either way. Existing users see no behavior change.