Version
codebase-memory-mcp 0.10.8 (build 1175645cb30560e7e47d78611cd1bcb509478eaf6d4e51f72fe18327ee9c1351)
Platform
Linux (WSL2)
Install channel
npm/binary install (~/.local/bin/codebase-memory-mcp)
Config
auto_watch = true, auto_index = false
What happened
Two indexed projects (git worktrees, both on branches ≥25 chars with hyphens — 4385-auditable-patreon-manual-grants (36 chars) and 4386-patreon-over-entitlement (29 chars)) entered a sustained self-triggering reindex loop with no real file changes behind it. Watched the daemon log live over an 8s window with nothing else touching either worktree:
level=info msg=index.supervisor.reap outcome=clean exit_code=0 signal=0
level=info msg=watcher.changed project=...4385-auditable-patreon-manual-grants strategy=git
i.e. an index run finishing is itself immediately re-detected as a "changed" event on the same project, which re-queues another index run, indefinitely. Over a ~15 min log window this produced 100+ watcher.changed strategy=git events alternating between the two projects, and two --index-worker child processes stayed pinned at 100%+ CPU the whole time.
git reflog on both worktrees showed no commits/rebases in the 15-40 minutes preceding the loop, and nothing under .git had an mtime inside the observation window — so this isn't real git activity being (correctly) detected, it's a false positive.
Why I think this is #1254, not #45
#1254 ("watcher.reindex infinite loop — git branch name overflows path buffer") was closed with the same log signature (watcher.changed → watcher.reindex → index.supervisor.reap in a tight loop, strategy=git) and the same repro condition: a git branch name ≥25 chars containing hyphens, corrupting the tracked path and causing every subsequent comparison to read as "changed". Both of my affected branch names hit that same profile. #45 is a separate, general "polling is too aggressive" report addressed by the v0.4.8 interval change — that fix wouldn't explain a zero-real-change loop like this one. This looks like either a regression of the #1254 fix, or a second bug with the same buffer-overflow shape that the #1254 fix didn't fully close.
I didn't have path= output on the watcher.changed lines themselves to directly confirm path corruption this time (only watcher.watch logs the path, at initial registration) — happy to add more logging/repro steps if that would help narrow it down.
Workaround
codebase-memory-mcp config set auto_watch false + daemon restart stops the loop, at the cost of losing automatic re-indexing (same workaround noted in #1254).
Impact
On a machine running many concurrent worktrees/sessions (14 committed daemon clients at the time), this pinned 100%+ CPU per affected project indefinitely with zero real work happening — not a one-off spike.
Version
codebase-memory-mcp 0.10.8 (build 1175645cb30560e7e47d78611cd1bcb509478eaf6d4e51f72fe18327ee9c1351)
Platform
Linux (WSL2)
Install channel
npm/binary install (
~/.local/bin/codebase-memory-mcp)Config
auto_watch = true,auto_index = falseWhat happened
Two indexed projects (git worktrees, both on branches ≥25 chars with hyphens —
4385-auditable-patreon-manual-grants(36 chars) and4386-patreon-over-entitlement(29 chars)) entered a sustained self-triggering reindex loop with no real file changes behind it. Watched the daemon log live over an 8s window with nothing else touching either worktree:i.e. an index run finishing is itself immediately re-detected as a "changed" event on the same project, which re-queues another index run, indefinitely. Over a ~15 min log window this produced 100+
watcher.changed strategy=gitevents alternating between the two projects, and two--index-workerchild processes stayed pinned at 100%+ CPU the whole time.git reflogon both worktrees showed no commits/rebases in the 15-40 minutes preceding the loop, and nothing under.githad an mtime inside the observation window — so this isn't real git activity being (correctly) detected, it's a false positive.Why I think this is #1254, not #45
#1254 ("watcher.reindex infinite loop — git branch name overflows path buffer") was closed with the same log signature (
watcher.changed→watcher.reindex→index.supervisor.reapin a tight loop,strategy=git) and the same repro condition: a git branch name ≥25 chars containing hyphens, corrupting the tracked path and causing every subsequent comparison to read as "changed". Both of my affected branch names hit that same profile. #45 is a separate, general "polling is too aggressive" report addressed by the v0.4.8 interval change — that fix wouldn't explain a zero-real-change loop like this one. This looks like either a regression of the #1254 fix, or a second bug with the same buffer-overflow shape that the #1254 fix didn't fully close.I didn't have
path=output on thewatcher.changedlines themselves to directly confirm path corruption this time (onlywatcher.watchlogs the path, at initial registration) — happy to add more logging/repro steps if that would help narrow it down.Workaround
codebase-memory-mcp config set auto_watch false+ daemon restart stops the loop, at the cost of losing automatic re-indexing (same workaround noted in #1254).Impact
On a machine running many concurrent worktrees/sessions (14 committed daemon clients at the time), this pinned 100%+ CPU per affected project indefinitely with zero real work happening — not a one-off spike.