Dá para usar dois sistemas ao mesmo tempo no Claude Code sem um atrapalhar o outro?

Fala aí, beleza? Hoje o Claude Code de qualquer pessoa que usa a ferramenta a sério tem skill do time, plugin instalado de marketplace, dois ou três servidores MCP, um subagente ou outro e uma penca de hooks rodando junto

Tudo isso convivendo no mesmo processo

E a pergunta que realmente importa não é "dá para instalar os dois", porque dar, dá

A pergunta é o que acontece quando dois deles querem o MESMO espaço: o mesmo nome, a mesma permissão, o mesmo evento, a mesma janela de contexto

A resposta muda por camada, e é isso que faz a diferença entre uma sessão saudável e aquela sensação de "jurava que tinha configurado isso"

Como cada camada resolve conflito: sobrepõe, soma ou avisa

Antes de sair caçando bug, vale entender a mecânica de cada camada

Algumas sobrepõem (uma vence, a outra é ignorada), outras somam (as duas valem ao mesmo tempo)

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Se você guardar só uma linha dessa tabela, guarde esta: skill, subagente, settings e MCP sobrepõem

Hook e CLAUDE.md somam

Quase todo susto de convivência cabe nessas duas frases

Sinais de que dois sistemas já estão brigando na sua sessão

A briga raramente aparece como erro vermelho na tela

Ela aparece como comportamento estranho, e você perde meia hora achando que é bug do modelo quando é a precedência funcionando certinho

O /deploy roda a versão errada

Sintoma: você editou a skill do projeto, salvou, rodou e o comportamento é o antigo

Causa documentada: skills se sobrepõem por nome, e a ordem é enterprise, depois pessoal, depois projeto. O exemplo oficial é exatamente esse: com uma skill deploy em ~/.claude/skills/ e outra em .claude/skills/ do projeto, o /deploy executa a pessoal, e a do projeto é ignorada

O que fazer: renomeie uma das duas, ou tire a versão pessoal do caminho quando for trabalhar naquele repositório

Como prevenir: nome de skill de projeto com cara de projeto. Nada de deploy, build, test genérico competindo com a sua coleção pessoal

Vale lembrar que uma skill de qualquer nível também sobrepõe uma skill embutida de mesmo nome (os aliases da embutida continuam valendo), e que skill vence comando quando os dois têm o mesmo nome

Nome igual é sempre disputa. Nomes diferentes com propósitos parecidos são outra conversa, tipo escolher entre /goal e ultracode na hora de atacar uma tarefa

O subagente sumiu, ou virou outro

Sintoma: você chama o subagente pelo nome e vem um comportamento que não é o do arquivo que você abriu agora há pouco

Causa documentada: aqui a ordem é diferente da das skills. Definições gerenciadas (managed) vencem subagentes de projeto e de usuário com o mesmo nome, e entre diretórios aninhados do projeto vence a definição mais próxima do diretório de trabalho

Tem um caso mais silencioso ainda: se dois arquivos declaram o mesmo nome de subagente dentro do MESMO .claude/agents/, o Claude Code carrega apenas um deles, escolhido pela ordem de leitura do sistema de arquivos, sem precedência documentada

Ou seja, não existe regra pra você prever qual ganha 😅

O que fazer: rode /context e olhe a origem de onde cada subagente carregou. É ali que a dúvida morre

Como prevenir: um nome, um arquivo. Duplicata dentro da mesma pasta é sorteio, não configuração

A permissão que você liberou continua bloqueando

Sintoma: você adicionou a allow, salvou, e a ferramenta continua barrada

Causa documentada: regras deny são avaliadas antes das allow e valem de qualquer escopo. Se algo foi negado em um nível, nenhum outro nível consegue liberar, e um deny amplo bloqueia até uma allow mais específica

E tem mais: deny e ask continuam valendo mesmo quando um hook PreToolUse devolve allow

O que fazer: parar de empilhar allow e ir caçar o deny. Ele pode estar em outro arquivo de settings, em outro escopo

Como prevenir: usar deny com escopo apertado. Deny largo é fácil de escrever e chato de debugar depois

O hook está executando duas vezes

Sintoma: o mesmo script roda em duplicidade no mesmo evento

Causa documentada: hooks somam entre os níveis de settings em vez de substituir, e os que casam com o evento rodam em paralelo. Existe deduplicação, mas ela é parcial: se o mesmo handler está definido em mais de um arquivo de settings, ele roda uma vez só. Já a cópia do mesmo handler vinda de um plugin ou de uma skill continua sendo tratada como separada

O que fazer: abrir o /hooks e ver todo hook registrado na sessão, agrupado por evento. A duplicata aparece ali

Como prevenir: cuidado ao instalar plugin que traz o mesmo hook que você já mantém à mão. A dedupe não cruza essa fronteira

O hook que não desliga

Sintoma: você usou disableAllHooks e mesmo assim tem hook rodando

Causa documentada: o ajuste não desativa hooks vindos de managed settings quando acionado de fora dos managed settings

O que fazer: aceitar que aquele hook não é seu pra desligar e falar com quem gerencia a configuração

Como prevenir: saber de antemão o que na sua máquina é managed. Isso muda o que você consegue e o que você não consegue mexer

O MCP conectou no endpoint errado

Sintoma: o servidor está de pé, mas responde como se fosse outro ambiente

Causa documentada: servidores MCP se sobrepõem por nome na ordem local, projeto e usuário. Quando o mesmo servidor está definido em mais de um lugar, o Claude Code conecta uma vez só, usando a definição da fonte de maior precedência, e a entrada INTEIRA daquela fonte é usada. Os campos não são mesclados entre escopos

Ou seja, não existe aquele meio termo de "pega a URL de um e o token do outro"

O que fazer: o próprio Claude Code avisa do conflito quando o mesmo nome de servidor aparece em mais de um escopo com endpoints diferentes, tanto na saída de claude mcp list quanto no /mcp. Leia esse aviso, ele é literalmente a resposta

Como prevenir: nome de servidor com o ambiente embutido evita metade dessa dor

A instrução do CLAUDE.md que parece ignorada

Sintoma: você escreveu a regra, ela está lá, e o modelo faz diferente

Causa documentada: arquivos CLAUDE.md são aditivos. Todos os níveis contribuem conteúdo para o contexto ao mesmo tempo, os do diretório de trabalho e acima carregam na inicialização e os de subdiretórios carregam conforme você trabalha neles. Quando as instruções se contradizem, o Claude reconcilia por julgamento, e a instrução mais específica tende a prevalecer

O que fazer: procurar a instrução contrária em outro nível antes de reescrever a sua pela quinta vez

Como prevenir: menos texto, mais específico. Regra vaga em três arquivos diferentes é convite pro modelo escolher

A briga silenciosa: contexto consumido antes de você digitar

A outra frente de conflito não disputa nome nenhum

Ela disputa espaço

Antes de você digitar qualquer coisa, já estão no contexto o CLAUDE.md, a memória automática, os nomes das ferramentas de MCP e as descrições das skills

A sessão começa com o tanque parcialmente cheio, e você nem participou disso ainda

Onde isso pesa mais: servidores MCP carregam TODAS as ferramentas que oferecem para dentro do contexto por padrão, mesmo as que você não vai usar naquele projeto

E a saída das ferramentas também ocupa: o Claude Code avisa quando a saída de uma tool MCP passa de 10.000 tokens e limita em 25.000 tokens por padrão, com a variável de ambiente MAX_MCP_OUTPUT_TOKENS disponível pra aumentar esse limite

Agora a parte que engana de verdade

A listagem de nomes e descrições de skills tem orçamento de caracteres equivalente a 1% da janela de contexto do modelo

Quando essa listagem estoura, o Claude Code começa a descartar descrições, e o descarte começa pelas skills MENOS invocadas, mantendo o texto completo das mais usadas

Repare no efeito: a skill continua instalada, não dá erro nenhum, ela só some do radar

É o tipo de coisa que faz a pessoa reescrever a skill três vezes achando que o problema é a redação. Vale a pena pensar com calma em quantas skills manter ativas por sessão

Depois de um resumo de conversa também tem regra: o Claude Code reanexa a invocação mais recente de cada skill, mantendo os primeiros 5.000 tokens de cada uma, e as skills reanexadas dividem um orçamento combinado de 25.000 tokens

Prevenção que a própria documentação recomenda: manter o CLAUDE.md abaixo de 200 linhas, só com o essencial, e mover instrução especializada para skill, que carrega sob demanda

É contraintuitivo pra quem gosta de documentar tudo, mas faz sentido: memória é o que sempre está ligado, skill é o que acende quando precisa

Como auditar o que realmente carregou na sua sessão

Nada disso precisa ser adivinhação, beleza?

Existem quatro comandos de diagnóstico documentados, e juntos eles cobrem a sessão inteira

1. Rode /context e leia por categoria. Ele mostra tudo o que ocupa a janela da sessão atual: system prompt, ferramentas do sistema, ferramentas de MCP, subagentes customizados COM a origem de onde cada um carregou, arquivos de memória, skills e mensagens da conversa. O erro comum deste passo é olhar só o total e ignorar a origem dos subagentes, que é justamente onde mora a resposta do "por que veio outro"

2. Rode /hooks pra ver todo hook registrado na sessão, agrupado por evento. O erro comum deste passo é culpar o hook por um bloqueio que na verdade veio de um deny: deny e ask continuam valendo mesmo quando um hook PreToolUse devolve allow, então se a coisa está barrada, olhe permissão antes de mexer no script

3. Rode /mcp pra verificar o status dos servidores. É aqui e no claude mcp list que aparece o aviso quando o mesmo nome de servidor existe em mais de um escopo com endpoints diferentes

claude mcp list

O erro comum deste passo é ver o servidor conectado e dar por encerrado, sem conferir de qual escopo veio a definição que ganhou

4. Rode /doctor pra ver as entradas que o Claude Code rejeitou. O erro comum deste passo é pular ele: config que nem carregou não aparece brigando em lugar nenhum, ela simplesmente não existe na sessão, e você fica procurando conflito onde só tem ausência

Um quinto passo que é só cabeça, não comando: compare o que apareceu com o que você ACHA que instalou

A distância entre as duas listas costuma ser o post inteiro resumido 🙂

Convivência sem atrito: nomes, escopos e namespaces

A boa notícia é que boa parte da prevenção já vem pronta

Tem mecanismo desenhado justamente pra dois sistemas não pisarem no pé um do outro

• Skills de plugin são sempre namespaced, no formato plugin-name:skill-name, exatamente pra evitar conflito quando plugins diferentes têm skills de mesmo nome. O prefixo vem do campo name do plugin.json, então a invocação fica /nome-do-plugin:nome-da-skill
• Ferramentas de MCP recebem nome no formato mcp__<servername>__<toolname>, o que elimina colisão de nome de ferramenta entre servidores diferentes. Dois servidores com uma tool search não brigam, porque na prática nenhum dos dois se chama só search
• Plugin de mesmo nome em marketplaces diferentes se resolve pelo sufixo do marketplace na hora de instalar

/plugin install <nome>@claude-plugins-official

• O nome do plugin no marketplace pode divergir do nome declarado no plugin.json do próprio plugin, e isso já causou confusão. A partir da versão 2.1.195, enable e disable na interface /plugin funcionam para plugins com os dois nomes diferentes, e /plugin enable e /plugin disable aceitam qualquer um dos dois
• Plugins sincronizados do claude.ai aparecem como name@synced, funcionam com claude plugin enable/disable <name>@synced e nunca sobrepõem um plugin de mesmo nome que você instalou

Repare no padrão: onde a documentação conseguiu, ela transformou o conflito em prefixo

Onde não deu pra prefixar (skill, subagente, settings, MCP), sobrou precedência. E precedência é aquilo que você precisa saber de cor

Onde colocar cada coisa quando o time também usa

Escopo não é burocracia, é a ferramenta de convivência entre você e o repositório

O .claude/settings.json pode ser commitado, e aí todo mundo que clona o repositório recebe as mesmas permissões, hooks, telemetria e plugins

Cada pessoa sobrescreve por conta própria no seu .claude/settings.local.json, que é individual

É o mesmo espírito de um arquivo de configuração versionado com um override local por cima: se você já trabalhou assim em qualquer projeto, é exatamente essa a ideia

Pra MCP, o padrão é conservador: claude mcp add registra o servidor no escopo local, privado e ativo só no projeto atual

claude mcp add <nome> --scope project

O --scope user registra para todos os seus projetos, e o --scope project compartilha com o time

Tome cuidado com esse detalhe, porque é aqui que nasce o clássico "na minha máquina funciona": você adicionou no local, o colega clonou e não tem servidor nenhum

E tem o ~/.claude.json, que concentra a sessão de login, as configurações de servidores MCP, o estado por projeto (como decisões de confiança) e as chaves globais que o /config escreve

Saber que esse arquivo existe já evita um bom tanto de confusão sobre "onde diabos isso ficou salvo"

Conclusão

Dois sistemas convivem tranquilo no Claude Code, desde que você saiba UMA coisa sobre a camada em disputa: ela sobrepõe ou ela soma?

Skill, subagente, settings e MCP sobrepõem, cada um com sua ordem

Hook e CLAUDE.md somam

Permissão tem lei própria, e deny ganha de allow em qualquer escopo

Quase todo comportamento esquisito de sessão cheia é uma dessas regras funcionando como documentado, só que numa direção que você não esperava

Próximo passo é bem concreto: abra a sessão que você usa todo dia, rode /context, /hooks, /mcp e /doctor, e compare o que carregou com o que você acha que instalou

Se as duas listas baterem, parabéns, tá redondo

Se não baterem, você acabou de achar o conflito antes dele te achar 😀

até o próximo post!