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.