[ENHANCEMENT] Final Sunset Update Feature Request

[twinlunarstarz-dev]

Problem (one or two sentences)

Locked "Modes" that cannot be removed.

Context (who is affected and when)

I love to use the ui for setting up and controlling multiple agents/models (which cline does not allow) using the "Modes", i have setup a bunch of different agents that all work well using their respective models.

Desired behavior (conceptual, not technical)

main problem i have is that the built in modes should be allowed to be removed or disabled completely but retaining the instructions to model to use the "modes" when switching. so essentially all i ask is on or before the final update remove the lock that requires the built in modes or atleast allow disabling them outright to prevent their usage to allow fully custom agent chains to be setup. you have done a wonderful job on the extension. (Please allow this).

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:

Problem

Built-in modes (Architect, Code, Ask, Debug, Orchestrator) are always present and cannot be removed or hidden. Users who set up fully custom agent chains want the ability to disable built-in modes they don't use.

Proposed Approach: "Disable Built-in Modes" Setting

Rather than deleting built-in modes (which are referenced as fallbacks throughout the codebase), I propose adding the ability to disable them, which hides them from the mode selector and prevents switching to them.

Changes:

1. Add disabledBuiltInModes to global state (packages/types and src/core/config/ContextProxy.ts)

   • New state key: disabledBuiltInModes: string[] (array of mode slugs)
   • This persists which built-in modes the user has disabled

2. Modify getAllModes() in src/shared/modes.ts

   • Accept an optional disabledBuiltInModes parameter
   • Filter out disabled built-in modes from the returned list (unless they have a custom override)
   • Ensure at least one mode always remains active

3. Add disable/enable toggle in the Modes UI (webview-ui/src/components/modes/ModesView.tsx)

   • For built-in modes (where the delete button is currently disabled), repurpose or add a toggle/button to disable the mode
   • Disabled modes disappear from the mode dropdown/tabs
   • Add a way to re-enable disabled modes (e.g., a "Manage Built-in Modes" section in settings)

4. Handle edge cases

   • If the currently active mode gets disabled, automatically switch to the first available mode
   • The switch_mode tool and new_task tool should respect disabled modes and fall back gracefully
   • Mode validation on task resume should handle disabled modes

5. Update mode-related message handlers (src/core/webview/webviewMessageHandler.ts)

   • Add a new message type to toggle built-in mode enabled/disabled state
   • Wire through the state update to the webview

6. Tests

   • Unit tests for getAllModes() with disabled modes
   • Tests for the disable/enable toggle behavior
   • Edge case tests (disabling active mode, preventing all modes from being disabled)

Benefits

• Non-destructive: built-in modes can be re-enabled at any time
• Safe: fallback logic still works since the mode definitions remain in code
• Clean UX: users only see the modes they want in their workflow

Alternative considered

Actual deletion of built-in modes was considered but rejected because many parts of the codebase use built-in modes as fallbacks (e.g., defaultModeSlug, modes[0]), and removing them entirely would require significant refactoring with risk of regressions.

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