You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
The IDE's installation directory is unnecessarily indexed. #403
Indexing the IDE's own installation directory is unnecessary and takes up hundreds of MB of space.
We only need to index the projects that are open within the IDE.
The patch handles the case where auto-index passes the Antigravity install directory itself as the discovery root. It normalizes the full root path and returns an empty discovery result for roots, with a regression test covering a synthetic install tree.
Correction on the path pattern from my previous comment: the PR skips roots matching AppData/Local/Programs/Antigravity* after normalizing path separators and case.
Quick update, @EnziinSystem — thanks again for the clear report.
I closed the focused patch in #468: it special-cased the literal Antigravity path and returned an empty result silently, which we can't put in the discovery core (it reports "success" with zero files and no warning, and doesn't generalize to the next IDE).
The right home for this is the configurable skip/exclude layer we're building:
Your case maps to the deferred config-key half of #500: a user-settable exclude in the global config (~/.config/codebase-memory-mcp/config.json — the same file that already holds extra_extensions), so you could tell cbm once, globally, to never index **/AppData/Local/Programs/**, and have auto-index honor that when it picks roots — not just when walking subdirectories. That root-selection part is the real fix here: auto-index is currently choosing the IDE's own install directory as a project root, and it shouldn't pick up install/Program-Files-type locations on its own.
Linking this to #500 and keeping it open so the root-selection angle isn't lost. 🙏
This issue now has a first-class, durable reproduction in the cumulative bug-reproduction suite landing in #667 — a test that pins the exact failing behaviour, so it's tracked and guarded against silent regression. Where #667 also lands the root-cause fix, that's called out in the PR; otherwise the reproduction makes the eventual fix straightforward and verifiable.
The reproduction goes live once #667 merges. (Posted from the release branch's QA pass.)
Fixed on main in 202ea657 (PR #1848, "fix: block sensitive program roots before background work").
Thank you for reporting it. Indexing an IDE's own installation directory is wasted work at best, and on some layouts it means walking into program directories that should never have been touched — so the fix blocks sensitive roots before any background work starts rather than filtering results afterwards. Noticing that the indexer had wandered somewhere it had no business being is exactly the kind of thing that goes unreported because it looks like slowness rather than a bug.
Fixed on main in 202ea657 (PR #1848, "fix: block sensitive program roots before background work").
Thank you for reporting it. Indexing an IDE's own installation directory is wasted work at best, and on some layouts it means walking into program directories that should never have been touched — so the fix blocks sensitive roots before any background work starts rather than filtering results afterwards. Noticing that the indexer had wandered somewhere it had no business being is exactly the kind of thing that goes unreported because it looks like slowness rather than a bug.
What do we do if the IDE path exposes the source code of native code which for obvious reasons need to be indexed as they are part of the application source?
Activity
DeusData commentedon Jun 12, 2026
Thanks for the report — the IDE's install directory should not be swept into the index. Will investigate the default exclusion rules.
rudi193-cmd commentedon Jun 14, 2026
Opened a focused fix for this: #468
The patch handles the case where auto-index passes the Antigravity install directory itself as the discovery root. It normalizes the full root path and returns an empty discovery result for roots, with a regression test covering a synthetic install tree.
rudi193-cmd commentedon Jun 14, 2026
Correction on the path pattern from my previous comment: the PR skips roots matching
AppData/Local/Programs/Antigravity*after normalizing path separators and case.fix: skip Antigravity IDE install roots during discovery
DeusData commentedon Jun 22, 2026
Quick update, @EnziinSystem — thanks again for the clear report.
I closed the focused patch in #468: it special-cased the literal
Antigravitypath and returned an empty result silently, which we can't put in the discovery core (it reports "success" with zero files and no warning, and doesn't generalize to the next IDE).The right home for this is the configurable skip/exclude layer we're building:
.cbmignorenegation).ignore-style override layer.cbmignore!negationun-skips a built-in dir) — in reviewYour case maps to the deferred config-key half of #500: a user-settable exclude in the global config (
~/.config/codebase-memory-mcp/config.json— the same file that already holdsextra_extensions), so you could tell cbm once, globally, to never index**/AppData/Local/Programs/**, and have auto-index honor that when it picks roots — not just when walking subdirectories. That root-selection part is the real fix here: auto-index is currently choosing the IDE's own install directory as a project root, and it shouldn't pick up install/Program-Files-type locations on its own.Linking this to #500 and keeping it open so the root-selection angle isn't lost. 🙏
test(repro): more install/UX + persistence reproductions for #607, #403…
DeusData commentedon Jun 28, 2026
This issue now has a first-class, durable reproduction in the cumulative bug-reproduction suite landing in #667 — a test that pins the exact failing behaviour, so it's tracked and guarded against silent regression. Where #667 also lands the root-cause fix, that's called out in the PR; otherwise the reproduction makes the eventual fix straightforward and verifiable.
The reproduction goes live once #667 merges. (Posted from the release branch's QA pass.)
fix: 17 reproduce-first issue + new-bug fixes (per-case verified)
DeusData commentedon Aug 29, 2026
Fixed on main in
202ea657(PR #1848, "fix: block sensitive program roots before background work").Thank you for reporting it. Indexing an IDE's own installation directory is wasted work at best, and on some layouts it means walking into program directories that should never have been touched — so the fix blocks sensitive roots before any background work starts rather than filtering results afterwards. Noticing that the indexer had wandered somewhere it had no business being is exactly the kind of thing that goes unreported because it looks like slowness rather than a bug.
DieFinsternis commentedon Sep 22, 2026
What do we do if the IDE path exposes the source code of native code which for obvious reasons need to be indexed as they are part of the application source?