fix: expand literal $HOME in injected env path vars (LIFEOS_DIR/LIFEOS_CONFIG_DIR/PROJECTS_DIR) — fixes #1404 shadow-$HOME directories and orphaned learning data

[jbmml]

Problem (#1404)

Claude Code injects settings.json env values verbatim — never shell-expanded — so the shipped settings.system.json values

"LIFEOS_DIR": "$HOME/.claude/LIFEOS",
"PROJECTS_DIR": "$HOME/Projects",
"LIFEOS_CONFIG_DIR": "$HOME/.claude/LIFEOS"

reach every hook/tool as literal strings. Since $HOME/... is a relative path, fs writes resolve under the process cwd: every working directory a session runs in silently grows a junk directory literally named $HOME/ containing shadow MEMORY/LEARNING/STATE trees.

Beyond the junk directories, this loses data: on our install, FailureCapture wrote a full failure record (including a ~950 KB transcript) and SatisfactionCapture wrote sentiment notes and 27 rating lines into shadow trees instead of the real MEMORY/LEARNING — invisible to MemoryRetriever, the statusline ratings display, and the learning loop.

Fix (consumer-side; settings.system.json stays portable)

• 64 TS consumers of process.env.LIFEOS_DIR / LIFEOS_CONFIG_DIR / PROJECTS_DIR get a small normalization block at module load: if the value starts with a literal $HOME/${HOME}, expand it in process.env before any path math. Idempotent, no imports, no behavior change when the value is already absolute. hooks/lib/paths.ts (already expands via expandPath) and Safety.hook.ts (own inline expansion) are untouched.
• LIFEOS_StatusLine.sh: bash ${LIFEOS_DIR:-…} keeps an already-set literal value without re-expanding it, so the script now expands $HOME/${HOME}/~/ prefixes explicitly right after the default assignment. This is the offender that continuously regrows the junk trees on established installs (model/weather/location/version caches every statusline tick), as also reported in the settings.system.json env values ship a literal, unexpanded $HOME — breaks USER scaffold on fresh installs (regression of the #1124 / #1270 class) #1404 comments.

Deliberately not changed: the $HOME form in settings.system.json (it's the portable template; expanding it at install time would also work and could be done as a complement — happy to add that if preferred). The consumer-side fix makes the code correct for existing installs too, which already have the literal value baked into their settings.json.

Testing evidence

Tested on a live LifeOS v6.0.5 install (macOS, Claude Code, bun 1.2.x) carrying the same bug — three shadow $HOME trees had accumulated (in ~/code, ~/Compass, and ~/.claude).

Reproduction of what Claude Code does — run offenders from a pristine cwd with the literal env value:

cd /tmp/proof-cwd
echo '{"model":{"display_name":"Test"},"workspace":{"current_dir":"/tmp/proof-cwd"},"session_id":"proof"}' \
  | env LIFEOS_DIR='$HOME/.claude/LIFEOS' bash LIFEOS_StatusLine.sh
env LIFEOS_DIR='$HOME/.claude/LIFEOS' bun LIFEOS/TOOLS/FreshnessCache.ts
echo '{"session_id":"proof","stop_hook_active":false,"last_assistant_message":"test"}' \
  | env LIFEOS_DIR='$HOME/.claude/LIFEOS' bun hooks/OutputFormatGate.hook.ts

• Before the patch: /tmp/proof-cwd/$HOME/.claude/LIFEOS/... appears, containing MEMORY/STATE/model-cache.txt, USER/CACHE/freshness.json, OBSERVABILITY/format-gate.jsonl.
• After the patch: test cwd stays empty; all three writes land at the real ~/.claude/LIFEOS/... paths with fresh mtimes (verified for statusline caches, freshness cache, and format-gate telemetry).
• All 64 patched TS files pass a Bun.Transpiler parse check; bash -n passes on the statusline; the diff is insert-only (453 insertions, 0 deletions).

Fixes #1404 (fresh-install scaffold breakage has the same root cause; ScaffoldUser.ts / LinkUser.ts / SeedPulse.ts are among the patched consumers).

[danielmiessler]

Merged — thank you. The diagnosis is exactly right, and the before/after repro made it easy to verify.

Two notes on how this landed on my side: this repo is regenerated from my private source tree at release time, so I ported the fix there as well. It applied cleanly everywhere except four files that no longer exist in the 7.x tree, which will drop out of the next release. And your install-time expansion idea is a good complement — I may add that in the scaffolder so future consumers are covered without per-file blocks.

Appreciate the testing evidence. Fixes like this are why I love running this project in the open.