People run LifeOS with more than one Claude account on the same machine — a personal
one and a work/agency one. LifeOS has no supported way to configure this. It should be a
first-class setting in LifeOS's own config/permissions layer, not something each user
hand-rolls with symlink surgery (and gets wrong).
This is not an edge case. Anyone doing freelance or agency work alongside their own life
needs it. Company Claude accounts are commonly administered by someone else who can read
the session history, so the two contexts must stay isolated.
What a LifeOS user has to do today (and why it breaks)
Our setup: personal account (Claude Pro) with the full LifeOS — TELOS, finances, health,
identity, memory. Separate work account (Claude Max, owned and administered by the boss)
for client work. Switched with a shell alias that sets CLAUDE_CONFIG_DIR.
LifeOS assumes one principal / one login. LIFEOS/USER and LIFEOS/MEMORY are
bound to a single identity. There is no supported way to share the engine while keeping
USER data per-profile.
Agentic /LifeOS setup and the migration tooling symlink LIFEOS/USER +
LIFEOS/MEMORY into the second profile so it has "the same structure". That drags the
personal TELOS, PROJECTS, identity and finances into a third-party-administered account.
For us it ended with the account's admin seeing a private client's name on screen. The
fix was manual and fragile: detach symlinks, drop placeholder files, comment out the
identity @-imports in CLAUDE.md.
DetectEnv / install tools target whatever profile they run from — everything had
to be run with CLAUDE_CONFIG_DIR=$HOME/.claude or the install leaked into the other
profile through the skills/ symlinks.
What we'd want from LifeOS
Profile as a first-class concept. lifeos profile add work --account creates a
profile that shares the engine (skills, hooks, TOOLS, Algorithm, docs) by symlink but has
its own real (non-symlink) LIFEOS/USER and LIFEOS/MEMORY with a minimal neutral
scaffold. Recorded in LifeOS config so the tooling knows which config-dir is primary.
A guard, shipped by default. SessionStart check that refuses / loudly warns when a
non-primary profile's LIFEOS/USER or /MEMORY is a symlink to the primary USER tree.
We wrote one — HustleProfileGuard.hook.ts — happy to contribute it as a starting point.
A supported way to share selected context without leaking the whole USER tree.
Our interim pattern: project/client context lives in per-repo / per-folder CLAUDE.md
files on disk outside /.claude (/Developer/**/CLAUDE.md), which Claude Code
auto-loads on cd from any profile. Sensitive material (rates, pipeline, strategy) stays
in the primary LIFEOS/USER. A LIFEOS/USER/SHARED/ subtree that is explicitly
allowed to be exposed to other profiles (unlike the rest of USER) would make this native.
/LifeOS setup and migration should ask whether the target config-dir is the primary
profile, and refuse to symlink USER/MEMORY into a non-primary one.
Our context
LifeOS 7.40.4, migrated from PAI v5.0.0 on 2026-08-28. Our migration runbook has ~9
documented traps; this leak is trap #10. Happy to share the runbook or the guard hook.
People run LifeOS with more than one Claude account on the same machine — a personal
one and a work/agency one. LifeOS has no supported way to configure this. It should be a
first-class setting in LifeOS's own config/permissions layer, not something each user
hand-rolls with symlink surgery (and gets wrong).
This is not an edge case. Anyone doing freelance or agency work alongside their own life
needs it. Company Claude accounts are commonly administered by someone else who can read
the session history, so the two contexts must stay isolated.
What a LifeOS user has to do today (and why it breaks)
Our setup: personal account (Claude Pro) with the full LifeOS — TELOS, finances, health,
identity, memory. Separate work account (Claude Max, owned and administered by the boss)
for client work. Switched with a shell alias that sets CLAUDE_CONFIG_DIR.
LifeOS assumes one principal / one login. LIFEOS/USER and LIFEOS/MEMORY are
bound to a single identity. There is no supported way to share the engine while keeping
USER data per-profile.
Agentic /LifeOS setup and the migration tooling symlink LIFEOS/USER +
LIFEOS/MEMORY into the second profile so it has "the same structure". That drags the
personal TELOS, PROJECTS, identity and finances into a third-party-administered account.
For us it ended with the account's admin seeing a private client's name on screen. The
fix was manual and fragile: detach symlinks, drop placeholder files, comment out the
identity @-imports in CLAUDE.md.
DetectEnv / install tools target whatever profile they run from — everything had
to be run with CLAUDE_CONFIG_DIR=$HOME/.claude or the install leaked into the other
profile through the skills/ symlinks.
What we'd want from LifeOS
Profile as a first-class concept. lifeos profile add work --account creates a
profile that shares the engine (skills, hooks, TOOLS, Algorithm, docs) by symlink but has
its own real (non-symlink) LIFEOS/USER and LIFEOS/MEMORY with a minimal neutral
scaffold. Recorded in LifeOS config so the tooling knows which config-dir is primary.
A guard, shipped by default. SessionStart check that refuses / loudly warns when a
non-primary profile's LIFEOS/USER or /MEMORY is a symlink to the primary USER tree.
We wrote one — HustleProfileGuard.hook.ts — happy to contribute it as a starting point.
A supported way to share selected context without leaking the whole USER tree.
Our interim pattern: project/client context lives in per-repo / per-folder CLAUDE.md
files on disk outside
/.claude (/Developer/**/CLAUDE.md), which Claude Codeauto-loads on cd from any profile. Sensitive material (rates, pipeline, strategy) stays
in the primary LIFEOS/USER. A LIFEOS/USER/SHARED/ subtree that is explicitly
allowed to be exposed to other profiles (unlike the rest of USER) would make this native.
/LifeOS setup and migration should ask whether the target config-dir is the primary
profile, and refuse to symlink USER/MEMORY into a non-primary one.
Our context
LifeOS 7.40.4, migrated from PAI v5.0.0 on 2026-08-28. Our migration runbook has ~9
documented traps; this leak is trap #10. Happy to share the runbook or the guard hook.