Mai multe conturi Claude Code pe un singur dispozitiv

Folosesc Claude Code zilnic — și pentru proiecte personale, și pentru munca de la firmă. Problema: sunt două conturi complet diferite, cu sesiuni OAuth diferite, instrucțiuni CLAUDE.md diferite, servere MCP diferite și memorie de proiect separată. Iată cum le rulez în paralel pe același dispozitiv cu un singur alias de shell pe o linie.

Problema

În mod implicit, Claude Code stochează totul în ~/.claude — tokenul OAuth, istoricul conversațiilor, fișierul global CLAUDE.md, memoria proiectelor, configurările serverelor MCP și setările. Când ai două conturi, ai nevoie de două lumi complet separate:

• Contul personal: abonamentul tău Max/Pro, un CLAUDE.md personal cu preferințele tale, serverele tale MCP (Obsidian, unelte personale)
• Contul corporativ: planul gestionat de companie, un CLAUDE.md de lucru cu instrucțiuni de integrare Jira/Slack, serverele MCP ale companiei
• Sesiuni OAuth diferite: nu poți fi autentificat pe două conturi în același director de configurare
• Memorie de proiect separată: nu vrei ca contextul proiectelor de la muncă să se scurgă în sesiunile personale și invers

Să te deconectezi și să te reconectezi de fiecare dată când schimbi contextul nu e o opțiune. Pierzi starea sesiunii, iar procesul e pur și simplu enervant.

Soluția: CLAUDE_CONFIG_DIR

Claude Code respectă o singură variabilă de mediu: CLAUDE_CONFIG_DIR. Setează-o pe orice cale, iar Claude va folosi acel director în locul lui ~/.claude pentru tot — autentificare, istoric, setări, memorie, absolut tot. Întreaga configurare durează 60 de secunde.

Pasul 1: Creează un al doilea director de configurare

Alege un nume care are sens pentru cazul tău de utilizare:

mkdir ~/.claude-work

Atât. Claude îl va popula cu structura necesară la prima pornire.

Pasul 2: Autentifică al doilea cont

Rulează Claude o dată cu noul director de configurare pentru a declanșa autentificarea OAuth:

CLAUDE_CONFIG_DIR=~/.claude-work claude

Se deschide browserul. Autentifică-te cu contul corporativ. Tokenul OAuth se salvează în ~/.claude-work — complet separat de sesiunea ta personală din ~/.claude.

Pasul 3: Adaugă un alias de shell

Adaugă asta în configurarea shell-ului ca să nu fii nevoit să ții minte variabila:

alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

Reîncarcă shell-ul:

source ~/.zshrc

Ce obții

Acum ai două medii Claude complet izolate:

• claude — pornește cu contul personal, CLAUDE.md-ul personal, memoria personală
• claude-work — pornește cu contul corporativ, CLAUDE.md-ul de lucru, memorie separată
• Istoric izolat: conversațiile de la muncă rămân la muncă, cele personale rămân personale
• Servere MCP separate: MCP-ul personal pentru vault-ul tău Obsidian nu apare în sesiunile de lucru
• Setări independente: unelte permise diferite, niveluri de permisiuni diferite, preferințe de model diferite pentru fiecare cont

Cum funcționează în culise

Directorul de configurare este sursa unică de adevăr pentru starea lui Claude Code. Iată ce se află înăuntrul fiecăruia:

~/.claude/              ← personal account
├── CLAUDE.md           ← personal global instructions
├── projects/           ← personal project memory
├── settings.json       ← personal permissions & MCP servers
└── ...                 ← OAuth session, history, cache

~/.claude-work/         ← corporate account
├── CLAUDE.md           ← company-specific instructions (Jira, Slack, etc.)
├── projects/           ← separate project memory
├── settings.json       ← different MCP servers, permissions
└── ...                 ← separate OAuth session

Când rulezi claude-work, Claude citește totul din ~/.claude-work. Habar nu are că ~/.claude există. Cele două instanțe sunt complet independente — le poți rula chiar simultan în file diferite ale terminalului.

Scalarea la N conturi

Modelul se extinde la orice număr de conturi. Ești freelancer cu mai mulți clienți? Adaugă mai multe alias-uri:

# Personal (default — no alias needed)
# Just run: claude

# Corporate
alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

# Freelance client
alias claude-client='CLAUDE_CONFIG_DIR=~/.claude-client claude'

Fiecare alias primește propriul director de configurare, propria sesiune OAuth, propriul CLAUDE.md cu instrucțiuni specifice clientului. Poți avea un CLAUDE.md pentru Clientul A care cunoaște convențiile codului și proiectul lui Jira și unul complet diferit pentru Clientul B.

Sfaturi practice

• Numește directoarele clar: ~/.claude-work, ~/.claude-clientname — o să-ți mulțumești singur când ai trei sau patru
• Scrie un CLAUDE.md croit pentru fiecare: cel de lucru poate include instrucțiuni specifice companiei (cum se creează tichete Jira, ce canale Slack să referențieze, proceduri de deployment). Cel personal rămâne suplu.
• Servere MCP diferite pentru fiecare cont: configurează uneltele de lucru (Jira MCP, Slack MCP, API-uri interne) doar în configurarea de lucru. Ține-o pe cea personală curată.
• Verifică ce cont e activ: rulează claude config list într-o sesiune dacă nu ești sigur pe ce cont ești — îți arată calea directorului de configurare

Unde această abordare dă greș

CLAUDE_CONFIG_DIR izolează pe cont, nu pe proiect. În interiorul unui singur profil, Claude vede fiecare server MCP pe care l-ai înregistrat vreodată pentru acel cont — din toate proiectele tale. Pentru uz personal solo, de obicei e în regulă. În momentul în care ai mai multe proiecte critice pentru producție sub un singur cont, mai ales în domenii care se suprapun precum facturarea, uneltele de administrare sau infrastructura, apare un risc concret între proiecte: un asistent AI poate apela o unealtă din proiectul A în timp ce lucrează la proiectul B, mai ales când ambele expun operațiuni cu nume asemănătoare.

Modelul cu profile răspunde la întrebarea pe ce cont sunt?. Nu răspunde la întrebarea uneltele cărui proiect ar trebui să fie active acum?. Pentru munca cu miză mai mare, adaugă un al doilea strat de izolare peste separarea pe conturi:

• Un profil per proiect critic pentru producție, nu doar per cont: în loc de ~/.claude și ~/.claude-work, creează ~/.claude-work-billing și ~/.claude-work-admin. Fiecare profil vede doar serverele MCP de care are realmente nevoie.
• MCP la nivel de proiect prin .mcp.json: comite un .mcp.json în rădăcina proiectului care listează doar serverele MCP ale acelui proiect. Claude le preia când e pornit din acel director. Ține-ți configurarea globală minimală — doar unelte universale (notițe, căutare), niciun endpoint de producție.
• Numește serverele MCP fără ambiguitate: evită nume generice precum admin, billing, mcp-server. Prefixează cu numele proiectului: acme_billing_prod, acme_admin_stage. Un nume descriptiv te obligă la o pauză când ceva e pe cale să fie apelat din contextul greșit.
• Verifică fiecare apel de unealtă MCP înainte să-l aprobi: apeluri precum *_create_*, *_delete_*, *_charge_* merită o a doua privire deliberată. Orice viteză câștigi din auto-aprobarea în bloc se evaporă prima dată când o unealtă din proiectul greșit trage în producție.

Regula generală: împarte profilurile agresiv, ține MCP-urile de nivel producție în afara profilului implicit și tratează suprapunerea numelor de unelte între proiecte ca pe un semnal că merită refactorizat.

Concluzie

O singură variabilă de mediu. Un singur alias. Izolare completă între conturi. Fără dansul logout/login, fără conflicte de configurare, fără scurgeri de context. E genul de soluție aproape dezamăgitor de simplă — dar tocmai asta o face bună. Configureaz-o o dată și nu te mai gândi niciodată la ea.