GRAPH_REPORT.md's generated header embeds the absolute path of the machine that built it:
# Graph Report - /Users/<user>/dev/apps/<project> (2026-08-03)
Source is graphify/report.py:104:
f"# Graph Report - {root} ({today})",
root is interpolated as given, so the header reflects whatever was passed on the command line: running graphify update . from inside the project yields # Graph Report - ., while passing an absolute root bakes the full host path into the file.
This is the same class as #2598, just fixed for graph.html's <title>. GRAPH_REPORT.md is a tracked artifact in practice — of six repos here, four commit it, and one of those carries an absolute /Users/... path in its committed blob. The result is that the same graph produces different bytes on different machines, and the build machine's directory layout ends up in git history.
Suggested fix, mirroring #2598: prefer a project-relative label or the directory basename rather than interpolating root raw.
Notes for triage:
Observed on 0.9.40.
GRAPH_REPORT.md's generated header embeds the absolute path of the machine that built it:Source is
graphify/report.py:104:f"# Graph Report - {root} ({today})",rootis interpolated as given, so the header reflects whatever was passed on the command line: runninggraphify update .from inside the project yields# Graph Report - ., while passing an absolute root bakes the full host path into the file.This is the same class as #2598, just fixed for
graph.html's<title>.GRAPH_REPORT.mdis a tracked artifact in practice — of six repos here, four commit it, and one of those carries an absolute/Users/...path in its committed blob. The result is that the same graph produces different bytes on different machines, and the build machine's directory layout ends up in git history.Suggested fix, mirroring #2598: prefer a project-relative label or the directory basename rather than interpolating
rootraw.Notes for triage:
manifest.json,.graphify_rootandcache/ast/*.json, but explicitly notGRAPH_REPORT.md.graphify/__main__.pyandgraphify/detect.py— it never touchesreport.py, so the report header is not actually covered by it. That PR is also currently conflicting and last updated 2026-05-23.Observed on 0.9.40.