Plusieurs comptes Claude Code sur un seul appareil

J'utilise Claude Code quotidiennement — pour mes projets personnels et pour le travail en entreprise. Le problème : ce sont deux comptes totalement différents avec des sessions OAuth distinctes, des instructions CLAUDE.md différentes, des serveurs MCP séparés et une mémoire de projets isolée. Voici comment je les fais tourner en parallèle sur un seul appareil avec un simple alias shell.

Le problème

Claude Code stocke tout dans ~/.claude par défaut — token OAuth, historique des conversations, CLAUDE.md global, mémoire des projets, configurations des serveurs MCP et paramètres. Avec deux comptes, tu as besoin de deux mondes complètement séparés :

• Compte personnel : ton abonnement Max/Pro, CLAUDE.md personnel avec tes préférences, tes serveurs MCP (Obsidian, outils personnels)
• Compte entreprise : plan géré par l'entreprise, CLAUDE.md de travail avec instructions d'intégration Jira/Slack, serveurs MCP corporate
• Sessions OAuth différentes : impossible d'être connecté à deux comptes dans le même répertoire de configuration
• Mémoire de projets séparée : tu ne veux pas que le contexte des projets professionnels fuie dans les sessions personnelles et vice versa

Se déconnecter et reconnecter à chaque changement de contexte n'est pas une option. Tu perds l'état de session, et c'est tout simplement pénible.

La solution : CLAUDE_CONFIG_DIR

Claude Code respecte une seule variable d'environnement : CLAUDE_CONFIG_DIR. Définis-la sur n'importe quel chemin et Claude utilisera ce répertoire au lieu de ~/.claude pour tout — auth, historique, paramètres, mémoire. L'installation complète prend 60 secondes.

Étape 1 : Créer un second répertoire de configuration

Choisis un nom qui correspond à ton cas d'usage :

mkdir ~/.claude-work

C'est tout. Claude le remplira avec la structure nécessaire au premier lancement.

Étape 2 : Authentifier le second compte

Lance Claude une fois avec le nouveau répertoire de configuration pour déclencher le login OAuth :

CLAUDE_CONFIG_DIR=~/.claude-work claude

Le navigateur s'ouvre. Connecte-toi avec ton compte entreprise. Le token OAuth est stocké dans ~/.claude-work — complètement séparé de ta session personnelle dans ~/.claude.

Étape 3 : Ajouter un alias shell

Ajoute ceci à ta configuration shell pour ne pas avoir à retenir la variable :

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

Recharge ton shell :

source ~/.zshrc

Ce que tu obtiens

Tu as maintenant deux environnements Claude complètement isolés :

• claude — lance avec ton compte personnel, CLAUDE.md personnel, mémoire personnelle
• claude-work — lance avec ton compte entreprise, CLAUDE.md de travail, mémoire séparée
• Historique isolé : les conversations de travail restent au travail, le personnel reste personnel
• Serveurs MCP séparés : ton MCP Obsidian personnel n'apparaît pas dans les sessions de travail
• Paramètres indépendants : outils autorisés différents, niveaux de permissions différents, préférences de modèle différentes par compte

Comment ça fonctionne sous le capot

Le répertoire de configuration est la source unique de vérité pour l'état de Claude Code. Voici ce qui vit à l'intérieur de chacun :

~/.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

Quand tu lances claude-work, Claude lit tout depuis ~/.claude-work. Il ignore l'existence de ~/.claude. Les deux instances sont complètement indépendantes — tu peux même les faire tourner simultanément dans différents onglets du terminal.

Passage à N comptes

Le pattern s'étend à n'importe quel nombre de comptes. Freelance avec plusieurs clients ? Ajoute plus d'alias :

# 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'

Chaque alias a son propre répertoire de configuration, sa propre session OAuth, son propre CLAUDE.md avec des instructions spécifiques au client.

Conseils pratiques

• Nomme les répertoires clairement : ~/.claude-work, ~/.claude-clientname — tu te remercieras quand il y en aura trois ou quatre
• Écris un CLAUDE.md dédié pour chacun : celui du travail peut inclure les instructions de l'entreprise (créer des tickets Jira, canaux Slack, procédures de déploiement). Le personnel reste minimaliste.
• Serveurs MCP différents par compte : configure les outils de travail (Jira MCP, Slack MCP, APIs internes) uniquement dans la config de travail. Garde ta config personnelle propre.
• Vérifie quel compte est actif : lance claude config list dans une session si tu as un doute — ça affiche le chemin vers le répertoire de configuration

Les limites de cette approche

CLAUDE_CONFIG_DIR isole par compte, pas par projet. À l'intérieur d'un même profil, Claude voit tous les serveurs MCP que tu as un jour enregistrés pour ce compte — à travers l'ensemble de tes projets. Pour un usage perso en solo, ça reste généralement acceptable. Dès que tu as plusieurs projets critiques en production sous un même compte, surtout dans des domaines qui se chevauchent comme la facturation, l'outillage admin ou l'infrastructure, ça introduit un risque concret entre projets : un assistant IA peut appeler un outil du projet A en travaillant sur le projet B, en particulier quand les deux exposent des opérations aux noms similaires.

Le pattern de profil répond à la question which account am I in?. Il ne répond pas à la question which project's tools should be active right now?. Pour du travail à enjeux plus élevés, empile une seconde couche d'isolation par-dessus le découpage par comptes :

• Un profil par projet critique en production, pas seulement par compte : au lieu de ~/.claude et ~/.claude-work, crée ~/.claude-work-billing et ~/.claude-work-admin. Chaque profil ne voit que les serveurs MCP dont il a réellement besoin.
• MCP au niveau projet via .mcp.json : commit un .mcp.json à la racine du projet listant uniquement les serveurs MCP de ce projet. Claude les charge quand il est lancé depuis ce répertoire. Garde ta config globale minimale — uniquement les outils universels (notes, recherche), aucun endpoint de production.
• Nomme les serveurs MCP sans ambiguïté : évite les noms génériques comme admin, billing, mcp-server. Préfixe avec le projet : acme_billing_prod, acme_admin_stage. Un nom descriptif force une pause quand quelque chose est sur le point d'être appelé depuis le mauvais contexte.
• Vérifie chaque appel d'outil MCP avant approbation : les appels comme *_create_*, *_delete_*, *_charge_* méritent un second regard délibéré. La vitesse gagnée par une auto-approbation systématique s'évapore la première fois qu'un outil du mauvais projet tire en production.

La règle générale : découpe les profils agressivement, garde le MCP de niveau production hors du profil par défaut, et traite tout chevauchement de noms d'outils entre projets comme un smell qui mérite un refactoring.

Conclusion

Une variable d'environnement. Un alias. Isolation totale entre les comptes. Pas de danse logout/login, pas de conflits de configuration, pas de fuite de contexte. Le genre de solution presque décevante de simplicité — mais c'est exactement ce qui la rend bonne. Configure une fois et n'y pense plus jamais.