Repository navigation
graphify-out files use absolute paths breaking portability across machines and directories #1417
Description
On macOS (Darwin 25.4.0), running /graphify . generates files in graphify-out/ that contain hardcoded absolute paths, making the outputs non-portable.
Affected files
manifest.json — All file keys are absolute paths:
{
"/Users/username/projects/my-project/backend/cmd/server/main.go": {
"mtime": 1781639382.9082484,
...
}
}This makes graphify --update fail to match any cached files when the repo is cloned to a different directory or shared between machines.
.graphify_root — Stores the absolute scan root:
/Users/username/projects/my-project
Should store the relative path (e.g., .) and resolve against CWD at runtime.
graph.json — Some source_file values leak absolute paths (files at repo root level), while most are correctly relativized. Semantic extraction subagents receive absolute paths in FILE_LIST and write them verbatim.
Cache directory (cache/semantic/) — Likely uses absolute paths for cache keys, same as manifest.
Expected behavior
All paths in graphify-out/ outputs should be relative to the scan root, so the outputs are portable across clones, machines, and users.
Steps to reproduce
git clone https://github.com/some-project
cd some-project
graphify .
# Observe manifest.json keys, .graphify_root, and graph.json source_file valuesEnvironment
- OS: macOS (Darwin 25.4.0)
- graphify: v0.8.44, installed via
uv tool install graphifyy
Activity
Write a portable manifest.json from the skill runbooks (#1417)
safishamsi commentedon Jun 22, 2026
Fixed on
v8(ships in the next release).The portability-breaking paths are now relativized:
manifest.json— the skill runbooks now passroot=tosave_manifest, so keys are stored relative to the scan root (1f42a2d); the nativegraphify extract/updateCLI already did this (bug: absolute paths in manifest.json, .graphify_root, and cache/ast/*.json break git-shared graphify-out/ across machines #777). This is the headline fix:graphify --updatenow matches cached files after a clone/move instead of re-extracting the whole corpus.graph.jsonsource_file— relativized for nodes/edges (pre-existing) and now forhyperedges[]too (d168de9, bug: to_json does not relativize source_file on graph.hyperedges[] entries — only nodes[] and links[] #1418).Two of the sub-points are intentional, not bugs:
.graphify_rootstays absolute by design. It's read by the post-commit/post-checkout git hooks, which run from the repo root regardless of where the graph was built. If you ran/graphifyfrom a subdirectory, a relative.would point the hook at the wrong tree; the absolute path keeps the rebuild correct. It's per-machine state and shouldn't be committed (see the.gitignoreguidance discussion in Question — manifest.json absolute paths + missing graphify-out/.gitignore: intended or oversight? #722).cache/keys are SHA-256 content hashes, not paths — already portable.If the
.graphify_rootbehaviour is a problem for your workflow, reopen and we can revisit (e.g. storing it relative only when the scan root equals the repo root).Release 0.8.45
Write a portable manifest.json from the skill runbooks (Graphify-Labs…
Release 0.8.45