Claude Code mantiene un solo accesso alla volta. Ecco come farne convivere diversi.

Guida sul campo per far convivere un account di lavoro e uno personale sulla stessa macchina: l'unica variabile d'ambiente che decide quale accesso è attivo, perché il metodo via shell si rompe appena hai più di due terminali aperti, e come fissare un account per progetto.

C'è un momento che capita a quasi tutti quelli che usano Claude Code sia per lavoro sia per i propri progetti. Chiudi una sessione di lavoro, passi a un progetto personale e ti accorgi che l'agente è ancora connesso con l'account che paga il tuo datore di lavoro. Allora esci, rientri con il tuo account, e mezz'ora dopo devi rifare l'operazione al contrario.

Questo giro non è una funzionalità mancante. È la conseguenza di dove Claude Code conserva il suo accesso, e una volta che sai dove lo tiene, far convivere più account diventa un dettaglio di configurazione invece che un problema di metodo di lavoro.

Una sola variabile d'ambiente decide quale account è attivo

Claude Code non ha profili. Lega tutto a una sola cartella: i metadati di sessione, la cronologia per progetto e l'accesso. Su Linux e Windows l'accesso è un file .credentials.json in quella cartella; su macOS è un elemento del portachiavi il cui nome deriva dal percorso della cartella, quindi è sempre la cartella a decidere quale account usi.

Quella cartella è quella indicata da CLAUDE_CONFIG_DIR. Se non imposti mai la variabile, è ~/.claude.

Schema di come Claude Code determina l'account attivo: la variabile d'ambiente CLAUDE_CONFIG_DIR punta a una cartella che contiene credentials.json, i metadati di sessione e la cronologia dei progetti, con ~/.claude come valore predefinito quando la variabile non è impostata.

Il meccanismo è tutto qui, e ha una proprietà utile: siccome un account è una cartella e non un'impostazione globale, avere due account significa avere due cartelle. Le due non condividono niente. Restano entrambe connesse a tempo indeterminato, e nessuna delle due sa che l'altra esiste.

Quindi la versione ingenua funziona:

# personale
CLAUDE_CONFIG_DIR=~/.claude claude

# lavoro
CLAUDE_CONFIG_DIR=~/.claude-work claude

Esegui /login una volta dentro la seconda, e hai due account attivi su una sola macchina.

Dove il metodo via shell inizia a fare male

La versione in due righe qui sopra va benissimo se apri un terminale alla volta e sei disciplinato. Smette di andare bene per tre motivi, e i tre si sommano.

La variabile vale per processo, non per macchina. Ogni nuovo terminale, ogni nuovo pannello, ogni shell integrata nell'editor riparte dal valore predefinito del tuo profilo. Esportala nel .zshrc e avrai soltanto spostato il problema: adesso è l'altro account quello che dimentichi in continuazione.

Niente sullo schermo ti dice quale account è attivo. Claude Code non stampa l'account nel suo prompt. Puoi chiederlo, con claude auth status --text (mostra il metodo di accesso, l'organizzazione e l'email della cartella indicata dalla shell corrente), ma nessuno lo esegue prima di ogni prompt. Se hai due terminali aperti e uno gira sull'account di lavoro, a occhio sono identici. Il momento in cui te ne accorgi di solito è quello in cui guardi la fattura.

Non regge il parallelismo. Le configurazioni interessanti fanno girare più agenti insieme, su più progetti. Superate le due sessioni simultanee, ricordarsi quale pannello è stato avviato con quale variabile non è più un problema di disciplina, è un problema di progettazione.

Schema di confronto: a sinistra, la scelta dell'account Claude Code tramite export di CLAUDE_CONFIG_DIR in ogni terminale, dove un terzo terminale non dà nessuna indicazione visibile di quale account sia attivo. A destra, l'account collegato al progetto con un override per agente, risolto automaticamente all'avvio dell'agente.

La soluzione non è altra shell. È smettere di prendere la decisione al momento del lancio e collegare l'account a ciò che davvero lo determina: il progetto.

Collega l'account al progetto, non al terminale

Quello che vuoi, di solito, è una regola e non un comando. Qualcosa tipo: il repository di questo cliente gira sempre sull'account di questo cliente. Una volta che la regola esiste, nessuno deve più ricordarsi niente.

Farlo per bene significa risolvere l'account secondo un ordine definito, perché la regola ha bisogno di eccezioni. Un valore predefinito a livello di progetto va bene quasi sempre, ma un agente specifico può dover girare altrove: un esperimento usa e getta su un account di test, o un agente di revisione su una licenza con una quota più ampia.

Schema dell'ordine di risoluzione dell'account su quattro livelli: l'override a livello di agente ha la precedenza sul pin del progetto, che ha la precedenza sul valore predefinito dell'applicazione, che ricade sulla cartella di sistema predefinita ~/.claude.

Si legge dall'alto verso il basso, e vince la prima regola che corrisponde. Un override di agente batte il pin del progetto. Il pin del progetto batte qualsiasi valore tu abbia impostato come predefinito generale. Se non è configurato niente da nessuna parte, ricadi su ~/.claude, cioè esattamente quello che fa già un'installazione appena fatta. Quest'ultimo ripiego conta: significa che aggiungere questo meccanismo a una configurazione esistente non cambia nulla finché non fissi qualcosa esplicitamente.

È il modello implementato da AgentsRoom. Ogni account è una cartella gestita, l'accesso avviene dentro l'app invece che in una shell, e la risoluzione descritta sopra viene eseguita all'avvio di un agente, impostando CLAUDE_CONFIG_DIR solo su quel processo. Se usi già uno switcher di terze parti come CCS, puoi puntare un account su una cartella di profilo esistente invece di rifare l'accesso.

Lo stesso problema esiste su Codex, con un'altra variabile

Se usi più di un provider, ci sbatterai contro due volte. La forma è identica, la variabile no, quindi uno switcher costruito per uno dei due non copre l'altro. Il versante Codex lo documentiamo a parte in multi-account per Codex, incluso ciò che cambia nella procedura di accesso.

Il punto generale vale la pena dirlo una volta: l'isolamento degli account è un meccanismo specifico di ogni provider. Qualsiasi strumento che dichiari di gestirlo in modo globale o sta incapsulando ogni provider uno per uno, o ne supporta uno solo.

Sapere quale account sta davvero consumando token

Separare gli account è solo metà del motivo per cui si fa tutto questo. L'altra metà è sapere dove finisce il consumo, soprattutto quando a pagare è un cliente.

È la parte che si rompe silenziosamente con il metodo via shell. Un lettore di consumo che guarda solo ~/.claude sottostima i numeri nel momento stesso in cui un agente gira altrove, e i totali restano abbastanza plausibili perché nessuno se ne accorga per settimane. Un lettore consapevole degli account deve scorrere tutte le cartelle configurate, non solo quella predefinita.

Se vuoi i numeri per account e per sessione, abbiamo trattato il lato misurazione in come controllare l'uso dei token di Claude Code, e la vista in tempo reale si trova sulla pagina dedicata all'uso dei token.

A cosa non serve tutto questo

Una precisazione, perché la domanda torna e merita una risposta netta invece del silenzio.

Tutto quello che precede riguarda la separazione di account che esistono già legittimamente. Una licenza pagata dal tuo datore di lavoro e un abbonamento personale che paghi tu sono due rapporti commerciali diversi, e tenerli sulla stessa macchina senza contaminazione incrociata è un'esigenza reale e ordinaria. Lo stesso vale per addebitare a un cliente i token di quel cliente, e per tenere un account sperimentale lontano da uno di produzione.

Creare account aggiuntivi per aggirare i limiti di capacità del piano che hai sottoscritto è un'altra cosa, ed è esattamente ciò a cui puntano le politiche di utilizzo. Il meccanismo descritto qui non rende accettabile quella pratica, e uno strumento che la automatizzasse ti starebbe aiutando a violare un contratto che hai firmato. Se il tuo secondo account esiste perché lo paga qualcun altro, sei su un terreno solido. Se esiste per azzerare un rate limit, no. Fanno fede le politiche di utilizzo di Anthropic, non questo articolo.

Le domande che si fanno davvero

Posso usare due account Claude Code sullo stesso computer?

Sì. Claude Code lega il suo accesso, i metadati di sessione e la cronologia dei progetti alla cartella indicata da CLAUDE_CONFIG_DIR, che per impostazione predefinita è ~/.claude. Fai puntare quella variabile a una seconda cartella, accedi lì dentro, e hai due account indipendenti sulla stessa macchina. Le due cartelle non condividono niente, quindi entrambi gli account restano connessi nello stesso momento.

Come cambio account Claude Code senza disconnettermi?

Non ti disconnetti affatto. Uscire e rientrare riutilizza la stessa cartella, quindi perdi la prima sessione per ottenere la seconda. Al suo posto, dai a ogni account la sua cartella di configurazione e scegli tra le due impostando CLAUDE_CONFIG_DIR quando avvii la CLI. Entrambe le credenziali restano valide sul disco, e cambiare account non costa nulla.

Dove salva Claude Code i dati di accesso?

Dipende dal sistema, ma è sempre legato alla cartella indicata da CLAUDE_CONFIG_DIR, che è ~/.claude finché non la cambi. Su Linux e Windows le credenziali finiscono in un file .credentials.json dentro quella cartella, accanto ai metadati di sessione e alla cronologia per progetto. Su macOS vanno invece nel portachiavi login, in un elemento il cui nome deriva da quella cartella: Claude Code-credentials per ~/.claude, Claude Code-credentials- seguito da otto caratteri esadecimali per qualsiasi altra cartella. In entrambi i casi, una cartella corrisponde a un account, ed è ciò che rende la sua sostituzione un cambio pulito e non un trucco.

Due agenti possono girare su due account Claude diversi contemporaneamente?

Sì, a patto che ogni processo agente riceva il proprio CLAUDE_CONFIG_DIR nel suo ambiente. La variabile viene letta per processo all'avvio, non a livello globale, quindi due agenti avviati con due valori diversi girano su due account diversi in parallelo. È questo che rende utilizzabili un progetto di lavoro e uno personale nella stessa finestra.

Come faccio a sapere con quale account è connesso Claude Code?

Esegui claude auth status --text in un terminale. Mostra il metodo di accesso, l'organizzazione e l'email dell'account, per la cartella indicata da CLAUDE_CONFIG_DIR in quella shell (verificato su Claude Code 2.1.299; senza --text le stesse informazioni escono in JSON, insieme al piano e alla cartella di configurazione). Per verificare un secondo account, metti la variabile davanti al comando: CLAUDE_CONFIG_DIR=~/.claude-work claude auth status --text. Se risponde Not logged in, in quella cartella non ha ancora effettuato l'accesso nessuno, oppure l'account lì è stato disconnesso.

Avere più di un account Claude viola i termini di Anthropic?

Avere account distinti per scopi distinti è normale: una licenza pagata dal tuo datore di lavoro e un abbonamento personale che paghi tu sono due rapporti commerciali diversi. Ciò a cui puntano le politiche di utilizzo è la creazione di account per aggirare i limiti di capacità del piano che hai sottoscritto. Se il tuo secondo account esiste perché lo paga qualcun altro, sei su un terreno solido. Se esiste per azzerare un rate limit, no. Fanno fede le politiche di utilizzo di Anthropic.

In breve

Claude Code memorizza un account sotto forma di cartella, e CLAUDE_CONFIG_DIR decide quale è attiva. Due cartelle significano due account, connessi in permanenza, senza niente in comune tra loro.

La versione via shell di tutto questo funziona finché non hai più di un terminale aperto. Dopodiché, quello che vuoi è che l'account diventi una proprietà del progetto, con un override per agente per le eccezioni, così che le credenziali giuste vengano collegate all'avvio e nessuno debba più ricordarsi niente.

Ingegnere DevOpsCopywriterSviluppatore FrontendCommercialeSviluppatore BackendCoach e FormatoreArchitetto SoftwareConsulente LegaleIngegnere QAAmministrazione e FinanzaSviluppatore Full-StackDesigner CreativoSviluppatore MobileRicercatoreIngegnere di SicurezzaRisorse Umane e Selezione
Project ManagerTraduttoreEsperto GitData AnalystSpecialista SEOContabileSpecialista LocalizzazioneComunicazione e PRBrainstormerOperations e LogisticaSpecialista MarketingAssistenza ClientiAssistente del progettoBuyerCommunity ManagerAssistente Personale

Scarica AgentsRoom

Esegui tutti i tuoi agenti AI, su tutti i tuoi progetti, da una sola finestra.

Scarica AgentsRoomGratis

App companion: monitora i tuoi agenti in movimento

Usa Claude, Codex, Antigravity CLI o un altro provider IA.

Installa l'estensione
Chrome Web Store

Invia bug e richieste direttamente nel tuo backlog pubblico.

Agenti che leggi come una conversazione

Ogni agente ha un ruolo, una faccia e un thread che leggi come un'app di messaggistica.

Vista conversazione

Vista conversazione di AgentsRoom: il lavoro di un agente AI di coding mostrato come chat
Multi-progetto
Multi-provider
Multi-agente
Stato in tempo reale
Diff e commit
App mobile
Anteprima live
Team di agenti
Test browser
Dev guidata da backlog
Libreria di prompt
Libreria di skill
Vedi tutte le funzionalità

Continua a leggere