Repository navigation
CBM_WATCH_MAX_INTERVAL_MS env var to configure watcher poll interval cap #1478
Description
What problem does this solve?
The watcher currently hard-caps per-project poll intervals at 60s (POLL_MAX_MS = 60000 in src/watcher/watcher.c). Each poll fires two supervised git subprocesses per watched repo (git rev-parse HEAD + git status --porcelain -uall -z). On Windows with many large repos under CBM_ALLOWED_ROOT, this creates continuous background CPU/IO load that is too aggressive for developer workstations.
Environment / scale
| Metric | Value |
|---|---|
| Indexed projects | 244 |
| Total graph nodes | ~4.4M |
| Total graph edges | ~18M |
| Total cache size | ~15 GB |
| Projects > 100k nodes | 9 |
| Largest project (nodes) | ~475k |
| OS | Windows 11 |
At the 60s max poll interval, the watcher fires git rev-parse HEAD + git status --porcelain -uall -z per git-detected project every minute. On Windows, git status -uall on large repos is particularly expensive (no fsmonitor equivalent by default), and with this many projects the load is continuous.
Proposed solution
Add a CBM_WATCH_MAX_INTERVAL_MS environment variable that overrides POLL_MAX_MS in cbm_watcher_poll_interval_ms(), following the existing pattern of CBM_WATCHER_PRUNE_GRACE_S. This would allow users to set the cap to e.g. 1 hour (3600000) without disabling watching entirely.
Suggested implementation
int cbm_watcher_poll_interval_ms(int file_count) {
const char *raw = getenv("CBM_WATCH_MAX_INTERVAL_MS");
int max_ms = POLL_MAX_MS;
if (raw && raw[0]) {
long v = strtol(raw, NULL, 10);
if (v > 0) {
max_ms = (v > INT_MAX) ? INT_MAX : (int)v;
}
}
int ms = POLL_BASE_MS + ((file_count / POLL_FILE_STEP) * CBM_MSEC_PER_SEC);
return ms > max_ms ? max_ms : ms;
}
Environment
- OS: Windows 11
- CBM_ALLOWED_ROOT: large directory tree with many git repos
- CBM_WORKERS=2, CBM_MEM_BUDGET_MB=4096
Alternatives considered
No response
Confirmations
- I searched existing issues and this is not a duplicate.
Activity
DeusData commentedon Aug 10, 2026
Thank you for the concrete watcher proposal and Windows context. Confirmed that current
mainhard-caps the watcher interval at 60 seconds and exposes no environment override for that cap. I have routed the configurability request under the watcher epic for0.11.0-rcwith normal priority.vitalca commentedon Aug 21, 2026
@leonfin - I suppose you don't need the watchers for the majority of the indexed 244 repositories. You only actively work on a handful of them. If that's the case, here is a suggestion for a temporary workaround.
codebase-memory-mcp config set auto_watch falsecodebase-memory-mcp cli index_repository --repo-path "$PWD" --name "$(basename "$PWD")"SessionStartandStop(see [1])[1]: This is what I always do, because sometimes CBM lags behind and does not see new directories. It finishes almost immediately for already indexed regular-size repos. But unfortunately I am heavily impacted by #1670 which adds ~5.5 sec to each CLI call on v0.10.x (with a warm daemon running!)
@DeusData - would be really great to be able to
set auto_watch falseper project! Would you consider this feature request?leonfin commentedon Aug 24, 2026
@vitalca thank you for the ideas! I set it up as git hook for now. Script per agent session start/stop doesn't really work for me since I usually work across multiple repos in same session. Also, I use codebase mcp cross repos in same claude session. That's where it's most valuable for me.
DeusData commentedon Oct 19, 2026
Thank you for the follow-up explaining why a session hook is insufficient when you work across many repositories. The configurable poll cap and the additional per-project auto-watch suggestion are separate choices; I have no new decision or implementation outcome to report for either.
DeusData commentedon Oct 25, 2026
Thank you for explaining the multi-repository workflow. Configurable poll intervals and per-project watch selection remain distinct maintainer decisions. Sorry for the delay; this is waiting on maintainer follow-up, and I’ll follow up soon.