Repository navigation
[0.10.8/Windows] Background watcher never picks up committed new files (120s+) #2167
Description
Environment
- Version: 0.10.8 (Windows, installed 2026-08-19 per installer timestamp)
- OS: Windows 11, PowerShell 5.1, NTFS local disk
- Config: auto_index=true, auto_index_limit=50000, auto_watch=true (\watcher_enabled\ does not appear in \config list\ output on this build)
Reproduction (synthetic, public-safe)
- Create a fresh git repo with one committed .ps1\ file defining a function.
- \codebase-memory-mcp cli index_repository --repo_path \ -> status indexed, baseline symbol queryable.
- Add a second .ps1\ file with a uniquely-named function, \git add -A && git commit.
- Wait 120+ seconds (also reproduced at 100+ seconds in a prior run).
- Query the new symbol via search_graph/name_pattern -> 0 results. Node count unchanged.
Expected
The background watcher detects the committed create and re-indexes incrementally within its poll bound.
Actual
No pickup after 120s. A manual \index_repository\ re-run indexes the new file immediately, so parsing is fine — only the watch trigger misses.
Notes
- No private paths or source in this report; repro uses disposable synthetic repos.
- Happy to test a candidate build with watcher diagnostics (poll interval, last-scan timestamp per project).
Activity
DeusData commentedon Sep 25, 2026
Thank you so much @huymai96 for this report. The synthetic, public-safe repro and your offer to test a diagnostics build made it quick to pin down.
Your observation is correct, and the root cause turned out to be our documentation rather than the watcher. The background watcher only watches the project an open MCP session is working in (your client's working directory), and it stops when the last session for that project closes. A repository indexed with
codebase-memory-mcp cli index_repositoryis not kept under watch, so it stays at the state of that index until you re-run it. That is why a manual re-index picked up your new file straight away. Our README said "Auto-sync keeps it fresh after that" for every indexed repo, which was wrong, and that's on us.The fix (#2348) does two things. The docs, the tool description and the server instructions now state the real scope. And
index_statusnow has the diagnostics you asked for: awatchobject withwatched, thepoll_interval_msandlast_scan_atwhen a project is watched, or areason(for examplenot_session_projectorcli_session) plus a re-index hint when it isn't.On
config list:watcher_enabledwas added in v0.11.0, which is why your 0.10.8 build didn't list it; upgrading will show it. Thanks again for the careful report!fix(watcher): show watch state in index_status, correct auto-sync docs (
docs: correct CLI-mode claim that one-shot commands never touch the d…
fix(watcher): show watch state in index_status, correct auto-sync docs (
DeusData commentedon Oct 1, 2026
Thank you again, @huymai96! The documentation half is now on
mainin 7d4a12c (merged via #2350): the README and docs/CONFIGURATION.md now describe how one-shotclicommands use the shared daemon, and the corrected auto-sync wording. The watch-status part (#2348) is still in review, so this issue stays open until it lands.fix(watcher): show watch state in index_status, correct auto-sync docs (
Merge pull request #2348 from DeusData/fix/issue-2167
DeusData commentedon Oct 9, 2026
The watch-status part has landed on main in 72a2c0b (#2348), which closes this issue. Thank you again, @huymai96, for reporting it: you turned "auto-sync keeps it fresh" from a promise the docs could not keep into something the status output now states plainly.
index_statusnow carries awatchobject. A watched project showswatched: truewith the watch strategy, the poll interval and the time of the last completed scan. An unwatched project gets areason(for examplenot_session_projectfor a repository indexed throughcli index_repositoryor from a session rooted elsewhere) plus a re-index hint. So a stale CLI-indexed repository no longer looks like a watcher bug. What gets watched is unchanged: the project an open MCP session is rooted in. The README, docs/CONFIGURATION.md and the MCP tool description now say exactly that.It ships in the next release.
Merge main into feat/doc-links-core
test(doc-links): read index_status's doc_links block up to the next key