Repository navigation
New files not detected without explicit re-index (watcher doesn't trigger for file creation) #520
Description
New files not detected without explicit re-index (watcher doesn't trigger for file creation)
Problem
When a new file is created in an indexed repository, search_graph and detect_changes both return 0 results for the new file. The graph requires an explicit index_repository call to discover new files.
The CONTRIBUTING.md mentions src/watcher/ (git-based background auto-sync), but in practice new files are invisible to the graph until manual re-indexing.
Reproduction
# 1. Index a repository
index_repository(repo_path="/path/to/repo", mode="full") # succeeds
# 2. Create a new file
echo 'def new_func(): pass' > /path/to/repo/new_file.py
# 3. Search for it
search_graph(query="new_func") → 0 results
detect_changes(project="...") → {"changed_files": [], "changed_count": 0}
Expected Behaviour
Either:
detect_changesshould report the new file as a change (even without re-indexing the full graph)- Or background auto-sync should pick up new files within a reasonable interval
Questions
- Is the
src/watcher/component expected to handle this case? - Is there a configuration to enable background watching?
- Is
detect_changesintended only for git-committed changes (not unstaged new files)?
Context
For interactive development workflows, developers frequently create new files and immediately ask questions about them. The current behaviour forces a full re-index, which breaks the conversational flow. Baseline tools (grep, fs_read) find new files instantly.
Environment
- codebase-memory-mcp (latest)
- Tested via MCP tools in kiro-cli chat session
detect_changeswith default base_branch="main"
Activity
DeusData commentedon Jun 21, 2026
Great observation, will check ASAP
test(repro): data-loss + watcher reproductions for #557, #520
fix(issues): #521 YAML config-URL Route dedup, #523 sequential extern…
fix(test): resolve 18 make-test regressions from the marathon batch
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)
style: clang-format issue-batch additions (cypher/mcp)
DeusData commentedon Sep 26, 2026
Thank you, @Russdataart, for the clean reproduction!
detect_changesnow includes untracked files: it readsgit status --porcelain --untracked-files=allalongside the diff, so a brand-newnew_file.pyappears inchanged_fileswithout a manual re-index. The background watcher's dirty signature also covers untracked files, so auto-sync picks them up. This shipped in v0.9.0 and is in v0.11.0.Closing as fixed. Please reopen with the version and the
detect_changesoutput if a new file still stays invisible on v0.11.0.