Uma Máquina, Duas Contas Claude, Zero Estado Compartilhado

Vi um post legal esses dias sobre rodar duas contas do Claude Code na mesma máquina compartilhando tudo entre elas: mesmas skills, mesmos servidores MCP, mesmos hooks.
O artigo era: "Um cérebro, duas carteiras"

Eu rodo, exatamente o oposto, e acho que pra muita gente o oposto é a escolha certa.

Minhas duas contas não são uma pessoal e uma reserva pra quando os créditos acabam. Uma é pessoal, outra é de trabalho.
A última coisa que eu quero é meus MCP servers de trabalho, meus hooks de trabalho e meu histórico de projeto de trabalho vazando pras sessões pessoais.

Então em vez de ligar as duas, eu mantenho elas separadas de propósito.

O setup inteiro

O Claude Code guarda o estado num diretório de config (~/.claude por padrão) e lê a variável CLAUDE_CONFIG_DIR pra apontar pra outro lugar. Esse é o único mecanismo que você precisa. Sem shim, sem symlink, sem jq.

bash
# ~/.zshrc
# Claude Code: contas isoladas (pessoal vs trabalho)
# Cada uma usa um CLAUDE_CONFIG_DIR proprio -> credenciais/sessao separadas.
# ~/.claude       = pessoal (default)
# ~/.claude-work  = trabalho
claude-work()     { CLAUDE_CONFIG_DIR="$HOME/.claude-work" claude "$@"; }
claude-personal() { CLAUDE_CONFIG_DIR="$HOME/.claude"      claude "$@"; }
# 'claude' sozinho continua sendo a conta pessoal.

source ~/.zshrc
claude-work   # pede login OAuth da conta de trabalho, uma vez só

Usei funções de shell em vez de alias por um motivo:

• a função repassa "$@" limpo, então claude-work --resume abc e claude-work chat funcionam sem a variável de ambiente vazar pra nada mais no shell. Um alias faria quase o mesmo aqui, mas a função deixa a passagem de argumentos explícita.

É isso. claude puro é pessoal. claude-work é trabalho. Nada é compartilhado, e é aí que mora a graça.

Por que eu não compartilho o cérebro

A versão de cérebro compartilhado faz symlink de skills, plugins, settings.json e dá merge no bloco mcpServers entre as duas contas pra elas se comportarem igual. Se as suas duas contas são de fato a mesma pessoa com duas assinaturas, tranquilo.

O trabalho tem MCP servers apontando pra sistemas internos. O trabalho tem hooks e permissões que eu nunca ia querer disparando numa sessão pessoal em algum projeto paralelo aleatório.

Histórico de trabalho é histórico de trabalho.

Quando eu abro um Claude pessoal, quero um ambiente pessoal limpo. Manter os diretórios de config totalmente separados me dá isso de graça. Sem script de merge pra manter, sem risco de um token de trabalho aparecer onde não devia.

O custo é real: se eu adiciono uma skill na conta pessoal, a de trabalho não recebe.

Preciso adicionar nos dois lugares. Em quatro meses isso me custou uns dez minutos no total, o'que eu acho aceitável.

O problema do setup compartilhado

Na versão compartilhada, a maior cilada é o .claude.json. Esse arquivo de nível de usuário (MCP servers, confiança de pasta, estado de onboarding) normalmente fica ao lado de ~/.claude, mas no instante em que CLAUDE_CONFIG_DIR está setado, o Claude lê ele de dentro do diretório de config. Ou seja, apontar um segundo alias pro seu ~/.claude existente pode criar um .claude.json novo e vazio, apagando seus MCP servers debaixo de você. A solução deles é um symlink de volta pro arquivo mestre.

Eu desvio disso inteiro. Cada conta tem o seu próprio ~/.claude/.claude.json e ~/.claude-work/.claude.json, os dois arquivos reais, cada um da sua conta. Nada aponta pra nada, então nada é sobrescrito.

E o --resume?

É o único ponto onde o setup compartilhado precisa mesmo do shim. Os transcripts de sessão ficam em <config-dir>/projects/<projeto>/<session-id>.jsonl. Se um script em background ou um restore de crash chama claude --resume <id> puro e a sessão pertence à outra conta, o Claude diz que ela não existe. O shim deles olha o ID, descobre qual conta é dona e seta o CLAUDE_CONFIG_DIR de acordo.

Eu não rodo esse shim, então assumo a pequena disciplina que ele compraria: retomo uma sessão de trabalho com claude-work --resume, e uma pessoal com claude. Como eu já penso nas duas como contextos diferentes, pegar o comando certo é automático, do mesmo jeito que eu não dou git push no repo errado.

Isolamento vs. um cérebro: como escolher

Faça uma pergunta só: suas duas contas são o mesmo você, ou dois contextos diferentes?

• Mesma pessoa, duas assinaturas, só muda quem paga. Compartilhe o cérebro. Os symlinks e o merge com jq daquele outro post são exatamente certos, e o shim de --resume vale a pena.
• Contextos diferentes (trabalho vs. pessoal, cliente A vs. cliente B, uma conta trancada pra algo sensível). Isole. Dois diretórios de config, duas funções, pronto. Você ganha a separação de graça e pula todos os contornos.

Em resumo:

claude                   # pessoal (default)
claude-work              # conta de trabalho, cada coisa dela
claude-work --resume X   # retoma uma sessão de trabalho

Comments

[Luis Cruz]

Eu entendi a necessidade de manter as contas separadas, especialmente quando se trata de informações sensíveis como MCP servers e histórico de projeto de trabalho. A sua abordagem de usar funções de shell para setar a variável CLAUDE_CONFIG_DIR é bem elegante e evita a necessidade de symlinks ou shims.
Acho interessante que você tenha mencionado o custo de manter as contas separadas, especialmente quando se trata de adicionar skills ou plugins.
Será que existe uma forma de automatizar a sincronização de skills ou plugins entre as duas contas, sem comprometer a segurança e a separação das informações?