Plusieurs comptes Claude Code sur une seule machine

Vous avez un abonnement Claude Code personnel et un professionnel. Ou vous êtes freelance pour deux clients qui fournissent chacun leur propre clé API. Ou vous voulez un compte sandbox pour vos expériences, sans polluer votre config principale.

Quelle que soit la raison, Claude Code ne propose pas de commande “changer de compte” intégrée. Mais son architecture rend la chose simple : tout vit dans un seul répertoire de configuration, et on peut le rediriger.

Comment Claude Code stocke son état

Claude Code conserve tout son état dans ~/.claude par défaut. Cela inclut :

• Les tokens d’authentification
• Les paramètres par projet (.claude/ dans chaque repo)
• L’historique des conversations
• Les fichiers de mémoire
• Les configs de serveurs MCP

Le point clé : la variable d’environnement CLAUDE_CONFIG_DIR remplace le répertoire où Claude Code cherche tout cela. Pointez-la ailleurs, et vous obtenez une instance complètement indépendante.

Configuration de base : les alias shell

Créez un répertoire de config par compte :

mkdir -p ~/.claude-personal
mkdir -p ~/.claude-work

Trouvez le chemin du binaire Claude :

which claude
# ex. /Users/you/.nvm/versions/node/v22.15.0/bin/claude

Ajoutez les alias dans votre ~/.zshrc (ou ~/.bashrc) :

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

Rechargez votre shell :

source ~/.zshrc

Puis authentifiez chaque compte séparément :

claude-personal   # lancez /login dans la session
claude-work       # lancez /login dans la session

Chaque alias ouvre maintenant Claude Code avec sa propre authentification, sa mémoire et ses paramètres.

Ce que l’approche par alias ne couvre pas

L’astuce des alias fonctionne, mais elle a des lacunes qui vous rattraperont en usage réel.

Problème 1 : les mises à jour NVM cassent les chemins absolus

Si vous codez en dur le chemin du binaire dans votre alias (comme beaucoup de guides le suggèrent), une mise à jour de Node via NVM le casse silencieusement. Utilisez simplement claude au lieu du chemin absolu, et laissez $PATH le résoudre :

# fragile
alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work /Users/you/.nvm/versions/node/v22.15.0/bin/claude'

# résilient
alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

Problème 2 : la config projet fuit entre les comptes

Claude Code crée un répertoire .claude/ dans votre repo projet. Ce répertoire stocke les paramètres projet, CLAUDE.md et settings.json. Ils sont partagés entre tous vos alias car ils vivent dans le repo, pas dans le répertoire de config.

Concrètement, votre compte pro et votre compte perso voient les mêmes instructions projet. C’est généralement acceptable, mais si vous avez besoin de serveurs MCP ou de permissions différentes par compte et par projet, il faudra gérer ça autrement (voir la section script wrapper ci-dessous).

Problème 3 : les hooks et serveurs MCP sont liés au config-dir

Si vous avez configuré des hooks ou serveurs MCP dans ~/.claude/settings.json, ils n’existeront pas dans vos nouveaux répertoires de config. Vous devrez copier ou créer des liens symboliques pour les éléments que vous voulez partager :

# partager les hooks entre les comptes
ln -s ~/.claude/settings.json ~/.claude-work/settings.json

Ou, si vous voulez des hooks différents par compte, copiez et personnalisez :

cp ~/.claude/settings.json ~/.claude-work/settings.json

Problème 4 : la mémoire ne se transfère pas

Chaque répertoire de config a son propre système de mémoire. Votre compte personnel ne se souviendra pas de ce que votre compte pro a appris. Si vous utilisez des workflows qui reposent beaucoup sur la mémoire, cette isolation est parfois un avantage, parfois un problème.

Meilleure approche : un script wrapper

Au lieu de simples alias, un petit wrapper vous donne le changement de compte avec validation :

#!/usr/bin/env bash
# Enregistrez sous ~/bin/claude-switch et chmod +x

ACCOUNT="${1:?Usage: claude-switch <nom-du-compte> [args claude...]}"
shift

CONFIG_DIR="$HOME/.claude-$ACCOUNT"

if [ ! -d "$CONFIG_DIR" ]; then
  echo "Compte '$ACCOUNT' introuvable. Comptes disponibles :"
  ls -d ~/.claude-* 2>/dev/null | sed 's|.*/.claude-||'
  exit 1
fi

CLAUDE_CONFIG_DIR="$CONFIG_DIR" exec claude "$@"

Utilisation :

claude-switch work
claude-switch personal --resume
claude-switch work -p "corrige le bug de login"

Tous les arguments sont transmis, donc les flags comme --resume, --print et -p fonctionnent normalement.

Valeurs par défaut par projet

Si un repo spécifique doit toujours utiliser un compte précis, vous pouvez le définir dans un fichier .envrc (si vous utilisez direnv) :

# /path/to/work-project/.envrc
export CLAUDE_CONFIG_DIR="$HOME/.claude-work"

Désormais, chaque fois que vous faites cd dans ce projet et lancez claude, il utilise automatiquement le compte pro. Pas besoin d’alias.

Sans direnv, vous pouvez l’ajouter à l’historique shell du projet ou à un fichier .env local que votre shell source.

Comptes par clé API vs comptes OAuth

Il existe deux modes d’authentification dans Claude Code, et ils interagissent différemment avec les setups multi-comptes :

OAuth (par défaut) : Vous lancez /login et vous vous authentifiez via le flux web d’Anthropic. Le token est stocké dans le répertoire de config. C’est ce que la plupart des gens utilisent avec les abonnements Claude Pro/Max.

Clé API : Vous définissez ANTHROPIC_API_KEY comme variable d’environnement. Cela contourne complètement l’authentification du répertoire de config.

Pour les setups par clé API, vous n’avez même pas besoin de répertoires de config séparés pour l’authentification. Il suffit de changer la clé :

alias claude-client-a='ANTHROPIC_API_KEY=$CLIENT_A_KEY claude'
alias claude-client-b='ANTHROPIC_API_KEY=$CLIENT_B_KEY claude'

Mais vous aurez quand même besoin de répertoires de config séparés si vous voulez isoler la mémoire, les hooks ou les serveurs MCP.

Combiner les deux : clé API + isolation de config

Le setup le plus robuste pour les freelances et consultants :

# ~/.zshrc
export CLIENT_A_KEY="sk-ant-..."  # ou sourcez depuis un gestionnaire de secrets

alias claude-client-a='ANTHROPIC_API_KEY=$CLIENT_A_KEY CLAUDE_CONFIG_DIR=~/.claude-client-a claude'
alias claude-client-b='ANTHROPIC_API_KEY=$CLIENT_B_KEY CLAUDE_CONFIG_DIR=~/.claude-client-b claude'

Chaque client obtient :

• Sa propre clé API (la facturation va au bon endroit)
• Sa propre mémoire (le contexte client reste séparé)
• Ses propres serveurs MCP (différents clients, différents outils)
• Ses propres hooks (différents standards de code review, différents workflows)

Exécuter des comptes simultanément

Vous pouvez lancer plusieurs instances Claude Code en parallèle, chacune dans son propre onglet de terminal. Les répertoires de config sont indépendants, donc il n’y a ni verrouillage ni conflit.

# Terminal 1
claude-work

# Terminal 2
claude-personal

Les deux sessions tournent en parallèle sans interférence. C’est utile quand vous attendez la fin d’une tâche longue sur un compte et voulez travailler sur autre chose avec l’autre.

Référence rapide

Ce que vous voulez	Ce qu’il faut configurer
Auth différente	CLAUDE_CONFIG_DIR
Clé API différente	ANTHROPIC_API_KEY
Mémoire différente	CLAUDE_CONFIG_DIR
Serveurs MCP différents	CLAUDE_CONFIG_DIR + settings.json custom
Défaut par projet	.envrc avec CLAUDE_CONFIG_DIR
Tout en même temps	Alias combiné avec les deux variables d’env

Aller plus loin : plusieurs instances de Claude Desktop

Tout ce qui précède concerne Claude Code (le CLI). Si vous utilisez aussi l’application de bureau Claude et voulez deux instances côte à côte avec des comptes différents, l’approche est différente : il faut dupliquer l’application elle-même.

Sur macOS, Parallels Toolbox peut créer un “raccourci d’application” qui agit comme une deuxième copie de Claude. Chaque copie maintient sa propre session de connexion, ce qui permet de lancer votre compte pro dans une fenêtre et votre compte perso dans une autre, sans avoir à se connecter et déconnecter. Ce tutoriel vidéo montre la procédure complète.

Le principe : ouvrez Parallels Toolbox, créez un raccourci d’application pointant vers Claude, donnez-lui un nom distinct (comme “Claude Work”), approuvez-le dans les réglages de sécurité macOS, et connectez-vous avec votre second compte. Les deux instances vivent dans votre dock et fonctionnent indépendamment.

Cela se combine bien avec le setup multi-comptes CLI : utilisez les alias CLAUDE_CONFIG_DIR pour le travail en terminal, et les raccourcis Parallels pour l’interface graphique.

Ce que j’utilise au quotidien

Deux répertoires de config : ~/.claude-personal pour mes projets perso, ~/.claude-work pour le travail client. Direnv gère le changement par projet, donc je tape simplement claude et il choisit le bon compte. Je fais un lien symbolique de settings.json depuis ma config perso vers celle du travail parce que je veux les mêmes hooks partout, mais la mémoire reste séparée.

L’installation complète a pris cinq minutes. Ce qui a pris le plus de temps, c’est de réaliser qu’il fallait relancer /login dans chaque répertoire de config après l’avoir créé.