Uma Máquina, Duas Contas Claude, Zero Estado Compartilhado A developer describes running two separate Claude Code accounts on the same machine with zero shared state, using distinct CLAUDE_CONFIG_DIR directories to keep personal and work environments isolated. The approach uses shell functions to switch between accounts, avoiding symlinks or merge scripts, at the cost of manually duplicating skills across accounts. 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" https://dev.to/daksh-gargas/one-brain-two-wallets-two-claude-code-accounts-on-one-machine-5ejb 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 ~/.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: "$@" 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