Option to index new filetypes #962

What problem does this solve?

Feature Request: Configurable filetype/path indexing for codebase-memory-mcp

Current behavior: index_repository (and therefore search_graph/search_code) only covers a fixed default source tree — in our case app/, lib/, components/, hooks/, and supabase/. Root-level one-off scripts (scripts/*.cjs, *.mjs) and research/documentation directories (research/) are silently excluded from indexing entirely.

Impact: This isn't just a coverage gap — it's a silent one. A search_graph/search_code query for a symbol that genuinely exists in an unindexed script (confirmed case: scoreImageOnce() in scripts/model-bench-template.cjs) returns zero hits with no distinction from "this symbol doesn't exist anywhere in the repo." The tool has no way to say "not indexed" vs. "not found," so a user has to already know a file lives outside the graph's coverage before they know to fall back to grep — defeating the "use the graph first" workflow entirely for anything in these directories.

This has become a real, elevated concern for us because our Playwright e2e test suite (a root-level .cjs script) has grown into what we consider critical infrastructure — the executable specification of an entire multi-agent content pipeline, not isposable test scaffolding. Bugs in it currently go uncaught by any indexed-code tooling, including this one.

Proposed solution

Requested feature: Expose configuration on index_repository (or a project-level config file) to specify additional include paths/glob patterns beyond the default source-tree assumption — e.g., --include
"scripts//*.cjs,scripts//.mjs,research/**/.md" — so one-off scripts, benchmark harnesses, and research write-ups can opt into full graph coverage (search_graph, search_code, get_code_snippet, trace_path) on demand, without requiring them to live under the conventional app//lib install layout.

Secondary ask: At minimum, have search_graph/search_code surface an explicit "N files matched but are outside indexed paths" signal when a query's zero-result set coincides with known-unindexed directories, so the silent-miss failure mode is at least visible rather than indistinguishable from a true negative.

Alternatives considered

No response

Confirmations

• I searched existing issues and this is not a duplicate.