[BUG] .rooignore rules not enforced for codebase indexing, file reads, or environment file listing

[frbrdan-code]

Problem (one or two sentences)

.rooignore entries are completely ignored — directories listed in .rooignore are still indexed by codebase search, readable via read_file, and shown without 🔒 icons in the auto-generated environment file listing.

Context (who is affected and when)

Affects any user with a .rooignore file in a workspace that contains git submodules or deeply nested third-party directories. The issue is visible immediately when the AI assistant accesses files that should be blocked. Particularly problematic for workspaces with large vendored/third-party code that users explicitly want to exclude.

Reproduction steps

1. Environment: Roo Code v3.50.4, Linux, any API provider (tested with Anthropic Claude Opus).

2. Setup: Create a workspace that contains a git submodule (a separate git repository nested inside the main repo):

   mkdir my-project && cd my-project && git init
   mkdir src && echo "int main() {}" > src/main.c
   # Add a git submodule — this creates vendor/some-lib/ with its own .git
   git submodule add https://github.com/some-org/some-lib.git vendor/some-lib

   Resulting structure:

   my-project/
   ├── .git/
   ├── .gitmodules            ← records the submodule
   ├── .rooignore
   ├── src/
   │   └── main.c
   └── vendor/
       └── some-lib/          ← git submodule (has its own .git inside)
           ├── .git           ← this makes it a separate git repo
           ├── Makefile
           ├── drivers/
           │   └── crypto.c
           ├── include/
           │   └── crypto-engine.h
           └── tests/
               └── test-basic.c
   

   The key detail is that vendor/some-lib/ is a git submodule — it has its own .git directory, making it a repo-inside-a-repo.

3. Create .rooignore at the workspace root with:

   vendor/some-lib/
   

4. Start a new Roo Code task.

5. Use codebase_search scoped to vendor/some-lib with any query (e.g., "crypto"). Observe: 50+ indexed results are returned from inside the ignored directory.

6. Use read_file on vendor/some-lib/Makefile. Observe: file content is returned successfully with no access-denied error.

7. Check environment_details auto-generated file listing. Observe: vendor/some-lib/ files appear without the 🔒 lock icon.

Expected result

.rooignore should block codebase indexing, file reads, and show 🔒 icons for all files matching the ignore patterns.

Actual result

All three enforcement mechanisms fail — files inside .rooignore-listed directories are indexed, readable, and displayed without lock icons, as if .rooignore does not exist.

Variations tried (optional)

• Tested with multiple .rooignore entries (several different vendor/ subdirectories) — none are enforced
• The directories in question are git submodules (have their own .git directory inside), but the issue may not be submodule-specific
• The .rooignore file is confirmed to exist at the workspace root with valid .gitignore-syntax patterns
• Testing with a non-submodule directory would help isolate whether git submodules specifically cause the issue vs. a general .rooignore enforcement failure

App Version

v3.50.4

API Provider (optional)

Anthropic

Model Used (optional)

Claude Opus 4.6

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

No errors in the Output panel — the failure is silent. `.rooignore` patterns are simply not applied.

**Likely root causes from source analysis:**

1. `RooIgnoreController.validateAccess()` (`src/core/ignore/RooIgnoreController.ts:89`) returns `true` (allow access) if `rooIgnoreContent` is undefined — which happens when the `.rooignore` file fails to load or the controller is initialized with the wrong `cwd`.

2. The scanner (`src/services/code-index/processors/scanner.ts:87`) creates a **new** `RooIgnoreController(directoryPath)` — if `directoryPath` differs from the workspace root where `.rooignore` lives, the controller won't find the file and silently allows everything.

3. `validateAccess()` calls `realpathSync()` on line 100 which follows symlinks. For git submodules, this may resolve to a path outside `cwd`, causing `path.relative()` to produce an unexpected result, and the catch block on line 113 defaults to **allowing access**.

4. The search service (`src/services/code-index/search-service.ts`) queries Qdrant directly with no post-query `.rooignore` filtering — once files are indexed, they appear in search results permanently.

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Root Causes Identified

After tracing through the code, I found three interconnected problems that explain why .rooignore silently fails, particularly (but not only) for git submodules:

1. validateAccess() uses realpathSync which can resolve paths outside cwd (RooIgnoreController.ts:100)

When realpathSync follows symlinks (common with submodule setups or --follow in ripgrep), the resolved path may land outside the workspace. path.relative(cwd, realPath) then produces ../../some/path, which the ignore library cannot match against .rooignore patterns. The outer catch block (line 112-115) defaults to allowing access, so any error in this flow silently bypasses all ignore rules.

2. Search results are never post-filtered by .rooignore (CodebaseSearchTool.ts)

Even when indexing correctly filters files, CodebaseSearchTool returns raw Qdrant results without checking .rooignore. Once a file enters the vector store (e.g., before .rooignore existed, or via a race), it remains searchable permanently.

3. Scanner creates its own RooIgnoreController instead of reusing the one from the manager (scanner.ts:87)

The manager already creates and initializes a RooIgnoreController (manager.ts:390), but the service factory does not pass it to the scanner (service-factory.ts:254). The scanner then creates a second, independent instance. While this should work if paths are correct, it means the scanner's controller is never initialized via await initialize() in the constructor flow -- the await on line 89 could race with scanning if there's any async issue.

Proposed Changes

Fix 1: Harden validateAccess() in RooIgnoreController.ts

• After realpathSync, check if realPath is still inside cwd. If not, fall back to using the original absolutePath for the relative path computation.
• Change the outer catch block from return true (allow) to return false (deny) -- fail closed for security.
• This directly fixes the symlink/submodule resolution problem.

Fix 2: Add .rooignore post-filtering in CodebaseSearchTool.ts

• After receiving search results from the index, filter them through task.rooIgnoreController.validateAccess() before returning results to the LLM.
• This ensures previously indexed files that are now in .rooignore are excluded from search results.

Fix 3: Pass the manager's RooIgnoreController through to the scanner

• Update DirectoryScanner to accept an optional RooIgnoreController parameter.
• Pass the manager's controller from service-factory.ts to the scanner.
• Fall back to creating a new one in scanDirectory() only if none was provided (backward compat).

Fix 4: Add tests

• Unit test for validateAccess with paths that resolve outside cwd (symlink scenario).
• Unit test for CodebaseSearchTool verifying .rooignore filtering of search results.

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

[frbrdan-code]

@roomote I approve this plan. Please proceed with the implementation.

One additional note: the bug also manifests in the environment_details auto-generated file listing - files in .rooignore-listed directories appear without lock icons. This should be fixed by Fix 1 (since formatResponse.formatFilesList uses the same RooIgnoreController), but please verify this is covered in the tests.

[roomote]

Thanks for the approval and the additional note about environment_details file listing! I've seen the comment and will proceed with the implementation now. I'll make sure the tests cover the formatFilesList / lock icon scenario as well. Will open a PR to share progress shortly.

[roomote]

Opened PR #11798 with my attempt at addressing this. It includes all three fixes from the plan plus the additional test coverage for the environment_details lock icon scenario. Feedback welcome!

[frbrdan-code]

A few comments @roomote :

1. FileWatcher has the same cwd mismatch (gap in the fix)

The scanner now receives the manager's RooIgnoreController, but FileWatcher still creates its own at src/services/code-index/processors/file-watcher.ts:85:

this.ignoreController = ignoreController || new RooIgnoreController(workspacePath)

This means files that change after initial indexing will still bypass .rooignore during incremental re-indexing if the workspacePath differs from the workspace root. The same plumbing fix (passing the manager's controller through service-factory.ts → createFileWatcher()) should be applied here for consistency.

2. validateAccess() behavior change for absolute paths outside cwd

The catch block changing from return true → return false is correct for security, but it's a behavior change for any caller that passes absolute paths outside cwd (e.g., /etc/hosts, paths from other workspaces). Other callers of validateAccess() in the codebase (ripgrep, tree-sitter, context management, mentions) should be spot-checked to make sure they don't rely on the old "allow on error" behavior.

3. Missing test for scanner controller passthrough

The scanner and service-factory changes don't have new/updated tests. A test verifying that the provided RooIgnoreController is actually used (and a new one is NOT created) would strengthen confidence in Fix 3.

4. Minor: filteredResults filter drops payload-less entries

In CodebaseSearchTool.ts line 117, if (!result.payload || !("filePath" in result.payload)) return false — entries without a payload are now treated as "blocked by rooignore" rather than being silently skipped later. The end behavior is equivalent, but a comment clarifying this is a guard clause (not an ignore decision) would improve readability.

[roomote]

I've seen the feedback comments and will work on addressing all 4 points:

1. FileWatcher cwd mismatch - pass manager's controller and fix the uninitialized fallback
2. validateAccess behavior change - spot-check callers and update security spec for outside-cwd paths
3. Missing scanner controller passthrough test
4. Clarifying comment on filteredResults guard clause

Will open a follow-up PR shortly.

[roomote]

Opened PR #11799 with my attempt at addressing all 4 feedback points. It targets the existing PR #11798 branch as base. Feedback welcome!

[frbrdan-code]

@roomote Please squash the two commits into a single commit - the first commit had failing tests (RooIgnoreController.security.spec.ts) that the second commit fixed, and we shouldn't have broken tests in the git history. After squashing, please mark the PR as ready for review.