Granular permissions for new_task, switch_mode, and ask_followup_question (and more?)

[cannuri]

What problem does this proposed feature solve?

What problem does this proposed feature solve?*

I have already implemented this feature in PR #3171 , but it was closed for further discussion about the approach and scope.

Currently, all modes in Roo Code have unrestricted access to certain tools like creating subtasks (new_task), switching modes (switch_mode), and asking follow-up questions (ask_followup_question). This presents several untapped opportunities:

1. Structured workflow creation: With mode permissions, users could define specific workflows where modes follow a predetermined sequence (e.g., ensuring Code mode always calls Test mode for TDD practices)

2. Optimized context management: For Example: When Orchestrator creates subtask in Architect mode, Architect often tries to switch to Code mode working on the plan. It should complete the task and report back to Orchestrator instead which then creates a new subtask for Code mode.
   Things like that could be prevented.

3. Fully autonomous operations: Users could create modes that run without interruptions by disabling follow-up questions, enabling true autopilot experiences

4. Consistent permission patterns: Just as fileRegex controls file access, mode permissions would provide the same granular control on which mode can call what on which mode.

Describe the proposed solution in detail

My implemented solution (in PR #3171) introduces a granular permission system for mode-specific tools. However, there are open questions about the scope and approach that need discussion:

1. New Permission Groups

I added three new permission groups that can be configured per mode:

• subtask: Controls whether a mode can create subtasks using new_task
• switch: Controls whether a mode can switch to other modes using switch_mode
• followup: Controls whether a mode can ask follow-up questions using ask_followup_question

Discussion point: Should we extend this to ALL available tools rather than just these three? This would provide maximum flexibility for users.

2. Mode Targeting Restrictions

For subtask and switch permissions, I implemented an optional slugRegex property that restricts which modes can be targeted:

["subtask", { "slugRegex": "^(code|test)$" }]

e.g this allows the mode to only create subtasks in Code or Test mode.

Discussion points:

• Should we keep the regex approach or simplify to just define allowed mode slugs (e.g., ["code", "test"])?
• Should we remove this feature entirely for the initial implementation?

UI Changes

The UI now shows three new checkboxes in the Prompts settings view:

Before:

After:

Backwards Compatibility

This is where we need to decide between approaches:

• Whitelist approach (current implementation): New tools are removed from ALWAYS_AVAILABLE_TOOLS, requiring migration to add them to existing custom modes

• Blacklist approach: Tools are available by default, but can be explicitly disabled

The concern is that with the whitelist approach, existing custom modes would lose access to these tools unless we implement a migration strategy.

Technical considerations or implementation details (optional)

The implementation in PR #3171 already includes:

1. Schema updates: Extended the mode schema to include the new permission groups in schemas/index.ts
2. Permission checking: Updated isToolAllowedForMode in modes.ts to:
   • Handle the new permission groups
   • Parse tool parameters (mode or mode_slug) and validate against slugRegex
3. Tool configuration: Updated toolGroups in tools.ts and removed these tools from ALWAYS_AVAILABLE_TOOLS
4. UI implementation: Updated PromptsView.tsx to:
   • Display new permission checkboxes
   • Interpret slugRegex and display allowed mode names
   • Handle both collapsed and expanded view formatting
5. Localization: Added translation keys for new permissions in all prompts.json files
6. Testing: Added comprehensive test coverage for permission logic, UI changes, and schema validation

Describe alternatives considered (if any)

1. Blacklist approach: Keep tools available by default, let users explicitly disable them. This would avoid breaking existing custom modes but changes the security model from opt-in to opt-out.

2. Extend to all tools: Allow granular control over all tools (not just the three I implemented). This provides maximum flexibility but needs careful UI design to avoid clutter.

3. Simple mode list instead of regex: Replace slugRegex with a simple array of allowed mode slugs (e.g., ["code", "test"]). Easier to understand but less flexible.

4. Remove mode targeting entirely: Start with just the boolean permissions (can/cannot use tool) without the ability to restrict target modes. Simpler initial implementation.

Additional Context & Mockups

Original PR with full implementation: #3171

Proposal Checklist

• I have searched existing Issues and Discussions to ensure this proposal is not a duplicate.
• This proposal is for a specific, actionable change intended for implementation (not a general idea).
• I understand that this proposal requires review and approval before any development work begins.

Are you interested in implementing this feature if approved?

• Yes, I would like to contribute to implementing this feature.

[hannesrudolph]

While the permission system you've described is comprehensive and interesting, the stated problem, unrestricted tool access across modes, is currently too broad and theoretical to justify implementing such a significant architectural change. Major changes like this require clear evidence of widespread, tangible issues impacting many users or significantly harming the workflow experience.

We prefer starting from concrete, well-defined problems with clear impacts rather than potential opportunities or theoretical improvements. If you can provide specific examples or detailed scenarios where the lack of mode permissions directly and negatively impacts users, please update the proposal accordingly. For now, we'll close this proposal as it stands.

[cannuri]

While the permission system you've described is comprehensive and interesting, the stated problem, unrestricted tool access across modes, is currently too broad and theoretical to justify implementing such a significant architectural change. Major changes like this require clear evidence of widespread, tangible issues impacting many users or significantly harming the workflow experience.

We prefer starting from concrete, well-defined problems with clear impacts rather than potential opportunities or theoretical improvements. If you can provide specific examples or detailed scenarios where the lack of mode permissions directly and negatively impacts users, please update the proposal accordingly. For now, we'll close this proposal as it stands.

Then please refer to my example regarding Architect mode: When Orchestrator creates subtask in Architect mode, Architect often tries to switch to Code mode working on the plan. It should complete the task and report back to Orchestrator instead which then creates a new subtask for Code mode.

If I had the opportunity to restrict Architect mode to switch modes or create subtasks, this wouldn't happen anymore.

[cannuri]

@hannesrudolph And just logically seen I don't see why the permissions for reading/editing files, running commands, using MCP servers is allowed, but the others like "creating a subtask" and "switching modes" aren't. I would even go a step further and allow fine grained control of any available tool for a mode.

[cannuri]

While the permission system you've described is comprehensive and interesting, the stated problem, unrestricted tool access across modes, is currently too broad and theoretical to justify implementing such a significant architectural change. Major changes like this require clear evidence of widespread, tangible issues impacting many users or significantly harming the workflow experience.

We prefer starting from concrete, well-defined problems with clear impacts rather than potential opportunities or theoretical improvements. If you can provide specific examples or detailed scenarios where the lack of mode permissions directly and negatively impacts users, please update the proposal accordingly. For now, we'll close this proposal as it stands.

Plus I would like to challenge the assumption, that major changes like this require clear evidence of widespread, tangible issues impacting many users: Is there a reason for restricting it?

Following the Principle of Least Astonishment (POLA): "Software should behave in a way that least surprises the user."
Means: If users expect to be able to do something (like adjust permissions, settings, export data), and there’s no harm in allowing it, not enabling that feature may cause frustration.

This is one of the principles besides Postel's Law that advocate towards giving a user the freedom of configuration unless there is a risk of harm, misuse or confusion.