Problem
LifeOS installs into ~/.claude — the user's primary Claude Code config. Across LifeOS/install/, 391 files hardcode ~/.claude / $HOME/.claude (1,780 occurrences), so the install root isn't really a parameter.
That means you can't try LifeOS without adopting it, can't develop it without mutating the assistant you're currently using, and can't run two configurations (work vs. personal, stable vs. dev, two principals on one machine) — which is a shame for a system that's fundamentally about per-principal identity.
The failure mode is quiet, too. USER/CONFIG/LIFEOS_CONFIG.toml ships user_dir = "~/.claude/LIFEOS/USER". Move the config root without rewriting that and LifeosConfig still loads fine — it just resolves to a path that doesn't exist, identity.ts reads no frontmatter, and the install silently reports its DA as "LifeOS" and its principal as "User". Nothing throws, so the try/catch fallback in paiUserDir() never fires.
Fix
Claude Code already supports this — it reads everything from CLAUDE_CONFIG_DIR:
claude # normal setup, ~/.claude
CLAUDE_CONFIG_DIR=~/.claude-lifeos claude # isolated LifeOS
# ~/.zshrc
alias lifeos='CLAUDE_CONFIG_DIR="$HOME/.claude-lifeos" claude'
So the ask is just: stop hardcoding the path, read the config root, default it to ~/.claude. No behavior change for existing users, and it can land incrementally by area (LIFEOS/, skills/, hooks/, agents/, USER/) rather than as one huge diff.
Happy to do that work and split it into reviewable chunks if you want it.
Context
I maintain claude-playbooks — a playbook is just an isolated Claude Code instance, i.e. a directory you point CLAUDE_CONFIG_DIR at.
I'm currently porting LifeOS to run as one, in ramazanpolat/LifeOS@claude/playbook-install: the checkout root is the config root, and a deployer materializes LifeOS/install/ into it, rewriting the hardcoded paths on the way. It works, and it's running my daily instance — but the rewrite pass only exists because the paths aren't parameters. If upstream took the change above, that layer would mostly disappear.
Not asking you to adopt any of my code — just checking whether path-parameterization is something you'd take into account.
Problem
LifeOS installs into
~/.claude— the user's primary Claude Code config. AcrossLifeOS/install/, 391 files hardcode~/.claude/$HOME/.claude(1,780 occurrences), so the install root isn't really a parameter.That means you can't try LifeOS without adopting it, can't develop it without mutating the assistant you're currently using, and can't run two configurations (work vs. personal, stable vs. dev, two principals on one machine) — which is a shame for a system that's fundamentally about per-principal identity.
The failure mode is quiet, too.
USER/CONFIG/LIFEOS_CONFIG.tomlshipsuser_dir = "~/.claude/LIFEOS/USER". Move the config root without rewriting that andLifeosConfigstill loads fine — it just resolves to a path that doesn't exist,identity.tsreads no frontmatter, and the install silently reports its DA as "LifeOS" and its principal as "User". Nothing throws, so thetry/catchfallback inpaiUserDir()never fires.Fix
Claude Code already supports this — it reads everything from
CLAUDE_CONFIG_DIR:So the ask is just: stop hardcoding the path, read the config root, default it to
~/.claude. No behavior change for existing users, and it can land incrementally by area (LIFEOS/,skills/,hooks/,agents/,USER/) rather than as one huge diff.Happy to do that work and split it into reviewable chunks if you want it.
Context
I maintain claude-playbooks — a playbook is just an isolated Claude Code instance, i.e. a directory you point
CLAUDE_CONFIG_DIRat.I'm currently porting LifeOS to run as one, in
ramazanpolat/LifeOS@claude/playbook-install: the checkout root is the config root, and a deployer materializesLifeOS/install/into it, rewriting the hardcoded paths on the way. It works, and it's running my daily instance — but the rewrite pass only exists because the paths aren't parameters. If upstream took the change above, that layer would mostly disappear.Not asking you to adopt any of my code — just checking whether path-parameterization is something you'd take into account.