Claude Code solo mantiene una sesión iniciada a la vez. Así es como puedes usar varias.

Guía de campo para usar una cuenta de trabajo y una personal en la misma máquina: la variable de entorno que decide qué cuenta está activa, por qué el método del shell se rompe en cuanto tienes más de dos terminales, y cómo fijar una cuenta por proyecto.

Hay un momento por el que pasa casi todo el que usa Claude Code tanto para el trabajo como para sus propios proyectos. Terminas una sesión de trabajo, cambias a un proyecto personal y te das cuenta de que el agente sigue con la sesión iniciada en la cuenta que paga tu empresa. Así que cierras sesión, vuelves a entrar con tu propia cuenta y media hora después te toca hacer lo contrario.

Ese bucle no es una funcionalidad que falte. Es una consecuencia de dónde guarda Claude Code su sesión iniciada, y en cuanto sabes dónde está, tener varias cuentas conviviendo pasa a ser un detalle de configuración en lugar de un problema de método de trabajo.

Una sola variable de entorno decide qué cuenta está activa

Claude Code no guarda sus credenciales en una base de datos ni en una entrada del llavero indexada por perfil. Lee todo lo que necesita de un único directorio: credenciales, metadatos de sesión e historial por proyecto.

Ese directorio es el que indique CLAUDE_CONFIG_DIR. Si nunca defines esa variable, es ~/.claude.

Diagrama de cómo resuelve Claude Code su cuenta: la variable de entorno CLAUDE_CONFIG_DIR apunta a un único directorio que contiene credentials.json, los metadatos de sesión y el historial de proyecto, con ~/.claude como valor por defecto cuando la variable no está definida.

Ese es todo el mecanismo, y tiene una propiedad útil: como una cuenta es un directorio y no un ajuste global, tener dos cuentas equivale a tener dos directorios. Nada se comparte entre ellos. Ambas se mantienen con la sesión iniciada indefinidamente, y ninguna sabe que la otra existe.

Así que la versión ingenua funciona:

# personal
CLAUDE_CONFIG_DIR=~/.claude claude

# trabajo
CLAUDE_CONFIG_DIR=~/.claude-work claude

Ejecuta /login una vez dentro del segundo y ya tienes dos cuentas activas en una sola máquina.

Dónde empieza a doler el método del shell

La versión de dos líneas de arriba está perfectamente bien si abres una terminal cada vez y eres disciplinado. Deja de estarlo por tres razones, y se acumulan.

La variable es por proceso, no por máquina. Cada terminal nueva, cada panel nuevo, cada shell integrado en el editor arranca con el valor por defecto de tu perfil. Expórtala en el .zshrc y solo habrás movido el problema de sitio: ahora la cuenta que se te olvida es la otra.

Nada te dice qué cuenta está activa. Claude Code no imprime la cuenta en su prompt. Si tienes dos terminales abiertas y una de ellas está en la cuenta de trabajo, se ven idénticas. El momento en que te das cuenta suele ser el momento en que miras la factura.

No sobrevive al paralelismo. Las configuraciones interesantes ejecutan varios agentes a la vez, en varios proyectos. Pasadas dos sesiones simultáneas, acordarse de qué panel se lanzó con qué variable deja de ser un problema de disciplina: es un problema de diseño.

Diagrama comparativo: a la izquierda, la elección de la cuenta de Claude Code exportando CLAUDE_CONFIG_DIR en cada terminal, donde una tercera terminal no da ninguna indicación visible de qué cuenta está activa. A la derecha, la cuenta asociada al proyecto con una anulación por agente, resuelta automáticamente cuando el agente arranca.

La solución no es más shell. Es dejar de tomar la decisión en el momento del lanzamiento y empezar a asociar la cuenta a lo que realmente la determina: el proyecto.

Asocia la cuenta al proyecto, no a la terminal

Lo que normalmente quieres es una regla, no un comando. Algo así como: el repositorio de este cliente se ejecuta siempre en la cuenta de este cliente. Una vez que esa regla existe, nadie tiene que acordarse de nada.

Hacerlo bien implica resolver la cuenta en un orden definido, porque la regla necesita excepciones. Un valor por defecto para todo el proyecto acierta la mayor parte del tiempo, pero puede que un agente concreto tenga que ejecutarse en otro sitio: un experimento desechable en una cuenta de pruebas, o un agente de revisión en una licencia con más cuota.

Diagrama del orden de resolución de la cuenta en cuatro niveles: la anulación a nivel de agente gana a la cuenta fijada en el proyecto, que gana al valor por defecto de la aplicación, que a su vez recurre al directorio del sistema por defecto ~/.claude.

Se lee de arriba abajo, y gana la primera regla que coincide. Una anulación de agente gana a la cuenta fijada en el proyecto. La cuenta fijada en el proyecto gana a lo que hayas definido como valor por defecto general. Si no hay nada configurado en ninguna parte, acabas en ~/.claude, que es exactamente lo que ya hace una instalación nueva. Ese último respaldo importa: significa que añadir esto a una configuración existente no cambia nada hasta que fijas algo de forma explícita.

Este es el modelo que implementa AgentsRoom. Cada cuenta es un directorio gestionado, el inicio de sesión ocurre dentro de la app en lugar de en un shell, y la resolución de arriba se ejecuta cuando arranca un agente, definiendo CLAUDE_CONFIG_DIR solo en ese proceso. Si ya usas un conmutador de terceros como CCS, puedes apuntar una cuenta a un directorio de perfil existente en lugar de volver a iniciar sesión.

El mismo problema existe en Codex, con otra variable

Si usas más de un proveedor, te toparás con esto dos veces. La forma es idéntica y la variable no lo es, así que un conmutador construido para uno no cubre el otro. Mantenemos la parte de Codex documentada por separado en multicuenta para Codex, incluido lo que cambia en el flujo de inicio de sesión.

Merece la pena enunciar el punto general una vez: el aislamiento de cuentas es un mecanismo propio de cada proveedor. Cualquier herramienta que afirme gestionarlo de forma global o está envolviendo cada proveedor por separado, o solo soporta uno.

Saber qué cuenta está quemando tokens de verdad

Separar cuentas es solo la mitad de la razón por la que la gente hace esto. La otra mitad es saber dónde aterriza el consumo, sobre todo cuando paga un cliente.

Esta es la parte que se rompe en silencio con el método del shell. Los lectores de uso que solo miran ~/.claude se quedarán cortos en cuanto un agente se ejecute en otro sitio, y los números parecen lo bastante plausibles como para que nadie lo note durante semanas. Un lector consciente de las cuentas tiene que recorrer todos los directorios configurados, no solo el que viene por defecto.

Si quieres cifras por cuenta y por sesión, cubrimos la parte de medición en cómo verificar el uso de tokens de Claude Code, y la vista en vivo está en la página de uso de tokens.

Para qué no sirve esto

Una aclaración, porque la pregunta sale y merece una respuesta directa en lugar de un silencio.

Todo lo anterior trata de separar cuentas que ya existen de forma legítima. Una licencia que paga tu empresa y una suscripción personal que pagas tú son dos relaciones comerciales distintas, y tenerlas conviviendo en una misma máquina sin contaminación cruzada es una necesidad real y corriente. También lo es facturarle a un cliente los tokens de ese cliente, y también lo es mantener una cuenta experimental lejos de una de producción.

Crear cuentas adicionales para sortear los límites de capacidad del plan que has contratado es otra cosa, y es justamente a lo que apuntan las políticas de uso. El mecanismo descrito aquí no hace que eso sea aceptable, y una herramienta que lo automatizara te estaría ayudando a incumplir un acuerdo que firmaste. Si tu segunda cuenta existe porque otra persona la paga, estás en terreno seguro. Si existe para reiniciar un límite de tasa, no. Las políticas de uso de Anthropic son la referencia, no este artículo.

Las preguntas que hace la gente

¿Puedo usar dos cuentas de Claude Code en el mismo ordenador?

Sí. Claude Code lee sus credenciales, los metadatos de sesión y el historial de proyecto del directorio al que apunta CLAUDE_CONFIG_DIR, que por defecto es ~/.claude. Apunta esa variable a un segundo directorio, inicia sesión allí y ya tienes dos cuentas independientes en la misma máquina. Nada se comparte entre los dos directorios, así que ambas se mantienen con la sesión iniciada al mismo tiempo.

¿Cómo cambio de cuenta en Claude Code sin cerrar sesión?

No cierras sesión en ningún momento. Cerrar sesión y volver a entrar reutiliza el mismo directorio, así que pierdes la primera sesión para ganar la segunda. En su lugar, dale a cada cuenta su propio directorio de configuración y elige entre ellas definiendo CLAUDE_CONFIG_DIR cuando lanzas la CLI. Las dos credenciales siguen siendo válidas en disco, y cambiar no cuesta nada.

¿Dónde guarda Claude Code su inicio de sesión?

En el directorio al que apunta CLAUDE_CONFIG_DIR, que es ~/.claude mientras no lo cambies. Las credenciales en sí acaban en un archivo .credentials.json dentro de ese directorio, junto a los metadatos de sesión y el historial por proyecto. Ese único directorio es toda la cuenta, y eso es lo que convierte su intercambio en un cambio limpio en lugar de un apaño.

¿Pueden dos agentes ejecutarse en dos cuentas de Claude distintas al mismo tiempo?

Sí, siempre que cada proceso de agente reciba su propio CLAUDE_CONFIG_DIR en su entorno. La variable se lee por proceso al arrancar, no de forma global, así que dos agentes iniciados con dos valores distintos se ejecutan en dos cuentas distintas en paralelo. Esto es lo que hace utilizables un proyecto de trabajo y uno personal en la misma ventana.

¿Va contra los términos de Anthropic tener más de una cuenta de Claude?

Tener cuentas separadas para propósitos separados es algo corriente: una licencia que paga tu empresa y una suscripción personal que pagas tú son dos relaciones comerciales distintas. A lo que apuntan las políticas de uso es a crear cuentas para sortear los límites de capacidad del plan que has contratado. Si tu segunda cuenta existe porque otra persona la paga, estás en terreno seguro. Si existe para reiniciar un límite de tasa, no. Las políticas de uso de Anthropic son la referencia.

La versión corta

Claude Code guarda una cuenta en forma de directorio, y CLAUDE_CONFIG_DIR decide cuál está activa. Dos directorios significan dos cuentas, con la sesión iniciada de forma permanente y sin nada compartido entre ellas.

La versión con shell de todo esto funciona hasta que tienes más de una terminal abierta. A partir de ahí, lo que quieres es que la cuenta sea una propiedad del proyecto, con una anulación por agente para las excepciones, de modo que las credenciales correctas se asocien en el momento de arrancar y nadie tenga que acordarse de nada.

Descargar AgentsRoom

Ejecuta tus agentes de IA (Claude, Codex, Antigravity CLI, OpenCode, Aider, Grok Build, Mistral Vibe, Kimi Code) en todos tus proyectos, desde una sola ventana.

GratisDescargar AgentsRoom

App complementaria: supervisa tus agentes en movimiento

Usa Claude, Codex, Antigravity CLI u otro proveedor de IA.

Instalar la extensión
Chrome Web Store

Envía bugs y peticiones directamente a tu backlog público.

Un vistazo a AgentsRoom en acción.

Multi-proyectos
Multi-proveedor
Multi-agentes
Estado en vivo
Diff y commit
App móvil
Vista previa
Equipos de agentes
Pruebas en navegador
Dev guiada por backlog
Biblioteca de prompts
Biblioteca de skills
Ver todas las funcionalidades

Seguir leyendo