Múltiples cuentas de Claude Code en un dispositivo

Uso Claude Code a diario — para proyectos personales y para el trabajo en mi empresa. El problema: son dos cuentas completamente diferentes con distintas sesiones OAuth, distintas instrucciones CLAUDE.md, distintos servidores MCP y memoria de proyectos separada. Así es como los ejecuto en paralelo en un solo dispositivo con un único alias de shell.

El problema

Claude Code almacena todo en ~/.claude por defecto — token OAuth, historial de conversaciones, CLAUDE.md global, memoria de proyectos, configuraciones de servidores MCP y ajustes. Con dos cuentas, necesitas dos mundos completamente separados:

• Cuenta personal: tu suscripción Max/Pro, CLAUDE.md personal con tus preferencias, tus servidores MCP (Obsidian, herramientas personales)
• Cuenta corporativa: plan de la empresa, CLAUDE.md de trabajo con instrucciones de integración Jira/Slack, servidores MCP corporativos
• Sesiones OAuth diferentes: no puedes estar logueado en dos cuentas en el mismo directorio de configuración
• Memoria de proyectos separada: no quieres que el contexto de proyectos de trabajo se filtre a sesiones personales y viceversa

Cerrar sesión e iniciar sesión cada vez que cambias de contexto no es una opción. Pierdes el estado de la sesión, y es simplemente doloroso.

La solución: CLAUDE_CONFIG_DIR

Claude Code respeta una única variable de entorno: CLAUDE_CONFIG_DIR. Establécela en cualquier ruta y Claude usará ese directorio en lugar de ~/.claude para todo — auth, historial, ajustes, memoria. Todo el setup toma 60 segundos.

Paso 1: Crear un segundo directorio de configuración

Elige un nombre que tenga sentido para tu caso:

mkdir ~/.claude-work

Eso es todo. Claude lo poblará con la estructura necesaria en el primer lanzamiento.

Paso 2: Autenticar la segunda cuenta

Ejecuta Claude una vez con el nuevo directorio de configuración para iniciar el login OAuth:

CLAUDE_CONFIG_DIR=~/.claude-work claude

Se abre el navegador. Inicia sesión con tu cuenta corporativa. El token OAuth se almacena en ~/.claude-work — completamente separado de tu sesión personal en ~/.claude.

Paso 3: Añadir un alias de shell

Añade esto a tu configuración de shell para no tener que recordar la variable:

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

Recarga tu shell:

source ~/.zshrc

Qué obtienes

Ahora tienes dos entornos Claude completamente aislados:

• claude — lanza con tu cuenta personal, CLAUDE.md personal, memoria personal
• claude-work — lanza con tu cuenta corporativa, CLAUDE.md de trabajo, memoria separada
• Historial aislado: las conversaciones de trabajo se quedan en trabajo, las personales en personal
• Servidores MCP separados: tu MCP de Obsidian personal no aparece en sesiones de trabajo
• Ajustes independientes: diferentes herramientas permitidas, diferentes niveles de permisos, diferentes preferencias de modelo por cuenta

Cómo funciona internamente

El directorio de configuración es la única fuente de verdad para el estado de Claude Code. Esto es lo que vive dentro de cada uno:

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

Cuando ejecutas claude-work, Claude lee todo de ~/.claude-work. No sabe que ~/.claude existe. Las dos instancias son completamente independientes — puedes incluso ejecutarlas simultáneamente en diferentes pestañas del terminal.

Escalando a N cuentas

El patrón se extiende a cualquier número de cuentas. ¿Freelancer con múltiples clientes? Añade más aliases:

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

Cada alias tiene su propio directorio de configuración, su propia sesión OAuth, su propio CLAUDE.md con instrucciones específicas del cliente.

Consejos prácticos

• Nombra los directorios claramente: ~/.claude-work, ~/.claude-clientname — te lo agradecerás cuando tengas tres o cuatro
• Escribe un CLAUDE.md adaptado para cada uno: el de trabajo puede incluir instrucciones de la empresa (cómo crear tickets Jira, canales Slack, procedimientos de despliegue). El personal se mantiene ligero.
• Diferentes servidores MCP por cuenta: configura herramientas de trabajo (Jira MCP, Slack MCP, APIs internas) solo en la configuración de trabajo. Mantén la personal limpia.
• Verifica qué cuenta está activa: ejecuta claude config list dentro de una sesión si no estás seguro — muestra la ruta al directorio de configuración

Dónde se queda corto este enfoque

CLAUDE_CONFIG_DIR aísla por cuenta, no por proyecto. Dentro de un mismo perfil, Claude ve todos los servidores MCP que alguna vez registraste para esa cuenta — a través de todos tus proyectos. Para uso personal en solitario suele estar bien. En el momento en que tienes varios proyectos críticos en producción bajo una sola cuenta, especialmente en dominios solapados como facturación, herramientas de administración o infraestructura, aparece un riesgo concreto entre proyectos: un asistente IA puede invocar una herramienta del proyecto A mientras trabaja en el proyecto B, sobre todo cuando ambos exponen operaciones con nombres parecidos.

El patrón de perfil responde a la pregunta which account am I in?. No responde a la pregunta which project's tools should be active right now?. Para trabajo de mayor riesgo, apila una segunda capa de aislamiento sobre la separación por cuentas:

• Un perfil por proyecto crítico en producción, no solo por cuenta: en lugar de ~/.claude y ~/.claude-work, crea ~/.claude-work-billing y ~/.claude-work-admin. Cada perfil ve solo los servidores MCP que realmente necesita.
• MCP a nivel de proyecto vía .mcp.json: commitea un .mcp.json en la raíz del proyecto listando solo los servidores MCP de ese proyecto. Claude los detecta cuando se lanza desde ese directorio. Mantén tu configuración global mínima — solo herramientas universales (notas, búsqueda), ningún endpoint de producción.
• Nombra los servidores MCP sin ambigüedad: evita nombres genéricos como admin, billing, mcp-server. Prefija con el proyecto: acme_billing_prod, acme_admin_stage. Un nombre descriptivo te obliga a pararte cuando algo está a punto de invocarse desde el contexto equivocado.
• Revisa cada llamada a herramienta MCP antes de aprobarla: llamadas como *_create_*, *_delete_*, *_charge_* merecen una segunda mirada deliberada. La velocidad que ganas con auto-aprobación masiva se evapora la primera vez que una herramienta del proyecto equivocado se dispara contra producción.

La regla general: divide perfiles de forma agresiva, mantén el MCP de producción fuera del perfil por defecto, y trata cualquier solapamiento de nombres de herramientas entre proyectos como un smell que vale la pena refactorizar.

Conclusión

Una variable de entorno. Un alias. Aislamiento total entre cuentas. Sin baile de logout/login, sin conflictos de configuración, sin fuga de contexto. Es el tipo de solución que es casi decepcionantemente simple — pero eso es lo que la hace buena. Configúrala una vez y no vuelvas a pensar en ello.