RooCode Security Middleware - Enterprise take on security, Proposed by DreamHost. #7912
Description
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