Graph not updated when the working tree returns to clean (revert leaves false negatives)

[denisborovikov]

Version

0.9.0

Platform

macOS (Apple Silicon)

Install channel

npm

Binary variant

standard

What happened, and what did you expect?

Title: Watcher updates the graph when the tree goes dirty but not when it returns to clean, leaving false negatives after a revert

Summary

With auto_index = true and auto_watch = true, the background watcher picks up changes while the working tree is dirty, but a transition back to clean appears never to be applied. Reverting a change therefore leaves the graph describing the reverted state.

The damaging direction is restoring a deleted file: the graph keeps reporting the symbol as absent. A missing-symbol result reads as "this code does not exist" and is acted on, unlike a stale node which is caught as soon as you open the file.

Reproduction

Repo: ~11.8k tracked files, ~68.5k nodes. Waits of 100–220s between each step; search_graph(name_pattern=...) after each.

#	Action	git status	Graph result
1	create new untracked file exporting zzProbeMarker	??	symbol present ✓
2	delete that untracked file	clean	symbol still present after 3 min ✗
3	rm a tracked file (normalizeSx.ts, 3 nodes)	D	nodes purged ✓
4	git checkout -- to restore it	clean	nodes still absent after 220s ✗

After step 4 the graph reported normalizeSx — a function with 152 in-edges — as non-existent while the file was on disk unchanged. A manual index_repository(mode: "full") restored it immediately.

Steps 1 and 3 (tree going dirty) were applied. Steps 2 and 4 (tree returning to clean) were not.

Expected

After the working tree returns to a clean state matching HEAD, the graph matches HEAD. Restoring a file should re-add its nodes.

Actual

The graph retains whatever the last dirty state produced. It can report a symbol that no longer exists, or fail to report one that does.

Possible duplicate

This may be the same underlying problem as #1296 ("MCP session serves a stale graph indefinitely after the background watcher re-indexes"). I can't distinguish the two from the outside:

• my reading is that the watcher never re-indexes on a return to clean;
• an equally consistent reading is that it does re-index and the session keeps serving a stale graph.

One detail that may help you separate them: in the same session, watcher-driven updates from steps 1 and 3 were visible, and a manual index_repository was visible immediately. So the session is not uniformly stale — only the two clean-transition cases failed to surface. Close as a duplicate of #1296 if that fits better.

Impact

Any workflow that reverts the working tree leaves the graph wrong: git checkout --, discarding changes, dropping a stash, switching back to a previous branch state. In a repo where every task runs in a worktree branched from a shared main checkout, that happens often, and a false negative is the failure most likely to be believed.

Workaround

index_repository(repo_path: "<main checkout>", mode: "full") after reverting anything. Note mode: "fast" is not a substitute — it skips similarity and semantic edges, so it downgrades a graph built with full.

Environment

• codebase-memory-mcp 0.9.0 (~/.local/bin/codebase-memory-mcp)
• macOS (Darwin 25.5.0, arm64), Claude Code
• auto_index = true, auto_index_limit = 50000, auto_watch = true

Project scale (if relevant)

~11.8k tracked files, ~68.5k nodes.

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.

[adfjadfj16-a11y]

Hola Denis, Gracias por compartir este hallazgo. Tras una revisión inicial, parece altamente probable que este comportamiento comparta la misma raíz que el issue #1296 que mencionaste. Para mantener nuestro seguimiento organizado, ¿estarías de acuerdo en que cerremos este ticket y consolidemos los detalles en el #1296? De esta forma, podremos centralizar la investigación y notificarte directamente cuando tengamos una solución que cubra ambos casos. Muchas gracias por tu colaboración. Saludos, En 29 de julio de 2026 12:41:13 p. m. GMT-04:00, Denis Borovikov ***@***.***> escribió:

…

denisborovikov created an issue (DeusData/codebase-memory-mcp#1339) ### Version 0.9.0 ### Platform macOS (Apple Silicon) ### Install channel npm ### Binary variant standard ### What happened, and what did you expect? **Title:** Watcher updates the graph when the tree goes dirty but not when it returns to clean, leaving false negatives after a revert ### Summary With `auto_index = true` and `auto_watch = true`, the background watcher picks up changes while the working tree is **dirty**, but a transition back to **clean** appears never to be applied. Reverting a change therefore leaves the graph describing the reverted state. The damaging direction is restoring a deleted file: the graph keeps reporting the symbol as absent. A missing-symbol result reads as "this code does not exist" and is acted on, unlike a stale node which is caught as soon as you open the file. ### Reproduction ### Reproduction Repo: ~11.8k tracked files, ~68.5k nodes. Waits of 100–220s between each step; `search_graph(name_pattern=...)` after each. | # | Action | git status | Graph result | |---|---|---|---| | 1 | create new untracked file exporting `zzProbeMarker` | `??` | symbol **present** ✓ | | 2 | delete that untracked file | clean | symbol **still present** after 3 min ✗ | | 3 | `rm` a tracked file (`normalizeSx.ts`, 3 nodes) | ` D` | nodes **purged** ✓ | | 4 | `git checkout --` to restore it | clean | nodes **still absent** after 220s ✗ | After step 4 the graph reported `normalizeSx` — a function with 152 in-edges — as non-existent while the file was on disk unchanged. A manual `index_repository(mode: "full")` restored it immediately. Steps 1 and 3 (tree going dirty) were applied. Steps 2 and 4 (tree returning to clean) were not. ### Logs ```text ``` ### Diagnostics trajectory (memory / performance / leak issues) ```text ### Expected After the working tree returns to a clean state matching HEAD, the graph matches HEAD. Restoring a file should re-add its nodes. ### Actual The graph retains whatever the last dirty state produced. It can report a symbol that no longer exists, or fail to report one that does. ### Possible duplicate This may be the same underlying problem as **#1296** ("MCP session serves a stale graph indefinitely after the background watcher re-indexes"). I can't distinguish the two from the outside: - my reading is that the watcher never re-indexes on a return to clean; - an equally consistent reading is that it does re-index and the session keeps serving a stale graph. One detail that may help you separate them: in the same session, watcher-driven updates from steps 1 and 3 **were** visible, and a manual `index_repository` was visible immediately. So the session is not uniformly stale — only the two clean-transition cases failed to surface. Close as a duplicate of #1296 if that fits better. ### Impact Any workflow that reverts the working tree leaves the graph wrong: `git checkout --`, discarding changes, dropping a stash, switching back to a previous branch state. In a repo where every task runs in a worktree branched from a shared main checkout, that happens often, and a false negative is the failure most likely to be believed. ### Workaround `index_repository(repo_path: "<main checkout>", mode: "full")` after reverting anything. Note `mode: "fast"` is not a substitute — it skips similarity and semantic edges, so it downgrades a graph built with `full`. ### Environment - codebase-memory-mcp 0.9.0 (`~/.local/bin/codebase-memory-mcp`) - macOS (Darwin 25.5.0, arm64), Claude Code - `auto_index = true`, `auto_index_limit = 50000`, `auto_watch = true` ``` ### Project scale (if relevant) ~11.8k tracked files, ~68.5k nodes. ### Confirmations - [x] I searched existing issues and this is not a duplicate. - [x] My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code. -- Reply to this email directly or view it on GitHub: #1339 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[denisborovikov]

Hey, I can do it, but I'm not sure if this message is legit and where it came from.

[oscar6echo]

Independent reproduction on Linux, and I think I have the datapoint that
separates this from #1296.

Environment

• v0.9.0 (latest release; no newer build available)
• Linux 7.0.0-28-generic, x86-64
• Statically-linked ELF binary at ~/.local/bin/codebase-memory-mcp (not npm)
• auto_index = true, auto_watch = true (confirmed via config list)
• Long-running MCP server under Claude Code, single session throughout

Notably this is a very small repo — 44 files, 409 nodes, 1665 edges, Python +
Bash — versus your ~11.8k files / ~68.5k nodes. So this doesn't look like a
scale- or debounce-timing artifact.

Repro

All five of your steps reproduce, with the same split. Waits are wall-clock
between the filesystem change and the search_graph call; each row is a single
observation, not a poll.

#	Action	git status	Wait	Graph result
1	create untracked _zz_watch_probe.py exporting zz_watch_probe_marker	??	~30s	symbol present	✓
2	edit it — add zz_watch_probe_second, called by the first	??	~30s	second symbol absent	—
2b	(same edit, longer wait)	??	~2min	both symbols present, CALLS edge present (out_degree 0→1)	✓
3	delete that untracked file	clean	~100s	all 4 nodes still present	✗
4	rm a tracked file (query_toto.py, 12 nodes)	D	~150s	nodes purged	✓
5	git checkout -- to restore it	clean	~180s	nodes still absent	✗

Step 5 matches your normalizeSx case: the graph reported class Abacus
(in_degree 3) as non-existent while the file sat unchanged on disk. Project
node count read 397 against a true 409. A manual index_repository(mode:"full")
restored it immediately and exactly.

Steps 3 and 4 being both deletions with opposite outcomes is what convinced me
the boundary isn't "deletes" — it's the direction of the tree state.

On #1296 vs this

You noted you couldn't distinguish "watcher never re-indexes on return to clean"
from "it does re-index and the session serves a stale graph". One observation
that may settle it:

Every dirty-direction update in the table was visible through the same
long-running MCP session, with no restart. Steps 1, 2b and 4 all landed in a
session that had already served queries against the pre-change graph — including
step 4, a purge, which is the same class of write a return-to-clean re-index
would have to perform.

If the session were pinned to a stale cached store, steps 1/2b/4 should have been
invisible too. They weren't. So on POSIX at least, the cache demonstrably does
refresh on watcher events, which points at your first reading — no re-index is
triggered on the clean transition — rather than at a stale-session cache.

That's inference from black-box behaviour, not from the internals; it rules out
"session cache never refreshes", but not a narrower invalidation bug that happens
to only affect the clean path.

Minor, possibly unrelated

Two consecutive index_repository(mode:"full") runs over byte-identical sources
returned 409 nodes both times but 1665 then 1658 edges. Both self-reported
expected_edges equal to what they produced, so nothing flagged it. Happy to
split this into its own issue if it isn't already known — it's only a nuisance
here because edge count is otherwise a cheap drift signal.

[DeusData]

Thank you, and thanks also to @oscar6echo for the independent Linux reproduction. The same live session successfully observes dirty-state updates, while only the return-to-clean transition is missed, so this is not a duplicate of the uniformly stale session behavior in #1296. Current main added an explicit dirty-signature transition check after 0.9.0, making this a required RC regression case rather than grounds to close the report. I have routed it at high priority in 0.9.1-rc. For clarity, the earlier Spanish support-style comment was not posted by the maintainer account or project team; please disregard it.

[DeusData]

One follow-up from the tag comparison: both public reproductions are on 0.9.0, while the dirty-state signature transition logic from 9789a7c5 is present in v0.9.1-rc.1 and current main. Could either reporter retest the dirty to clean sequence on RC1 or a current-main build? I have marked this awaiting that verification while keeping it high priority in 0.9.1-rc; the existing evidence remains valuable and the issue stays open.

[github-actions]

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

• the codebase-memory-mcp --version you're on
• the exact steps or command you ran
• a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.