Auditando plugins do Claude Code antes de instalar o Marketplace oficial

O marketplace oficial de plugins do Claude Code da Anthropic deixou de ser um boato escondido em pastas de configuração. O repositório público no GitHub, anthropics/claude-plugins-official, tem mais de 30.000 estrelas em 17 de junho de 2026, e seu README descreve um diretório curado com plugins internos da Anthropic e entradas de terceiros. O mesmo README também traz a frase que deveria definir sua postura: “Make sure you trust a plugin before installing, updating, or using it”, porque a Anthropic não controla todos os servidores MCP, arquivos ou outras dependências empacotadas nesses plugins (GitHub).

Esse aviso não é juridiquês de rodapé. Um plugin do Claude Code pode empacotar comandos slash, skills, agentes, hooks, servidores MCP, servidores LSP, executáveis e configurações. Em termos simples de dev: ele pode adicionar contexto ao prompt, iniciar processos locais, chamar serviços remotos, executar hooks de shell em eventos do ciclo de vida e expor novas ferramentas ao modelo.

O modelo mental certo não é “instalar um tema de editor”. É “adicionar uma dependência que pode executar código perto da minha árvore de código-fonte”.

Esboço do fluxo de instalação de um plugin do Claude Code, do catálogo do marketplace ao cache local e aos componentes habilitados, com fou

O Marketplace É Real, Mas “Oficial” Não Quer Dizer “Seguro às Cegas”

A Anthropic anunciou plugins do Claude Code em 9 de outubro de 2025, descrevendo-os como coleções de comandos slash, agentes, servidores MCP e hooks instaláveis com /plugin (Claude blog). A documentação atual do Claude Code diz que o marketplace oficial da Anthropic, claude-plugins-official, fica disponível automaticamente quando o Claude Code inicia, e que você pode instalar um plugin com:

/plugin install github@claude-plugins-official

Se o plugin estiver faltando, a documentação manda atualizar o marketplace com:

/plugin marketplace update claude-plugins-official

ou adicioná-lo com:

/plugin marketplace add anthropics/claude-plugins-official

Esse é o caminho feliz oficial (Claude Code docs). Ele é útil. Também é incompleto como política operacional.

O arquivo de marketplace do repositório oficial aponta para uma mistura de diretórios locais de plugins e fontes externas fixadas por commit SHA. Por exemplo, entradas podem referenciar repositórios do GitHub, subdiretórios, refs e SHAs em .claude-plugin/marketplace.json (raw marketplace file). Fixar versões ajuda, mas não elimina a necessidade de inspecionar o que o código fixado faz. Um plugin ainda pode iniciar um servidor, pedir credenciais, executar hooks ou depender de um binário cujo comportamento muda fora do manifesto do marketplace.

A comunidade percebeu a mesma coisa. Em uma thread recente no r/ClaudeAI perguntando por plugins importantes do Claude Code, uma resposta recomendou primeiro CLAUDE.md e hooks, depois apenas servidores MCP específicos do projeto. Outra alertou para não “jogar conectores aleatórios” no Claude Code, porque eles custam tokens e podem poluir o contexto (Reddit). Esse é o debate prático agora: plugins são poderosos, mas cada capacidade extra vem com uma superfície de custo.

Comece Pelo Manifesto, Depois Leia o Repo

Seu primeiro alvo de auditoria é a fonte do plugin. Não instale a partir de snippets de busca, comandos copiados de blog ou agregadores aleatórios de marketplace até conseguir rastrear a origem até um repositório e um manifesto.

No repositório oficial do marketplace, verifique:

A entrada do marketplace em .claude-plugin/marketplace.json
O tipo de source, URL, path, ref e SHA
O .claude-plugin/plugin.json do plugin, se existir
Qualquer .mcp.json, .lsp.json, hooks/hooks.json, commands/, skills/, agents/, bin/ e scripts

A referência de plugins da Anthropic lista os caminhos principais dos componentes. Hooks vivem em hooks/hooks.json, servidores MCP podem viver em .mcp.json, executáveis podem viver em bin/, e manifestos de plugin podem apontar para locais customizados de componentes (Claude Code plugin reference). Isso significa que “eu conferi o plugin.json” não basta. Um plugin pode depender de caminhos de descoberta padrão.

Uma revisão manual rápida fica assim:

git clone https://github.com/OWNER/PLUGIN-REPO /tmp/plugin-audit
cd /tmp/plugin-audit

find . -maxdepth 3 \( \
  -name plugin.json -o \
  -name hooks.json -o \
  -name .mcp.json -o \
  -name .lsp.json -o \
  -path "*/bin/*" -o \
  -path "*/scripts/*" \
\) -print

rg -n "curl|wget|bash|sh -c|chmod|open |xdg-open|osascript|token|api_key|secret|eval|exec|spawn|subprocess"

Esse comando rg é bruto, mas aqui bruto é bom. Você está procurando surpresas na instalação, execução de shell, abertura de navegador, downloads remotos, tratamento de credenciais e scripts que alteram seu repositório ou diretório home.

Minha regra: se um plugin precisa de um script de shell para fazer seu trabalho principal, quero entender cada comando desse script antes de instalar. Se ele baixa outro artefato em runtime, trato esse artefato de runtime como parte do plugin.

Servidores MCP São a “Conveniência” Mais Cara

MCP é onde a conveniência de um plugin pode virar custo escondido. A documentação de MCP da Anthropic diz que servidores MCP definidos por plugins iniciam automaticamente quando o plugin é habilitado, e que ferramentas MCP de plugins aparecem junto das ferramentas MCP configuradas manualmente (Claude Code MCP docs). A documentação também diz que servidores MCP de plugins usam as mesmas variáveis de ambiente dos servidores configurados manualmente, o que importa se seu shell exporta tokens de cloud, URLs de banco de dados ou credenciais de serviços internos.

A reclamação da comunidade é específica: schemas de ferramentas MCP podem comer contexto antes mesmo de você chamar uma ferramenta. Em uma thread do r/ClaudeCode sobre overhead de tokens, usuários apontaram plugins desabilitados e a ausência de servidores MCP pesados como provável motivo para menor queima de tokens, e um comentarista chamou schemas de ferramentas MCP de “um enorme custo escondido” (Reddit). Em outra thread, um comentarista afirmou que servidores MCP conectados registram schemas de ferramentas no contexto e recomendou podar servidores por sessão (Reddit).

Trate estimativas exatas de tokens no Reddit como anedóticas, a menos que você as reproduza no seu próprio setup. A direção geral continua correta: um servidor sempre ligado, com muitas ferramentas verbosas, não sai de graça.

Use esta tabela de decisão antes de instalar um plugin estilo conector:

Necessidade	Padrão mais seguro	Use MCP quando
Executar operações no GitHub	CLI `gh` via Bash	Claude precisar navegar por issues, PRs e metadados interativamente
Consultar um banco de dados	CLI somente leitura ou script local	Claude precisar de chamadas de ferramenta estruturadas com credenciais escopadas
Inspecionar recursos de cloud	CLI do fornecedor com comandos explícitos	O servidor MCP tiver permissões estreitas e logs de auditoria claros
Buscar documentação	Docs estáticos, arquivos do repo ou links web	Os recursos forem grandes, dinâmicos e consultados com frequência
Aplicar política	Hook `PreToolUse`	A decisão precisar de contexto visível ao Claude ou metadados de ferramenta

Uma ferramenta de CLI costuma ser mais segura porque só é invocada quando necessária e só produz saída para aquele turno. MCP pode ser mais seguro quando oferece OAuth escopado, ferramentas tipadas e logs de auditoria. O erro é instalar MCP por reflexo.

Gráfico compacto comparando ferramentas de CLI versus servidores MCP em quatro linhas: custo de contexto, superfície de permissão, setup

Hooks Merecem Sua Própria Revisão de Segurança

Hooks são o recurso que faz plugins parecerem mágicos. Também são o recurso que eu audito com mais rigor.

Hooks do Claude Code podem rodar em eventos como SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, PreCompact e SessionEnd. A referência de plugins diz que os tipos de hook incluem command hooks, HTTP hooks, MCP tool hooks, prompt hooks e agent hooks (Claude Code plugin reference). O guia de hooks explica que um hook PreToolUse pode bloquear uma ação saindo com código 2, enquanto o stdout de UserPromptSubmit, UserPromptExpansion e SessionStart pode ser adicionado ao contexto do Claude (Claude Code hooks guide).

É muito poder.

Um bom hook bloqueia comportamento perigoso ou adiciona contexto compacto e determinístico. Um hook ruim transforma todo prompt em um pipeline RAG caro, vaza texto do prompt para um endpoint HTTP ou muda silenciosamente seu ambiente.

Audite hooks com quatro perguntas:

Qual evento dispara isso?
Qual matcher limita isso?
Quais dados isso recebe?
O que isso escreve em stdout, stderr, disco, rede ou contexto?

A comunidade está dividida aqui de um jeito útil. Em uma thread do r/ClaudeCode sobre hooks, alguns desenvolvedores descrevem hooks como a única forma confiável de aplicar regras, bloquear ações ruins de git ou lembrar o Claude de escrever memória. Outros estão criando fluxos elaborados de memória e RAG em UserPromptSubmit (Reddit). Ambos podem ser válidos. A diferença está no orçamento e no raio de explosão.

Para instalações em equipe, eu liberaria hooks de política antes de hooks de injeção de contexto. Um hook PreToolUse que bloqueia padrões rm -rf é fácil de raciocinar. Um hook UserPromptSubmit que busca e injeta memória a cada turno precisa de medições, limites e donos claros.

Instale de Forma Restrita, Meça, Depois Promova

O Claude Code oferece escopos de plugin de usuário, projeto, local e gerenciado. A documentação descreve o escopo de usuário como pessoal entre projetos, o escopo de projeto como compartilhado por .claude/settings.json, e o escopo local como específico do projeto, mas não compartilhado (Claude Code docs).

Use esses escopos como mecanismo de rollout:

Instale localmente primeiro.
Rode uma tarefa real.
Confira os detalhes em /plugin e /mcp.
Use /context e /usage antes e depois.
Desabilite qualquer coisa que não se pague.
Promova para escopo de projeto só depois da revisão.

A documentação agora diz que o painel de detalhes do plugin pode mostrar estimativas de custo de contexto no Claude Code v2.1.143 e posterior, datas da última atualização no v2.1.144 e posterior, e um inventário “Will install” no v2.1.145 e posterior (Claude Code docs). Use esse inventário antes de apertar instalar. Se um plugin diz ser um formatador, mas instala um servidor MCP, um hook e um monitor em background, pare e inspecione.

Também preste atenção nas atualizações automáticas. A Anthropic diz que marketplaces oficiais têm auto-update habilitado por padrão, enquanto marketplaces de terceiros e locais ficam desabilitados por padrão. A documentação também descreve DISABLE_AUTOUPDATER e FORCE_AUTOUPDATE_PLUGINS para controlar o comportamento de atualização (Claude Code docs). Auto-update é conveniente para correções de segurança, mas muda sua cadeia de suprimentos em runtime. Para equipes reguladas, fixe versões do marketplace em um marketplace interno revisado em vez de deixar cada laptop divergir por conta própria.

Mockup de dashboard de auditoria antes e depois, mostrando o inventário de plugins instalados encolhendo de muitos servidores MCP e hooks para

O Checklist Que Eu Uso Antes de Instalar

Aqui vai a versão curta que eu daria a qualquer dev em uma equipe usando Claude Code.

Fonte:

O marketplace é anthropics/claude-plugins-official, um repo interno ou um repo de terceiros?
A fonte do plugin está fixada em um SHA?
A homepage bate com o dono da fonte?
O repo tem mudanças recentes inesperadas, blobs gerados ou scripts de instalação?

Componentes:

Ele adiciona servidores MCP?
Ele adiciona hooks?
Ele adiciona executáveis em bin/?
Ele adiciona agentes que podem chamar ferramentas?
Ele adiciona servidores LSP que exigem binários locais?

Permissões:

Quais credenciais ele pede?
Valores sensíveis são armazenados via userConfig do plugin como campos sensíveis?
O servidor MCP recebe acesso somente leitura ou de escrita?
Algum hook “telefona para casa” via HTTP?
Algum script herda variáveis de ambiente amplas?

Custo:

O que /plugin reporta como custo de contexto?
O que muda em /context depois de habilitar?
O plugin agrega valor em toda sessão ou só em fluxos raros?
Um comando de CLI poderia produzir o mesmo resultado com menos contexto persistente?

Operações:

Você consegue desabilitar limpo com /plugin disable name@marketplace?
Você consegue desinstalar limpo?
Ele deixa configuração, credenciais, daemons, caches ou autenticação de navegador para trás?
Quem é dono das atualizações?
O que quebra se a fonte do plugin desaparecer?

A resposta opinativa: instale menos plugins do que você quer. Prefira plugins pequenos e sem graça que adicionam um fluxo de trabalho. Prefira CLIs para operações pontuais. Use MCP quando o servidor for escopado, auditado e realmente interativo. Use hooks para guardrails, não como depósito de toda preferência que você gostaria que o modelo lembrasse.

Plugins estão virando o formato de pacote do Claude Code para fluxos de trabalho. Isso é bom. Significa que equipes podem compartilhar setups repetíveis em vez de folclore tribal de prompts. Mas o formato de pacote é poderoso o suficiente para merecer revisão de dependências, revisão de permissões e revisão de custo. Se você não rodaria curl | bash para colocar uma ferramenta no seu repo sem ler antes, não instale a versão em plugin só porque ela aparece numa UI amigável de marketplace.

Rodapé discreto: Se quiser testar o Claude Fable 5 por conta própria, você pode usá-lo via Claude Fable 5 on OneHop, um endpoint drop-in com preço cerca de 30% abaixo da tabela. Novas contas podem começar com US$ 10 grátis, sem cartão.

Leitura adicional: Primeiros passos com Claude Fable 5.