1.6.1/1.6.2 scan only 1 file at the root of a large Java monorepo (1.6.0 indexes 12,831) #3160

Summary

On a large Java multi-module monorepo, codegraph index at the repo root scans only 1 file and indexes ~180 files on 1.6.1 and 1.6.2, while 1.6.0 on the exact same tree indexes 12,831–12,958 files. No .java files are included in the 1.6.1/1.6.2 index.

Environment

• macOS (Apple Silicon), Node 24.3.0
• codegraph 1.6.0 / 1.6.1 / 1.6.2 (installed via the official installer; codegraph upgrade <version> to switch)
• Repo shape (private, so no URL): Java monorepo, 73 top-level entries / ~20 modules
  • git ls-files | wc -l → 21,777
  • *.java on disk → 20,307
  • total files (excl. .git) → 65,966
  • git ls-files --others --ignored --exclude-standard | wc -l → 44,215
  • git ls-files --others --exclude-standard | wc -l → 0
  • .git/info/exclude → one entry (.claude); core.excludesFile → global ignore with only standard macOS entries (.DS_Store, *.tmp, …)
  • no nested git repos, no submodules, no symlinked directories at the root

Repro

codegraph index -v <repo-root>

Observed scanning phase (same tree, same command, only the binary differs):

codegraph status right after the 1.6.1 run showed Files: 179 (down from 12,790), and the previous ~840 MB index had already been replaced, so the regression also destroys an existing index.

Narrowing

• Indexing a subdirectory that is a single module of the same repo works on 1.6.1/1.6.2 (codegraph init <repo>/<module> → 85–108 files, Java included).
• A trivial standalone directory with one .java file works on 1.6.1 (Indexed 1 files).
• So the failure is specific to scanning the repo root of this monorepo, not to Java parsing or to sub-project scans.
• Everything the scanner does find at the root is outside src/ trees; the module source trees (<module>/src/main/java/**) never appear.

Guess at the cause

The 1.6.1 release notes mention the watcher scope now matching git ls-files --exclude-standard and buildScopeIgnore reading .git/info/exclude / core.excludesFile. In this repo git ls-files --exclude-standard returns 21,777 paths (not empty), so if the scanner now derives its file list from that and then filters again, something in the interaction with the 44k ignored-untracked files or the module layout appears to prune everything except a handful of config files.

Ask

1. Is this a known issue for 1.6.1/1.6.2?
2. Is there a supported way to force a filesystem walk / bypass the git-derived scope (config or env var), so 1.6.2 can be used on repos like this?
3. I can run any diagnostic build or provide a sanitized file listing if that helps localize it.

Happy to test a patch — 1.6.0 is the last version that indexes this repo correctly, so I'm staying on 1.6.0 for now.