Claude Code ne retient qu'une session à la fois. Voici comment en faire tourner plusieurs.

Il y a un moment que connaissent la plupart des gens qui utilisent Claude Code à la fois pour leur travail et pour leurs projets personnels. Vous terminez une session pro, vous basculez sur un projet perso, et vous réalisez que l'agent est toujours connecté sur le compte que paie votre employeur. Alors vous vous déconnectez, vous vous reconnectez avec votre propre compte, et une demi-heure plus tard il faut refaire l'opération en sens inverse.

Cette boucle n'est pas une fonctionnalité manquante. C'est une conséquence de l'endroit où Claude Code range sa session. Et une fois qu'on sait où il la range, faire cohabiter plusieurs comptes devient un détail de configuration plutôt qu'un problème de méthode de travail.

Une seule variable d'environnement décide du compte actif

Claude Code ne conserve pas ses identifiants dans une base de données ni dans une entrée de trousseau indexée par profil. Il lit tout ce dont il a besoin dans un seul répertoire : identifiants, métadonnées de session et historique par projet.

Ce répertoire est celui que désigne CLAUDE_CONFIG_DIR. Si vous ne définissez jamais cette variable, c'est ~/.claude.

C'est tout le mécanisme, et il a une propriété utile : parce qu'un compte est un répertoire et non un réglage global, avoir deux comptes revient à avoir deux répertoires. Rien n'est partagé entre eux. Les deux restent connectés indéfiniment, et aucun ne sait que l'autre existe.

La version naïve fonctionne donc :

# perso
CLAUDE_CONFIG_DIR=~/.claude claude

# pro
CLAUDE_CONFIG_DIR=~/.claude-work claude

Lancez /login une fois dans le second, et vous avez deux comptes actifs sur une seule machine.

Là où la méthode par le shell commence à faire mal

La version en deux lignes ci-dessus convient très bien si vous n'ouvrez qu'un terminal à la fois et que vous êtes discipliné. Elle cesse de convenir pour trois raisons, et elles se cumulent.

La variable vaut par processus, pas par machine. Chaque nouveau terminal, chaque nouveau panneau, chaque shell intégré à l'éditeur repart de la valeur par défaut de votre profil. Exportez-la dans votre .zshrc et vous n'avez fait que déplacer le problème : c'est désormais l'autre compte que vous oubliez en permanence.

Rien ne vous indique quel compte est actif. Claude Code n'affiche pas le compte dans son invite. Si vous avez deux terminaux ouverts et que l'un tourne sur le compte pro, ils sont identiques à l'œil. Le moment où vous le remarquez est en général celui où vous regardez la facture.

Ça ne survit pas au parallélisme. Les configurations intéressantes font tourner plusieurs agents à la fois, sur plusieurs projets. Passé deux sessions simultanées, se souvenir de quel panneau a été lancé avec quelle variable n'est plus un problème de discipline, c'est un problème de conception.

La solution n'est pas plus de shell. C'est d'arrêter de prendre la décision au lancement pour rattacher le compte à ce qui le détermine réellement : le projet.

Rattacher le compte au projet, pas au terminal

Ce que vous voulez, en général, c'est une règle et non une commande. Quelque chose comme : le dépôt de ce client tourne toujours sur le compte de ce client. Une fois cette règle posée, personne n'a plus rien à retenir.

Bien la mettre en place suppose de résoudre le compte dans un ordre défini, parce que la règle a besoin d'exceptions. Un défaut à l'échelle du projet convient la plupart du temps, mais un agent précis peut devoir tourner ailleurs : une expérimentation jetable sur un compte de test, ou un agent de relecture sur un siège au quota plus large.

La lecture se fait du haut vers le bas, et la première règle qui s'applique gagne. Une surcharge d'agent bat l'épinglage de projet. L'épinglage de projet bat le défaut général. Si rien n'est configuré nulle part, vous retombez sur ~/.claude, c'est-à-dire exactement ce que fait déjà une installation neuve. Ce dernier repli compte : il signifie qu'ajouter ce dispositif à une configuration existante ne change rien tant que vous n'épinglez rien explicitement.

C'est le modèle qu'implémente AgentsRoom. Chaque compte est un répertoire géré, la connexion se fait dans l'application plutôt que dans un shell, et la résolution ci-dessus s'exécute au démarrage d'un agent, en définissant CLAUDE_CONFIG_DIR sur ce processus uniquement. Si vous utilisez déjà un commutateur tiers comme CCS, vous pouvez pointer un compte vers un répertoire de profil existant au lieu de vous reconnecter.

Le même problème existe sur Codex, avec une autre variable

Si vous utilisez plusieurs fournisseurs, vous rencontrerez ce problème deux fois. La forme est identique et la variable ne l'est pas : un commutateur écrit pour l'un ne couvre donc pas l'autre. Nous documentons le versant Codex séparément dans le multi-compte pour Codex, avec ce qui diffère dans le parcours de connexion.

Le point général mérite d'être posé une fois : l'isolation des comptes est un mécanisme propre à chaque fournisseur. Tout outil qui prétend la gérer globalement enveloppe en réalité chaque fournisseur un par un, ou n'en prend en charge qu'un seul.

Savoir quel compte consomme réellement

Séparer les comptes ne représente que la moitié de la raison pour laquelle on fait tout cela. L'autre moitié consiste à savoir où atterrit la consommation, en particulier quand un client paie.

C'est la partie qui casse discrètement avec la méthode par le shell. Un lecteur de consommation qui ne regarde que ~/.claude sous-évalue dès qu'un agent tourne ailleurs, et les chiffres restent assez plausibles pour que personne ne s'en aperçoive pendant des semaines. Un lecteur conscient des comptes doit parcourir tous les répertoires configurés, pas seulement celui par défaut.

Si vous voulez le détail par compte et par session, nous avons traité le volet mesure dans comment vérifier la consommation de tokens de Claude Code, et la vue en direct se trouve sur la page consommation de tokens.

Ce à quoi cela ne sert pas

Une précision, parce que la question revient et qu'elle mérite une réponse franche plutôt qu'un silence.

Tout ce qui précède concerne la séparation de comptes qui existent déjà légitimement. Un siège payé par votre employeur et un abonnement personnel que vous payez sont deux relations commerciales différentes, et les faire cohabiter sur une machine sans contamination croisée est un besoin réel et ordinaire. Facturer les tokens d'un client à ce client aussi. Tenir un compte d'expérimentation à l'écart d'un compte de production aussi.

Créer des comptes supplémentaires pour contourner les limites de capacité de l'offre à laquelle vous avez souscrit est autre chose, et c'est précisément ce que visent les politiques d'usage. Le mécanisme décrit ici ne rend pas cette pratique acceptable, et un outil qui l'automatiserait vous aiderait à enfreindre un contrat que vous avez signé. Si votre second compte existe parce que quelqu'un d'autre le paie, vous êtes en terrain sûr. S'il existe pour réinitialiser une limite de débit, non. Les politiques d'usage d'Anthropic font foi, pas cet article.

Les questions qui reviennent

Puis-je utiliser deux comptes Claude Code sur le même ordinateur ?

Oui. Claude Code lit ses identifiants, ses métadonnées de session et son historique de projet dans le répertoire pointé par CLAUDE_CONFIG_DIR, qui vaut ~/.claude par défaut. Faites pointer cette variable vers un second répertoire, connectez-vous dedans, et vous avez deux comptes indépendants sur la même machine. Rien n'est partagé entre les deux répertoires, donc les deux restent connectés en permanence.

Comment changer de compte Claude Code sans me déconnecter ?

Vous ne vous déconnectez pas du tout. Se déconnecter puis se reconnecter réutilise le même répertoire : vous perdez la première session pour gagner la seconde. À la place, donnez à chaque compte son propre répertoire de configuration et choisissez entre eux en définissant CLAUDE_CONFIG_DIR au lancement de la CLI. Les deux jeux d'identifiants restent valides sur le disque, et le basculement ne coûte rien.

Où Claude Code stocke-t-il sa session ?

Dans le répertoire pointé par CLAUDE_CONFIG_DIR, qui vaut ~/.claude tant que vous ne le changez pas. Les identifiants eux-mêmes atterrissent dans un fichier .credentials.json à l'intérieur de ce répertoire, à côté des métadonnées de session et de l'historique par projet. Ce répertoire unique constitue tout le compte, et c'est ce qui fait de son remplacement un vrai basculement plutôt qu'un bricolage.

Deux agents peuvent-ils tourner sur deux comptes Claude différents en même temps ?

Oui, à condition que chaque processus d'agent reçoive son propre CLAUDE_CONFIG_DIR dans son environnement. La variable est lue par processus au lancement, pas globalement : deux agents démarrés avec deux valeurs différentes tournent donc sur deux comptes différents en parallèle. C'est ce qui rend utilisable un projet pro et un projet perso dans la même fenêtre.

Est-ce contraire aux conditions d'Anthropic d'avoir plusieurs comptes Claude ?

Détenir des comptes distincts pour des usages distincts est ordinaire : un siège payé par votre employeur et un abonnement personnel que vous payez sont deux relations commerciales différentes. Ce que visent les politiques d'usage, c'est la création de comptes destinée à contourner les limites de capacité de l'offre à laquelle vous avez souscrit. Si votre second compte existe parce que quelqu'un d'autre le paie, vous êtes en terrain sûr. S'il existe pour réinitialiser une limite de débit, non. Les politiques d'usage d'Anthropic font foi.

En résumé

Claude Code range un compte sous forme de répertoire, et CLAUDE_CONFIG_DIR décide lequel est actif. Deux répertoires signifient deux comptes, connectés en permanence, sans rien de partagé entre eux.

La version shell de tout ceci fonctionne jusqu'à ce que vous ayez plus d'un terminal ouvert. Au-delà, ce que vous voulez, c'est que le compte devienne une propriété du projet, avec une surcharge par agent pour les exceptions, afin que les bons identifiants soient rattachés au démarrage et que personne n'ait plus rien à retenir.