Claude Code Multi-Account: Official Profiles vs Relay Servers

Power Claude runs the safe, allowed multi-account route: Architecture B — the official Claude Code client with separate CLAUDE_CONFIG_DIR profiles — not a subscription OAuth relay. This guide contrasts Architecture B with Architecture A (relay servers), cites public sources, and maps how Power Claude’s official-cli transport implements the Option B pattern from anthropics/claude-code#261, plus account groups for work/personal isolation.

TL;DR (featured-snippet style)

Question	Short answer
Safe multi-account Claude Code?	Prefer Architecture B: real claude + one CLAUDE_CONFIG_DIR per login (issue #261).
Risky pattern?	Architecture A: relay server holding many subscription OAuth tokens and impersonating the client (DEV A vs B).
How does Power Claude do it?	Public default official-cli: launch official Claude Code, profiles = config dirs, no PC-owned Anthropic subscription proxy; optional account groups isolate memory.
Anthropic endorsement of Power Claude?	No claim. Independent third-party software; we cite public docs/issues only.

Primary sources to verify yourself:

1. DEV: Two multi-account architectures (A vs B)
2. GitHub: anthropics/claude-code#261 (Option B / multi-config-dir workflow; closed as completed)
3. Anthropic env vars: CLAUDE_CONFIG_DIR

Claude Code multi-account: why the architecture choice matters

Search demand is real: claude code multiple accounts, switch Claude work personal, CLAUDE_CONFIG_DIR, claude relay, is multi-account against ToS.

From the outside those queries look identical. On the wire they are not.

• Architecture B = N times the official Claude Code client, each with its own config directory and login.
• Architecture A = one unofficial relay that stores many OAuth tokens and answers as if it were Anthropic’s client.

The DEV Community article frames this as the difference between a pattern Anthropic’s own issue tracker has closed around config-dir workflows and a pattern associated with ban waves against relay/gray-market traffic. Read their full argument here:

Two Multi-Account Claude Code Architectures: One Anthropic Accepts, One They Ban (DEV)

We use that A/B vocabulary below and add the Power Claude safety mapping.

Architecture A: Claude subscription relay / OAuth proxy (high risk)

What Architecture A is

A middle server:

• Collects many Claude subscription OAuth tokens
• Exposes an Anthropic-compatible API to tools
• Load-balances or rotates tokens server-side
• Is not the official Claude Code binary on the path to Anthropic for those calls

Community and commercial “pooled Claude” / “relay station” products often share this relay-server pattern. The DEV article catalogs open-source and commercial examples in that family (educational context, not a recommendation).

Why it is treated differently by vendors

From Anthropic’s perspective (as argued in the DEV architecture piece):

• Traffic is not “N normal Claude Code installs”
• It is “one control plane, many tokens, non-official client behavior”
• Telemetry and client fingerprinting the real binary would emit may not match
• High-volume relay patterns have been the subject of enforcement narratives (e.g. widely discussed OpenClaw-related coverage)

Power Claude safety rule on Architecture A

Power Claude’s public product does not default to Architecture A.

In official-cli mode Power Claude:

• Does not set ANTHROPIC_BASE_URL to a Power Claude listener for subscription OAuth
• Does not store, parse, copy, or refresh Claude access/refresh tokens as the public transport
• Does not market “silent subscription OAuth pooling behind a fake Anthropic endpoint”

If something holds subscription OAuth and impersonates Claude Code, that is not the Power Claude public architecture.

Architecture B: official Claude Code + CLAUDE_CONFIG_DIR (Option B)

What Architecture B is

Each subscription is a separate config directory. You always run the real claude binary:

# Architecture B / Option B pattern (official client per profile)
mkdir -p ~/.claude-work ~/.claude-personal

# Login each profile once (interactive /login as Anthropic requires)
CLAUDE_CONFIG_DIR=~/.claude-work claude
CLAUDE_CONFIG_DIR=~/.claude-personal claude

# Day-to-day aliases
alias claude-work="CLAUDE_CONFIG_DIR=~/.claude-work claude"
alias claude-personal="CLAUDE_CONFIG_DIR=~/.claude-personal claude"

Each directory is its own credential store, history, and settings. No relay impersonates the client.

Primary source for Option B: GitHub issue #261

Anthropic’s public tracker:

anthropics/claude-code#261 — multi-account / config directory discussion, closed as completed (March 2025).

That issue is the community’s citation for “Option B”: isolate accounts with separate directories and the official CLI. Pair it with Anthropic’s own docs:

Environment variables: CLAUDE_CONFIG_DIR

Together they define the documented isolation primitive for multi-account Claude Code without a middleman API.

What Anthropic sees under Architecture B

• N separate official-client processes
• Each authenticated via the normal login flow
• Each identifying as Claude Code
• Orchestration (which profile to launch next) happens outside Anthropic’s request path

That is the core of the DEV article’s “what the vendor sees” section: B is N clients; A is one impersonator. See again: DEV A vs B.

Architecture A vs B comparison table (SEO + operators)

Dimension	Architecture A (relay)	Architecture B (Option B / CLAUDE_CONFIG_DIR)
Who speaks to Anthropic	Relay / proxy	Official claude binary
OAuth location	Often pooled server-side	Per config directory
Client identity	Impersonation risk	Real Claude Code
Documented primitive	N/A (wrong layer)	CLAUDE_CONFIG_DIR + issue #261
Field guide	DEV article	Same + env-vars docs
Power Claude public default	No	Yes (family)

How Power Claude implements Architecture B safely

Power Claude is independent third-party software and is not affiliated with, endorsed by, or certified by Anthropic. The points below describe product design, not a legal opinion.

Safety pillars (checklist)

1. Official Claude Code owns the wire Subscription traffic is intended to go through the real Claude Code executable, not a Power Claude Anthropic request proxy (official-cli).

1. One profile = one CLAUDE_CONFIG_DIR Same Option B primitive as issue #261: credentials and login state stay per directory.

1. No public subscription OAuth token harvesting Power Claude does not treat “read/copy/refresh Claude OAuth tokens” as a public transport feature for official-cli.

1. No public ANTHROPIC_BASE_URL → Power Claude for subscription OAuth Official mode refuses to inject a local PC proxy base URL for that path.

1. Account groups for isolation without becoming a relay Account groups partition membership + local projects/memory trees (Work / Personal / client). They do not create a multi-tenant OAuth relay.

1. Explicit active group You choose which group is active (pc scope use or dashboard Use this group) so switching is deliberate.

1. Transparent non-affiliation Marketing and legal surfaces state independence from Anthropic; we cite public issues and docs instead of claiming special approval.

Mapping DEV “Architecture B” → Power Claude features

Architecture B idea	Power Claude surface
Separate config dirs	Profiles with CLAUDE_CONFIG_DIR
Official binary	official-cli transport launches real claude
Shell aliases / small router	Dashboard + pc scope / profile selection
Failover / selection outside Anthropic	Local supervision, recovery, group selection (not OAuth proxy flip)
Work vs personal isolation	Account groups isolated projects trees

What “safe” does not mean here

• Not “guaranteed ban-proof forever”
• Not “Anthropic accepts Power Claude”
• Not “bypass rate limits” or “turn five Pro into Max”
• Not Architecture A on localhost

“Safe” in this article means: aligned with the official-client + config-dir pattern described in public Anthropic docs/issues and the DEV Architecture B writeup, with product controls that refuse the subscription-OAuth-relay pattern as the public default.

Practical setup: Architecture B with Power Claude

Minimal Option B without Power Claude

export CLAUDE_CONFIG_DIR=~/.claude-work && claude   # /login
export CLAUDE_CONFIG_DIR=~/.claude-personal && claude

Option B + Power Claude profiles and groups

1. Install Power Claude (install docs).
2. Link each subscription under its own profile (official login under that config dir).
3. Create groups Work / Personal / Client (account groups how-to).
4. Leave isolation on so projects/memory do not mix.
5. Use this group or pc scope use <id> when switching roles.
6. Keep transport on official-cli for subscription work.

Deep dive on groups: Power Claude account groups: isolate work, personal, and client context.

Search-intent FAQ (long-tail SEO)

What is the safe way to use multiple Claude Code accounts?

Use Architecture B: the official claude binary with a separate CLAUDE_CONFIG_DIR per login, as discussed in claude-code#261 and the DEV A vs B article. Power Claude’s official-cli path is built around that family.

What is CLAUDE_CONFIG_DIR for multi-account Claude Code?

It points Claude Code at an isolated config home (credentials, settings, session state). One directory per subscription is the Option B multi-account primitive. See Anthropic’s env vars documentation.

What is Architecture A vs Architecture B for Claude multi-account?

Per the DEV Community guide: A = relay/OAuth pool pretending to be the client; B = N official clients with separate config dirs.

Is a “Claude relay service” the same as Power Claude?

No. A classic subscription relay is Architecture A. Power Claude public default is Architecture B-style official client orchestration, not a multi-tenant OAuth Anthropic impersonator.

How does Power Claude keep multi-account use safer?

Official Claude Code on the network path for subscription mode, per-profile config directories, no public subscription OAuth proxy injection, and optional account groups that isolate local context without pooling OAuth on a relay.

Does Power Claude claim Anthropic approval?

No. We are independent third-party software. We reference public docs and issue #261; we do not claim endorsement or certification.

Can I still isolate work and personal memory?

Yes. Architecture B separates credentials per directory; Power Claude account groups add isolated projects/memory trees and an active group selector on top.

Where do I read the original A vs B analysis?

DEV: Two Multi-Account Claude Code Architectures… and the Option B discussion in anthropics/claude-code#261.

Related reading (internal + external)

External (cite / dofollow where policy allows; we use noopener noreferrer)

• DEV: One architecture Anthropic accepts, one they ban
• GitHub anthropics/claude-code#261
• Claude Code env vars (CLAUDE_CONFIG_DIR)

Internal

• Account groups deep dive
• Account groups setup docs
• Install Power Claude
• Downloads

Closing

Claude Code multi-account is not one product feature; it is an architecture decision. Architecture A (subscription OAuth relay) and Architecture B (CLAUDE_CONFIG_DIR official profiles, Option B in issue #261) look similar in a one-line pitch and nothing alike on the network path. The DEV field guide names that split; Power Claude’s public design chooses the official-client family, then adds account groups so work and personal context stay isolated without becoming a relay.

Independent third-party software. Not affiliated with Anthropic. “Claude” and “Claude Code” are Anthropic trademarks used for identification only.

Power Claude product modes (2026-07-14)

Power Claude defaults to manual multi-account. Optional Auto-Rotation Engine is classic automatic rotation with an OAuth boundary and use-at-own-risk warning — see product docs/product/rotation-modes.md.