Watcher does not auto-reindex git-visible untracked file on Linux stdio MCP session (v0.6.0)

[cryptomaltese]

Summary

Adding a new, git-visible, untracked .py file to an already-indexed project does not trigger the autoindex watcher inside a live stdio MCP session. Explicit index_repository picks it up immediately, so the pipeline works — the watcher just never fires.

Per #71 (closed) the internal/watcher/watcher.go git-strategy watcher polls git status --porcelain --untracked-files=normal on a 5000 + (fileCount/500)*1000 ms interval capped at 60s. For the test repo in question (~300 files → expected interval ≈5-6s), 120s of wall-clock is well past several poll cycles.

Environment

• Version: 0.6.0 (codebase-memory-mcp --version → codebase-memory-mcp 0.6.0)
• OS: Linux (Ubuntu 24.04, GLIBC 2.39), x86_64
• Shell: bash
• Integration: Claude Code, stdio MCP server (standard variant — not UI)
• Install: canonical codebase-memory-mcp install -y (2 hooks + 1 skill wired to ~/.claude/)
• Config: auto_index = false (default) at time of test
• Concurrent servers: 2 stdio processes alive (2 Claude Code sessions)

Repro

# 1. Indexed project: 444 nodes / 816 edges (pre-test baseline)
REPO=/path/to/claude-watch
PROBE="$REPO/_cbm_probe_v2.py"
SYMBOL=_cbm_probe_v2_fn

# 2. Create git-visible probe
echo "def ${SYMBOL}(): return 1" > "$PROBE"
git -C "$REPO" check-ignore "$PROBE"   # exit != 0 (not ignored)
git -C "$REPO" status --porcelain -- "$PROBE"
# → "?? _cbm_probe_v2.py"   # git sees it as untracked

# 3. Poll the graph every 5s for 120s via CLI
while ...; do
  codebase-memory-mcp cli search_graph \
    '{"project":"'"$PROJECT"'","name_pattern":"'"$SYMBOL"'"}' \
    | jq '.content[0].text | fromjson | .total'
  # → 0 for every sample across 120s
done

# 4. Explicit reindex immediately picks it up
codebase-memory-mcp cli index_repository '{"repo_path":"'"$REPO"'"}'
# → nodes 444 → 447, edges 816 → 818

Observed

• 24 polls across 120s, every sample returned total: 0.
• Immediately after timeout, index_repository returned nodes: 447, edges: 818 (+3/+2) — the probe was parseable and indexable; the watcher just hadn't noticed.
• After deleting the probe and reindexing, counts returned to 444/816.

What I haven't tested

• I flipped config set auto_index true after the timeout but did not restart the MCP server (would have disrupted two active Claude Code sessions). The config help for that key says "Enable auto-indexing on MCP session start", which I read as boot-time catchup rather than a live-watcher master switch — but happy to be corrected. If auto_index=true is in fact the master switch for the watcher, a config-key rename or a note in codebase-memory-mcp config list output would be helpful.

Related closed issues (not duplicates)

• Submodule visibility gap and poll-interval scaling in git-strategy watcher #71 — describes the git-strategy watcher's existence + formula + submodule limitation. Confirms a watcher should exist; doesn't cover "watcher not running at all" on Linux stdio.
• Stack overflow crash in autoindex_thread → cbm_pipeline_pass_configlink (v0.5.6, macOS ARM64) #139 — autoindex_thread crash in v0.5.6; closed/fixed, so the thread should be alive in 0.6.0.
• New files not indexed — WAL-checkpoint blocked on successfully-indexed project (Windows, v0.6.0) #277 — "New files not indexed" but Windows-only (WAL-checkpoint lock on orphan processes). Different root cause; our .db writes land fine when triggered explicitly.

Likely next steps

• Confirm whether auto_index is the master switch (docs/help text update either way).
• If the watcher is running with auto_index=false, any logging hook / metric that could be dumped to confirm autoindex_thread is actually iterating on this repo would help narrow it down.
• If the design is "watcher only runs with auto_index=true", then the config list description should probably read "Enable background auto-indexing of known projects" instead of "on MCP session start" (which reads like a one-shot boot event).

Happy to retest with auto_index=true + server restart and post a follow-up if that changes behavior.

[cryptomaltese]

Follow-up: retested with auto_index=true + fresh MCP server process. Same result — watcher does not fire.

Test conditions

• codebase-memory-mcp config get auto_index → true (confirmed at runtime via the probe script)
• MCP server respawned after flipping the flag (new PID 420383, replacing the pre-flip PID from the first test)
• Same indexed repo, same probe scheme (git-visible untracked .py file with a distinct symbol)
• 120s monitoring window, 24 polls at 5s intervals

Result

• All 24 polls returned total: 0.
• Post-timeout index_repository picked up the probe immediately: nodes: 444 → 447, edges: 816 → 818.
• Cleanup reindex returned counts to baseline.

So

auto_index=true is not the master switch for the live watcher, or the watcher isn't running at all in stdio MCP mode on Linux regardless of that flag. The original filing stands; auto_index can be crossed off the "maybe just a config issue" list.