Power Claude account groups go beyond a flat multi-account rotator. Name a set for Work, Job A, or Client B; put only those Claude seats in it; pool within that set; activate it when that engagement is live; and hard-isolate Claude Code projects/memory so other jobs never inherit that context.
TL;DR: Account groups isolate seats and memory by job or client. Activate a named group so Job A never shares context or burn with personal or Client B work.
TL;DR (agentic extract)
| Goal | Do this |
|---|---|
| Scoped pool for Job A / Client B | Create a named group, put only those seats in it, Use this group while on that engagement |
| Keep work ≠ personal memory | Isolated groups; activate when you switch roles |
| Group any accounts + name them | + New group → any free-form name → drag accounts from Ungrouped |
| Active set for “who I am now” | Dashboard Use this group or pc scope use <id> |
| One account, many labels | Use tags for labels; groups are single-membership (by design) |
| Architecture | Official Claude profiles (CLAUDE_CONFIG_DIR); groups isolate local context, not OAuth tokens |
Power Claude account groups vs a flat multi-account rotator
Most multi-account tooling gives you either:
- One global pool of every login on the machine (every job, client, and personal seat compete in the same flat list), or
- Manual switch / dual config dirs (you pick one login at a time, with no named “Client B set”).
Neither answers: “For Client North this week, only these three seats, with Client North memory — not my side project and not Job A.”
Power Claude account groups add that missing layer:
| Capability | Flat dual-login / shell aliases | Flat multi-account rotator | Power Claude account groups |
|---|---|---|---|
| Two logins stay signed in | Yes (CLAUDE_CONFIG_DIR) | Yes | Yes (profiles + membership) |
| Name a set: Work / Job A / Client B | No | No | Yes — free-form group names |
| Put only those seats in the set | No | Rarely (usually all-in) | Yes — drag membership |
| Pool members inside that set for the engagement | No | One global pool | **Yes — the group is the scoped set** |
| Activate “run Job A now” | Manual shell discipline | Manual exclude/include hacks | Use this group / pc scope use |
| Hard-isolate projects/memory per set | Partial (separate dirs only) | No | Yes — isolation on by default |
| Credentials stay private per account | Yes | Depends | Yes — groups never copy OAuth |
The problem: multi-account Claude without isolation
Claude Code is excellent at remembering a project. Transcripts, memory files, and tool history accumulate under your config. That is a feature — until you switch personas or engagements.
People searching for:
- “separate work and personal Claude”
- “Claude Code multiple accounts”
- “isolate Claude context”
- “group Claude accounts”
- “name Claude account groups”
- “client-specific Claude accounts”
are not asking for a second password manager. They need named, poolable boundaries: which seats belong to Job A vs Client B, and which memory tree is live when that job is on.
| Pattern | What goes wrong without groups |
|---|---|
| Work + personal on one laptop | Side-project experiments inherit enterprise context (or vice versa) |
| Agency / freelancers | Client A conventions leak into Client B sessions |
| Several seats for one job | Personal login accidentally used for work capacity |
| Billing by project | No durable “these seats are Project X” boundary |
| Manual “just switch account” | No durable active set; context still shared |
What account groups are (authoritative model)
An account group (CLI: scope) is a named, poolable set of seats for one engagement — Work, Job A, Client B — not a label on a global free-for-all.
| Piece | Meaning |
|---|---|
| Group name | Human label you choose: Work, Personal, Client-Acme, Sandbox, Billing-ProjectX |
| Members | Any linked accounts you drag or pc scope add into the group |
| Active group | “What I am working as right now” |
| Isolated (default) | Group-local projects/memory tree under ~/.power-claude/claude-shared/scopes/<id>/ |
| Global (optional) | Members use the machine-wide shared projects tree |
State file (mode 0600): ~/.power-claude/state/account-scopes.json.
~/.power-claude/
state/account-scopes.json
claude-shared/projects/ # global tree
claude-shared/scopes/<group-id>/projects/ # this group onlyWhen you Use this group with isolation on, Power Claude re-points member profiles’ projects layout at the group tree. It fails closed on conflicts and never touches .credentials.json.
Name groups like real personas
You can name a group anything. The product does not force Work/Personal — those are conventions that match how people actually switch roles.
| Name | Who belongs | Isolation | When to activate |
|---|---|---|---|
Work | Company / contractor seats | Isolated | Before workday / work repos |
Personal | Personal email Max/Pro | Isolated | Side projects, learning |
Client-North | Client North’s seats | Isolated | Before opening that monorepo |
Client-South | Client South’s seats | Isolated | Same |
Project-Alpha | Seats billed to Alpha | Isolated | When that project is “on” |
Sandbox | Throwaway / experimental | Isolated | Risky agentic runs |
Team-Shared | Seats that should share memory | Global (optional) | Only if you want one brain |
Naming tips that stay useful
- Prefer short, stable names (
Work, notmy work stuff 2026). - Match repo or client codes if you use shell aliases (
pc scope usein direnv). - One group per persona boundary, not one group per account (unless that account is the persona).
- For agencies:
Client-<code>beats vague names likeStufforOther. - For freelancers billing by project: name the group after the invoice line, then put every seat used for that project in it.
How to set up: name groups and put any accounts in them
Dashboard (about 5 minutes)
- Open Power Claude → Your Profiles.
- Under Account groups, click + New group.
- Name it (e.g.
Work). Isolation defaults on. - Create
Personal(and any client or project groups). - Drag account chips from Ungrouped onto the correct group — any linked account can go in any group.
- Click Use this group on Work before work.
- Switch to Personal (or another group) when your role changes, or Clear active group.
There is no special “work account type.” Membership is free-form: group any combination of logins, name the set, activate when that persona is live.
CLI (same model)
pc scope create Work
pc scope create Personal
pc scope create Client-Acme
pc scope list
pc scope add <work-id> you+work@company.com
pc scope add <personal-id> you@gmail.com
pc scope add <client-id> client@acme.com
pc scope use <work-id> # active group + apply layout
pc scope use none # clear active
pc scope isolation <id> isolated # or: global
pc scope move you@gmail.com <personal-id>
pc scope move you@gmail.com none # ungroup
pc scope delete <id>Aliases: pc scopes, pc group, pc groups.
Verify isolation
pc scope list # active marked with *
ls ~/.power-claude/claude-shared/scopes/Run a short session under Work, switch to Personal, confirm you are not continuing the same memory tree.
Decision tree: groups vs tags vs CLAUDE_CONFIG_DIR
| Need | Use |
|---|---|
| Separate logins (distinct OAuth / config dirs) | Official Claude profiles via CLAUDE_CONFIG_DIR (Architecture B) |
| Separate personas + local memory + active set | Account groups (this feature) |
| Soft labels only (“favorite”, “backup”) | Tags (pc tag) — no isolation |
| Shared memory on purpose across seats | Group with isolation global, or leave ungrouped |
Single membership rule: one account lives in at most one group. That keeps isolation unambiguous. If you need multi-label classification without dual isolation, use tags.
Use cases (search-intent examples)
Work vs personal on one machine
Two isolated groups; assign accounts; activate before role changes. → Step-by-step: Separate work and personal Claude accounts
Agency with three clients
Groups Client-North, Client-South, Internal. Assign seats; Use the matching group before opening that client’s repo. Naming the group after the client is the whole product: any accounts, any name, clear active set.
Several seats for one product
One isolated group ProductX with every work seat; personal stays out. Capacity inside the group stays in the product boundary; personal memory stays elsewhere.
Billing / cost attribution by project
Create Billing-Acme or Project-Q3-Launch. Put only the seats you intend to charge (or track) for that work into the group. Activate that group for the duration of the engagement so context and membership match the invoice line. Groups do not invent Anthropic invoices; they give you a durable local boundary so you stop mixing personas while you work.
Labels without isolation
Create a group for convenience and set isolation global, or use tags for multi-label classification without a hard memory boundary.
Daily workflow (keep personas honest)
- Start the day → Use
Work(or your main client group). - Open work repos and run Claude Code as usual.
- After hours / side project → Use
Personal. - Client call / different monorepo → Use that client group first.
- End of day → Clear active group if you want a neutral machine state.
Optional automation:
# example: direnv or shell function per repo
pc scope use <work-id> # in work repo .envrc
pc scope use <personal-id>Dashboard drag-and-drop and pc scope write the same store (account-scopes.json). Neither is a shadow UI.
Troubleshooting
| Symptom | Check |
|---|---|
| Context still mixed | Isolation = isolated; you clicked Use this group after creating it |
| Wrong account feels “active” | Confirm membership with pc scope list; move stragglers with pc scope move |
| Layout apply failed | Non-empty real projects dir can fail closed — see product docs / applyScopeLayout |
| Groups missing in UI | Update Power Claude; reload window |
| Drag does nothing | Reload dashboard; fall back to pc scope add |
| Expected double quotas | Groups organize seats and local memory; they do not multiply Anthropic limits |
Compliance (authoritative)
- Public Power Claude uses official-cli for subscription traffic.
- Groups do not claim Max pooling, silent multi-account thrash past limits, or ToS evasion.
- On usage limits: pause/notify and official capacity options — not “bypass.”
- See Does Power Claude violate Anthropic’s ToS?
Primary sources
- Anthropic Claude Code multi-profile discussion: anthropics/claude-code#261 (
CLAUDE_CONFIG_DIR/ config separation). - Architecture field guide (A vs B): DEV — two multi-account Claude Code architectures.
- Product behavior: Power Claude feature doc
account-scopes(CLIpc scope, state under~/.power-claude/).
Frequently asked questions
How do I separate work and personal Claude accounts?
Create two isolated groups named Work and Personal, put each login in the right group, and select Use this group when you switch roles. Full walkthrough: separate work and personal.
Can I group any Claude accounts and name the group anything?
Yes. + New group → choose any free-form name → drag any linked accounts onto that group. Names are not restricted to Work/Personal; clients, projects, and sandbox labels all work.
How many groups can I create?
As many as you need (work, personal, per-client, per-project, sandbox). Prefer one group per persona or billing boundary.
Can one account sit in two groups?
No — single membership keeps isolation unambiguous. Use tags for multi-label without dual isolation.
Do groups share passwords or OAuth?
No. Each account keeps its own credentials. Groups never copy login secrets.
Will creating a group delete old sessions?
No. Isolation re-homes where context is rooted; it does not wipe disk history. Layout apply fails closed if a non-empty tree would be clobbered.
Does this bypass rate limits?
No. Limits stay per Anthropic account/plan. Groups organize seats and local memory.
What is the active group?
The group you selected as current persona. New work is framed by that membership and (if isolated) that memory tree.
Where is state stored?
~/.power-claude/state/account-scopes.json (permissions 0600). Do not commit work emails to public repos.
CLI vs dashboard — which is authoritative?
Same store. Dashboard drag-and-drop and pc scope both update account-scopes.json.
How do I clear the active group?
Dashboard Clear active group or pc scope use none.
How do I keep only work seats in the work set?
Put only work emails in Work. Leave personal in Personal or Ungrouped. Use pc scope move if something landed wrong.
Can I use groups for project billing boundaries?
Yes as a local organization tool: name a group per project or client, put the seats you use for that work inside it, and activate it while you are on that engagement. That keeps context and membership aligned; it does not replace Anthropic billing.
Related: usage limits while switching groups?
Isolation does not multiply quotas. For token hygiene see stop hitting Claude usage limits.
Is this the same as CLAUDE_CONFIG_DIR profiles?
Related but different. Config dirs separate logins. Groups separate persona + local projects/memory and the active set. Use both for a clean Architecture B setup.
How is this different from a normal multi-account rotator?
A flat rotator usually treats every linked seat as one global pool. Account groups let you name a set for Work, Job A, or Client B, put only those seats in it, pool within that set, activate it for the engagement, and isolate memory so other jobs do not inherit that context. Dual config dirs alone do not give you named engagement pools.
How do I rename a group?
Prefer a stable name from day one. If the UI does not expose rename, create the correctly named group, move members with drag or pc scope move, then delete the old empty group. Keep a backup of account-scopes.json.
Setup checklist
- Link every Claude account you use on this machine.
- Create named groups for real personas (Work / Personal / clients / projects).
- Leave isolation on unless you intentionally want shared memory.
- Drag any accounts into the right groups.
- Use this group before deep work.
- Switch groups when you switch roles.
- Optional:
pc scope use <id>in direnv/shell aliases per repo.
Related reading
- Two Claude accounts on Mac
- Separate work and personal Claude accounts (how-to)
- Account groups docs
- Multi-account architectures A vs B
- How Power Claude’s account rotator works
- Install · Downloads · Product #feature-account-groups
Closing
Multi-account Claude is normal. What was missing was a first-class way to say: these seats are one job, that seat is another life — name them, group any of them, and keep their memories apart. Power Claude account groups are that control surface: drag-and-drop for daily use, pc scope for automation, isolated projects trees when you need a hard boundary.
Try Power Claude: 14-day Premium trial · free install / download · account groups on the product page.
Independent third-party software. Not affiliated with Anthropic.