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 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
claude-work() { CLAUDE_CONFIG_DIR="$HOME/.claude-work" claude "$@"; }
claude-personal() { CLAUDE_CONFIG_DIR="$HOME/.claude" claude "$@"; }
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:
"$@"
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.
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.
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.
--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.
Faça uma pergunta só: suas duas contas são o mesmo você, ou dois contextos diferentes?
jq
daquele outro post são exatamente certos, e o shim de --resume
vale a pena.Em resumo:
claude # pessoal (default)
claude-work # conta de trabalho, cada coisa dela
claude-work --resume X # retoma uma sessão de trabalho