Summary
graphify update (and the post-commit / post-checkout git hooks, which route through the same code path) writes graph.json with numeric-only community tags and no community_name. The MCP tools (query_graph, get_node, get_community) then show community=7237 instead of a readable hub name like community=stripe.ts. Running graphify cluster-only immediately restores the names — so every auto-refresh silently strips them again.
Version
graphifyy 0.9.12 (uv tool install)
Root cause
The shared code path is _rebuild_code in watch.py, used by both the git hooks and CLI update (cli.py:1268).
watch.py:1010 builds a fully-populated labels dict (LLM-free hub names via label_communities_by_hub).
watch.py:1019 then calls, without community_labels=labels:
json_written = to_json(G, communities, str(graph_tmp), force=True, built_at_commit=commit)
to_json only writes the community_name node field when community_labels= is passed (export.py:249-250).
cluster-only, by contrast, passes it (cli.py:1196) — which is exactly why cluster-only shows names and update does not.
The MCP reads names exclusively from the community_name node field (serve.py:627, 1069, 1106), with no fallback to the .graphify_labels.json sidecar, so the numeric tags surface directly.
Suggested fix
Forward the already-computed labels at watch.py:1019, matching cluster-only:
json_written = to_json(G, communities, str(graph_tmp), force=True, built_at_commit=commit, community_labels=labels)
Zero added cost — labels is already built and to_json already iterates every node; it just sets one extra key. _canonical_graph_for_compare keeps community_name, so it's a one-time rewrite, not repeated churn.
Impact
With the auto-refresh hooks installed, every commit re-strips community names, so agents permanently see numeric cluster IDs and need an extra get_community call to orient. Minor, but recurring and self-inflicted on every rebuild.
Summary
graphify update(and thepost-commit/post-checkoutgit hooks, which route through the same code path) writesgraph.jsonwith numeric-only community tags and nocommunity_name. The MCP tools (query_graph,get_node,get_community) then showcommunity=7237instead of a readable hub name likecommunity=stripe.ts. Runninggraphify cluster-onlyimmediately restores the names — so every auto-refresh silently strips them again.Version
graphifyy 0.9.12 (uv tool install)
Root cause
The shared code path is
_rebuild_codeinwatch.py, used by both the git hooks and CLIupdate(cli.py:1268).watch.py:1010builds a fully-populatedlabelsdict (LLM-free hub names vialabel_communities_by_hub).watch.py:1019then calls, withoutcommunity_labels=labels:to_jsononly writes thecommunity_namenode field whencommunity_labels=is passed (export.py:249-250).cluster-only, by contrast, passes it (cli.py:1196) — which is exactly whycluster-onlyshows names andupdatedoes not.The MCP reads names exclusively from the
community_namenode field (serve.py:627, 1069, 1106), with no fallback to the.graphify_labels.jsonsidecar, so the numeric tags surface directly.Suggested fix
Forward the already-computed
labelsatwatch.py:1019, matchingcluster-only:Zero added cost —
labelsis already built andto_jsonalready iterates every node; it just sets one extra key._canonical_graph_for_comparekeepscommunity_name, so it's a one-time rewrite, not repeated churn.Impact
With the auto-refresh hooks installed, every commit re-strips community names, so agents permanently see numeric cluster IDs and need an extra
get_communitycall to orient. Minor, but recurring and self-inflicted on every rebuild.