graphify install is not profile-isolated: CLAUDE.md registration ignores CLAUDE_CONFIG_DIR; other platforms' version stamps advance without their content

[yotamleo]

graphify install is not profile-isolated: CLAUDE.md registration ignores CLAUDE_CONFIG_DIR, and other platforms' version stamps are advanced without their content

Summary

Two related side effects of graphify install --platform claude (verified against 0.9.40 install.py):

1. The skill copy honors CLAUDE_CONFIG_DIR, but the CLAUDE.md registration does not. The skill destination resolves via CLAUDE_CONFIG_DIR when set (install.py ~119-120), yet the always-on registration writes Path.home() / ".claude" / "CLAUDE.md" unconditionally (~line 629). Running the installer from a redirected/routed Claude profile therefore mutates the DEFAULT profile's CLAUDE.md — surprising for multi-profile setups (e.g. a work profile vs personal profile split via CLAUDE_CONFIG_DIR).

2. .graphify_version is advanced for every other installed platform without updating those platforms' skill contents (install.py ~58-65). After a claude-platform install, a stale Codex/OpenCode/etc. skill directory carries a CURRENT version stamp, which suppresses the per-run "skill is from graphify X, package is Y" warning that would otherwise prompt the user to refresh it — the stamp now asserts a refresh that never happened.

Suggested fixes

• Resolve the CLAUDE.md path through the same CLAUDE_CONFIG_DIR logic as the skill path (or add a --config-dir override), so a redirected profile is fully self-contained.
• Only stamp .graphify_version for platforms whose skill content was actually (re)written in this run; leave other platforms' stamps untouched so their staleness warnings stay truthful.

Impact

Wrapper tooling that wants a safe "refresh the Claude skill after a package upgrade" step currently has to refuse to run the installer from any routed profile to avoid cross-profile writes, and cannot trust other platforms' stamps afterwards.

Environment

graphify 0.9.40 (also present in 0.9.36), Windows 11, graphify install --platform claude.

[yotamleo]

Related history: #527 (closed) fixed CLAUDE_CONFIG_DIR handling for the skill copy path — this issue is the residual: the always-on CLAUDE.md registration at install.py ~629 still resolves Path.home() unconditionally, so the #527 fix does not cover it. Verified against 0.9.40.

[AromalBiju1]

Confirmed still reproducing on 0.9.43 — traced it to install.py around line 637, where the always-on CLAUDE.md registration resolves Path.home() unconditionally, same root cause you diagnosed. I have a fix ready (mirrors the CLAUDE_CONFIG_DIR check already used in _platform_skill_destination at lines 120–122) and verified it locally across all three cases — project scope, global with CLAUDE_CONFIG_DIR set, and global default fallback. Will open a PR shortly.

[safishamsi]

Part 1 (CLAUDE.md registration honoring CLAUDE_CONFIG_DIR) shipped in v0.9.44 via #2753, thanks @AromalBiju1. Leaving this open for the remaining half: the per-platform .graphify_version stamp is written without rewriting skill content, which suppresses staleness warnings.

[safishamsi]

Both halves are now shipped: part 1 (CLAUDE.md registration honoring CLAUDE_CONFIG_DIR) in v0.9.44 via #2753, and part 2 (per-platform version stamp) in v0.9.45 via #2777. Thanks @AromalBiju1 and @ousamabenyounes. Closing.