RooCode Security Middleware - Enterprise take on security, Proposed by DreamHost.

[ThatChillGuy]

What specific problem does this solve?

What specific problem does this solve?

Who is affected: Enterprise users and teams who need more granular security controls beyond the current .rooignore functionality.

Current State:
RooCode already has .rooignore which BLOCKS file access completely using gitignore-style patterns. This works well for completely hiding files, but has limitations:

What's Missing:

No ASK option: .rooignore only blocks completely - you can't prompt users for approval to access sensitive files
Single-tier config: Only project-level .rooignore - no global or custom configuration paths
Limited flexibility: Binary choice (block or allow) doesn't work for files that are sometimes okay to access
No enterprise controls: Can't enforce organization-wide security policies
Specific Problems:

Developers want AI help with config files but need approval prompts for sensitive sections
Enterprise teams need global security policies that apply across all projects
Current system forces "all or nothing" - either completely block files or give unlimited access
No way to ask "AI wants to read .env file - approve?" instead of just blocking it
Expected Behavior:
Enhance existing .rooignore with:

ASK rules: Prompt user before AI accesses potentially sensitive files
YAML configuration: More flexible rule definition beyond gitignore patterns
Three-tier system: Global → Project → Custom configuration hierarchy
Enterprise controls: Organization-wide security policies

Additional context (optional)

No response

Roo Code Task Links (Optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear impact and context

Interested in implementing this?

• Yes, I'd like to help implement this feature

Implementation requirements

• I understand this needs approval before implementation begins

How should this be solved? (REQUIRED if contributing, optional otherwise)

No response

How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)

No response

Technical considerations (REQUIRED if contributing, optional otherwise)

No response

Trade-offs and risks (REQUIRED if contributing, optional otherwise)

No response

[daniel-lxs]

Thank you for this detailed proposal. The gaps you’ve outlined in the current .rooignore functionality are clear.

We don’t have plans to extend this area right now, and there are still open questions around configuration formats, user experience for prompts, and interaction between global and project-level policies that would need more design before implementation.

I'll move this issue to a discussion for now.