Como pedir ao Claude Code para resolver a tarefa sem instalar biblioteca nova

Você pede uma coisa simples, deixa claro que não quer dependência nova, e volta um npm install no meio do diff 😅

Isso não é birra do modelo, é peso de contexto: um "não instale nada" enfiado na última linha de um pedido longo tem pouquíssima força perto de tudo que veio antes

E tem um detalhe que quase ninguém pensa: mesmo que ele obedeça agora, na próxima sessão essa instrução simplesmente não existe mais

Por isso a solução aqui vem em três camadas: COMO escrever a restrição, ONDE fixar ela pra valer em toda sessão, e como travar de verdade quando escrever não basta

Bora montar as três?

O que você precisa antes de começar

• Claude Code rodando em sessão interativa, que é onde o Esc interrompe o turno em andamento
• Saber onde mora o arquivo de memória do projeto: ./CLAUDE.md ou ./.claude/CLAUDE.md
• Saber onde mora o seu, de usuário: ~/.claude/CLAUDE.md
• Acesso ao settings.json: o ~/.claude/settings.json vale pra todos os projetos, e o .claude/settings.json dentro do projeto vale só pra aquele projeto e é compartilhado com o time

Ainda não tem CLAUDE.md nenhum? Roda /init, que ele gera um inicial a partir da estrutura atual do projeto, pra você refinar depois

E se você nem sabe quais arquivos de memória estão ativos aí, o /memory lista e abre esses arquivos (CLAUDE.md, CLAUDE.local.md e outros) nos escopos de usuário e de projeto, sem sair da sessão

Se o seu problema ainda é anterior a tudo isso e o CLI nem sobe direito, dá uma passada nos erros comuns ao instalar o Claude Code antes de continuar

Formação Recomendada

Formação Claude Code

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

• 116 aulas
• 4 projetos
• 9h 23min

Conhecer formação

Passo a passo para resolver a tarefa sem instalar biblioteca nova

1. Escreva a restrição no começo do prompt, e de um jeito verificável

Restrição negativa solta some no meio do texto

O truque é transformar "não instale nada" em uma AÇÃO que dá pra conferir: primeiro ele lista o que já existe, depois ele resolve dentro dessa lista

Antes de propor qualquer solução, liste as dependências que já existem no manifesto do projeto.
Resolva a tarefa usando apenas o que está nessa lista.
Se achar que precisa de algo fora dela, pare e me explique o porquê, sem instalar.

Tarefa: <descreva aqui>

O erro comum deste passo: jogar o "não instale nada" na última linha de um pedido gigante, no meio de outras cinco condições

2. Peça o plano antes do código

O Shift+Tab alterna o plan mode, e o /plan como prefixo vale pra um único prompt

Em plan mode ele lê arquivos e responde sem alterar nada, e as edições ficam bloqueadas até você aprovar o plano (exceto em sessões com bypass de permissões)

Ou seja: é exatamente onde você descobre que ele planejou instalar uma lib ANTES de ele instalar

Se quiser sair sem aprovar nada, Shift+Tab de novo

O erro comum deste passo: aprovar o plano no automático, sem ler a parte em que ele cita as dependências que pretende usar

3. Interrompa cedo, com Esc

A documentação oficial recomenda corrigir o Claude assim que ele sai do trilho, porque ciclo curto de feedback dá resultado melhor do que deixar a resposta seguir errada e refazer depois

Então, na primeira linha do plano que citar biblioteca nova, Esc e reescreve o pedido

O erro comum deste passo: mandar mensagem enquanto ele está trabalhando achando que isso interrompe

Não interrompe, a mensagem entra na FILA

(e se você se arrepender, a seta pra cima na primeira linha do campo de entrada devolve as mensagens enfileiradas pra edição)

4. Tire a regra do prompt e bote no CLAUDE.md do projeto

O Claude Code lê os arquivos CLAUDE.md no início de cada sessão, em escopos hierárquicos: política gerenciada da organização, usuário em ~/.claude/CLAUDE.md e projeto em ./CLAUDE.md ou ./.claude/CLAUDE.md

Escreveu uma vez, vale sempre

## Dependências

Não adicionar dependência nova sem aprovação explícita minha.
Resolver a tarefa com o que já está declarado no manifesto do projeto.
Se uma dependência parecer inevitável, propor e esperar resposta antes de instalar.

E se isso for uma manha sua e não uma regra do time? Existe o CLAUDE.local.md na raiz do projeto, pra preferência pessoal que não deve ir pro controle de versão, carregado junto com o CLAUDE.md e tratado da mesma forma

Dá pra manter um arquivo único de instruções e importar de qualquer ponto do CLAUDE.md com a sintaxe @, inclusive apontando pra fora do projeto:

@~/.claude/minhas-instrucoes.md

O erro comum deste passo: encher o CLAUDE.md do que ele já deduz lendo o código

A própria doc é bem direta no que entra e no que fica de fora

"Não adicionar dependência sem aprovação" é regra que diverge do padrão, então ela merece o arquivo 👍

5. Trave de verdade com uma regra deny

As permissões do Claude Code valem pra Bash, Read, Edit, WebFetch, MCP e demais ferramentas, com regras allow, ask e deny

O deny bloqueia o uso da ferramenta, ponto

A ordem de avaliação é deny, depois ask, depois allow, e a primeira correspondência decide, independentemente de qual regra é mais específica

Sobre o formato: a documentação descreve o padrão de curinga em geral, com exemplo em ls, e o sufixo :* é equivalente a escrever espaço seguido de asterisco

Ou seja, Bash(ls:) casa os mesmos comandos que Bash(ls )

A regra do SEU instalador é você que escreve, seguindo esse mesmo padrão, dentro do settings.json:

{
  "permissions": {
    "deny": [
      "Bash(npm install:*)"
    ]
  }
}

O erro comum deste passo: não sacar o que o espaço faz

Bash(ls ) exige espaço depois de ls, então lsof não casa, enquanto Bash(ls) casaria lsof também

Um caractere muda a mira inteira da regra, se liga nisso

Se você não quer bloqueio seco e sim um pedágio, usa ask: ele pede confirmação mesmo em modos que aprovariam sozinhos, como acceptEdits ou bypassPermissions (e no modo dontAsk uma regra ask nega em vez de perguntar)

Tome cuidado pra não misturar as coisas aqui: permissão negada pelo Claude Code é uma história, e erro de permissão do npm na hora de instalar o próprio CLI é outra completamente diferente

6. Camada final pra quem quer garantia: hook PreToolUse

Os hooks PreToolUse rodam ANTES da checagem de modo de permissão, em todos os modos

Um hook que devolve permissionDecision igual a "deny" cancela a chamada da ferramenta e manda o permissionDecisionReason de volta pro Claude, inclusive no modo bypassPermissions e com --dangerously-skip-permissions

Sacou a diferença? A regra de permissão é a porta, o hook é o segurança que fica antes da porta

Tem também o caminho do código de saída: sair com código 2 é erro bloqueante e para a chamada antes das regras de permissão serem avaliadas, e nesse caso o JSON de saída é ignorado

Os detalhes de formato estão na documentação de hooks

"E o sandbox, não resolve isso?"

Ele aplica restrição de sistema operacional ao sistema de arquivos e à rede, mas só pra ferramenta Bash e seus processos filhos: ferramentas em processo, como WebFetch, continuam seguindo as regras de permissão

Então trate o sandbox como reforço, não como substituto das camadas de cima

Recapitulando o que cada camada te dá:

E quando ele insiste que a biblioteca é necessária?

Tem hora que a resposta volta batendo o pé

Três cenários que aparecem sempre, com causa e saída

Sintoma: "não dá pra fazer isso sem a lib"

Causa provável: o pedido está vago demais sobre o que JÁ existe no projeto, então ele completa o buraco com a solução mais óbvia do mundo, que é instalar algo

Solução: quebre em dois turnos

Primeiro só o inventário ("liste o que já está declarado no manifesto e o que dá pra reaproveitar pra essa tarefa"), depois a implementação em cima dessa lista

Sintoma: ele concorda com a regra e instala mesmo assim, três mensagens depois

Causa: a restrição existia só no prompt daquele turno

Conversa longa, contexto novo entrando, e aquilo virou detalhe antigo

Solução: sobe a regra pro CLAUDE.md (passo 4) e coloca a regra de permissão por cima (passo 5)

O que está escrito no arquivo ele relê no início de cada sessão, e o que está no deny não depende de ele lembrar de nada

Sintoma: a proposta com dependência é, honestamente, a melhor

Acontece, e negar isso é dogma

Solução: peça os dois caminhos lado a lado, no mesmo plano

Quanto custa escrever à mão (quantos arquivos, o que precisa ser testado) contra o que exatamente a lib resolve

Com o plan mode ligado ele lê e responde sem alterar nada, então você decide com o diff ainda parado 🙂

Pra prevenir tudo isso, o combo é simples: regra escrita uma vez no arquivo, deny no instalador e leitura do plano antes de aprovar

O que mudou aqui depois que a regra saiu do prompt e virou arquivo

Eu testei essa ideia de "instrução em arquivo" num projeto meu de gestão de produtos, um CRUD bem simples de itens, só pra ver o comportamento na prática

Sem esse tipo de instrução, o padrão que eu vejo é sempre o mesmo: a IA assume coisas por conta própria, mexe em arquivo que não precisava, entrega código mais complicado que o necessário e ainda diz que está pronto sem ter testado

O clássico é o escopo escapando: você pede UMA mudança, ela altera outros arquivos, arruma uma coisa e quebra outra

Com o arquivo de instruções ativo, a coisa muda de figura: ela passa a focar em código mínimo, mudando ou adicionando só o que resolve o problema pedido, e define critério de sucesso antes de executar

No teste, o prompt foi adicionar um botão de exportar CSV na tabela de produtos, exportando só os produtos visíveis e filtrados

Tarefa clara, então ela foi direto pra execução, sem perguntar nada

No fim veio um relatório do que foi alterado, incluindo a checagem de que as colunas exportadas batiam com as colunas visíveis da tabela: nome, categoria, preço, estoque e status

Abri o CSV gerado no editor e os produtos eram exatamente os que eu queria 👌

Repara que isso é justamente o tipo de coisa que vale estar no arquivo: quais colunas contam como "certo" nesse projeto é uma armadilha não óbvia, não é algo que ele adivinha lendo o código

Depois eu forcei um segundo teste com um prompt propositalmente vago, pedindo um sistema de autenticação no projeto

Aí ela parou ANTES de codar pra alinhar as escolhas, dizendo que autenticação tem várias formas e cada uma muda bastante o código

E entre as perguntas apareceram escolhas de biblioteca

Ou seja: decisão que muda escopo virou pergunta em vez de suposição, que é exatamente o comportamento que a gente está perseguindo neste post inteiro

Essa etapa de perguntas não é obrigatória, viu? Se o prompt for claro, ela resolve direto, o que poupa tempo e evita pergunta desnecessária

Dois avisos honestos: a demonstração principal foi simples e não exigiu questionamento nenhum, por isso precisei do prompt vago pra provocar as perguntas, e eu deixei aquilo instalado só no projeto de teste, não de forma global, pra manter o ambiente limpo enquanto avaliava

O ganho prático que sobrou pra mim foi economia de tokens e chegar no objetivo mais rápido, com menos idas e vindas

No vídeo acima eu mostro esses dois testes na tela: o pedido do CSV indo direto pra execução, o relatório final com a conferência das colunas, e o prompt vago fazendo a IA parar pra perguntar antes de escrever qualquer linha

Quando segurar a restrição e quando abrir mão dela

Restrição vira dogma rapidinho, e aí atrapalha mais do que ajuda

Onde segurar firme:

• Projeto legado com build frágil: se o build já é aquele castelinho, cada dependência nova é uma chance de derrubar tudo por um motivo que não tem nada a ver com a sua tarefa
• Biblioteca compartilhada: aqui cada dependência sua vira peso pra todo mundo que consome o seu pacote, então o custo não é seu, é do time inteiro
• Exercício de aprendizado: se o objetivo é você entender a lógica, deixar a lib resolver mata o exercício, e aí o deny no instalador é literalmente a regra do jogo
• Ambiente com aprovação de dependência: onde entra pacote novo só com revisão, o agente instalando sozinho só te dá retrabalho depois

Onde abrir mão sem culpa:

• Criptografia: escrever isso à mão é o tipo de economia que sai caríssima
• Parsing de formato complexo: os casos de borda são um poço sem fundo
• Data, hora e fuso horário: já me ferrei uma vez achando que era só somar segundos, não é 😅

A régua que eu uso é essa: a restrição serve pra proteger o projeto, não pra provar ponto

Se a dependência resolve um problema que ninguém quer manter à mão, o certo é aprovar de forma consciente, com o plano na tela, e não deixar acontecer de surpresa

Conclusão

A restrição só vale o que está escrito em algum lugar que o agente REALMENTE lê

No prompt ela dura um turno

No CLAUDE.md ela volta no início de cada sessão

No deny do settings.json e no hook PreToolUse ela deixa de depender de o modelo lembrar de qualquer coisa

Próximo passo, e dá pra fazer hoje: roda /memory, abre o CLAUDE.md do projeto, escreve as três linhas da regra de dependência e testa no próximo pedido com o plan mode ligado

Se ele citar uma lib nova no plano, você vê antes de qualquer arquivo ser tocado, e é esse o jogo todo

até o próximo post! 😀