VIPEntrar

Módulo 6 - Permissões e segurança

O controle fino: liberar, perguntar e bloquear

8 min de leitura · por Cesar Gargiulo, revisão editorial da equipe ValorFinal · Atualizado em 25/09/2026

O que você vai aprender

  • Diferenciar as regras de liberar, perguntar e bloquear.
  • Pré-aprovar ferramentas confiáveis para reduzir interrupções.
  • Bloquear o que nunca deve rodar, mesmo em modos soltos.
  • Entender que bloquear vence liberar.

Três tipos de regra sobre o modo

O modo define o comportamento geral, mas você pode afiná-lo com regras para ferramentas e comandos específicos. São três tipos. Liberar pré-aprova algo confiável, para o agente rodar sem perguntar mesmo no modo cauteloso, como o comando que roda os testes. Perguntar força a aprovação de algo delicado, mesmo quando o modo em geral não pediria, como qualquer acesso à internet. Bloquear impede de vez que uma ferramenta ou comando rode, valendo em todos os modos. Com essas três, você esculpe um Claude Code sob medida: menos interrupção no que é seguro, mais atrito no que é delicado, e portas fechadas para o que é proibido.

Diagrama com três caixas de regra sobre o comportamento do modo: liberar, com um sinal verde pré-aprovando o comando de testes; perguntar, com um sinal amarelo forçando aprovação para acesso à internet; e bloquear, com um sinal vermelho impedindo um comando destrutivo, com uma nota de que bloquear vence liberar.
Liberar, perguntar e bloquear: o controle fino que você coloca sobre o modo de permissão.

As regras ficam nos arquivos de configuração do Claude Code, os mesmos que você viu de leve no módulo de memória e que um módulo próprio vai detalhar. Cada regra nomeia uma ferramenta, e as de comando podem nomear até um padrão específico, como liberar só o comando de testes e não qualquer comando de terminal. Isso permite uma pontaria fina: você libera exatamente o que confia, sem abrir a porteira. Configurar isso uma vez para o seu projeto costuma valer muito, porque tira do caminho as aprovações repetitivas de coisas seguras, deixando a sua atenção para o que realmente importa.

Liberar com pontaria, não abrir a porteira

A tentação ao configurar regras de liberar é ser generoso demais, liberando tudo de uma categoria para nunca mais ser interrompido. É um erro clássico de segurança. Liberar qualquer comando de terminal, por exemplo, pré-aprova também os comandos perigosos, e você perde a rede de proteção justamente onde ela mais importa. O caminho seguro é a pontaria: libere comandos específicos e conhecidos, como o de rodar testes ou o de ver o status do controle de versão, e deixe o resto pedindo aprovação. Assim você ganha fluidez no que faz o tempo todo sem baixar a guarda no que pode dar errado.

Liberar sem pontaria (arriscado)

  • Liberar qualquer comando de terminal.
  • Liberar toda e qualquer escrita de arquivo em qualquer lugar.
  • Liberar tudo para nunca ser interrompido.

Liberar com pontaria (seguro)

  • Liberar só o comando de rodar os testes.
  • Liberar edições apenas dentro da pasta de trabalho.
  • Liberar o repetitivo e seguro; deixar o resto pedindo.

🎮 Jogo da aula

Boa regra de permissão?

Para cada afirmação sobre regras de permissão, diga se é verdadeira ou falsa.

Vale lembrar de onde vem essa fluidez sem risco: no módulo do fluxo agêntico você viu que ferramentas só de leitura já correm livres, e que comandos de terminal apenas de leitura também. As regras de liberar são para ir além disso, pré-aprovando ações que mudam algo mas que você considera seguras naquele projeto. Como são ações que alteram, o cuidado com a pontaria é maior. Um bom exercício ao configurar é perguntar, para cada regra de liberar, o que acontece de pior se isto rodar sem eu ver? Se a resposta assustar, a regra é ampla demais.

Bloquear o inegociável

Se as regras de liberar dão fluidez, as de bloquear dão paz. Elas impedem que uma ferramenta ou comando rode, e a força delas está em valerem em todos os modos, até nos mais automáticos. Isso as torna a defesa certa para o que é inegociável no seu projeto: comandos destrutivos que você nunca quer que o agente execute, acesso a arquivos sensíveis, qualquer coisa que, se rodasse por engano, causaria estrago sério. E aqui vale a regra que resolve conflitos: bloquear sempre vence liberar. Se por acaso uma regra ampla liberou algo e uma regra de bloquear o proibiu, a trava ganha, por segurança.

Um detalhe que dá tranquilidade extra: mesmo sem você configurar nada, o Claude Code já protege por conta própria um conjunto de caminhos sensíveis, como a pasta de controle de versão e a própria configuração dele, que nunca são alterados sem aprovação, salvo no modo sem freios. É o tema da próxima aula. Por ora, a mensagem é que você tem duas camadas de defesa: as proteções que a ferramenta já traz e as regras de bloquear que você adiciona para o seu contexto específico. Juntas, elas garantem que, por mais autonomia que você dê ao agente, existam linhas que ele simplesmente não cruza.

Teste rápido

Uma regra libera uma categoria ampla e outra regra bloqueia um comando específico dela. O que acontece com esse comando?

Perguntas frequentes

Onde ficam as regras de permissão?
Nos arquivos de configuração do Claude Code, os mesmos que guardam outras preferências e que um módulo próprio detalha. Cada regra nomeia uma ferramenta, e as de comando podem nomear um padrão específico. Você configura uma vez por projeto e colhe menos interrupções no seguro e mais atrito no delicado.
Liberar uma categoria inteira é má ideia?
Geralmente sim. Liberar toda uma categoria, como qualquer comando de terminal, pré-aprova também os comandos perigosos, e você perde a proteção onde mais importa. Prefira a pontaria: libere comandos específicos e conhecidos e deixe o resto pedindo aprovação. Pergunte-se o que aconteceria de pior se aquilo rodasse sem você ver.
As regras valem em todos os modos?
As de bloquear e as de perguntar sim, inclusive nos modos automáticos. As de liberar têm efeito nos modos que pediriam aprovação; no modo sem freios, como tudo já é liberado, elas não mudam nada, mas as de bloquear e perguntar continuam valendo. Por isso bloquear é a defesa mais confiável.
O que é bom candidato a bloquear?
Comandos destrutivos que você nunca quer que o agente rode, a leitura de arquivos com segredos como senhas e chaves, e qualquer ação difícil de desfazer. A regra de bloquear cria linhas que o agente não cruza em nenhum modo, o que traz tranquilidade mesmo quando você dá mais autonomia.
Preciso configurar regras para usar o Claude Code?
Não. Ele funciona bem sem nenhuma regra extra, com o comportamento do modo escolhido e as proteções que já traz. As regras são um refinamento: valem a pena quando você percebe aprovações repetitivas de coisas seguras ou quer travar algo específico do seu projeto. Comece simples e ajuste conforme a necessidade.

Fontes

Seu progresso fica salvo neste aparelho. Assinantes sincronizam entre os aparelhos.

← Os modos de permissão Concluir e avançar →