Permissões do Claude Code: como proteger projetos .NET
As permissões do Claude Code definem o que o agente pode fazer sozinho, o que precisa da sua aprovação e o que nunca pode acontecer no seu projeto. Com o auto mode como padrão, essas regras deixaram de ser um detalhe de configuração e passaram a ser a principal forma de manter o controle de um repositório .NET.
Este artigo usa como base um relato prático publicado pelo Round The Code. Nele, o autor configura regras ask e deny em um projeto ASP.NET Core com EF Core e descobre, na prática, qual arquivo de configuração vence quando as regras entram em conflito.
O que são as permissões do Claude Code
O Claude Code é um agente que lê arquivos, edita código e executa comandos no terminal. Por isso, cada ação com efeito no sistema passa pelas permissões do Claude Code antes de rodar.
As permissões do Claude Code se dividem em três listas de regras. A lista allow libera uma ferramenta sem aprovação, a lista ask exige confirmação a cada uso e a lista deny bloqueia a ferramenta.
Um ponto importante é que o próprio Claude Code aplica as regras de permissões, e não o modelo. Em outras palavras, as instruções do seu prompt ou do CLAUDE.md moldam o que o Claude tenta fazer, mas não mudam o que a ferramenta permite.
Essa diferença tem impacto direto no dia a dia. Uma frase no CLAUDE.md como "nunca rode migrations" funciona como orientação, enquanto uma regra deny funciona como bloqueio de fato.
Se você ainda está montando o CLAUDE.md do seu projeto, vale ler também como otimizar o Claude com .NET antes de seguir.
Por que pular as permissões é arriscado
Antes do auto mode, quem se cansava dos prompts de aprovação costumava iniciar o Claude Code com o parâmetro --dangerously-skip-permissions. Com ele, todos os prompts desaparecem de uma vez.
O problema é o tamanho da porta que se abre. Nesse modo, o agente pode apagar qualquer arquivo, executar qualquer comando e até alterar arquivos fora da pasta do projeto.
De fato, o Claude Code ainda pede confirmação antes de apagar a raiz do sistema ou o diretório home. No entanto, a maior parte dos comandos passa direto, sem nenhuma revisão.
A própria documentação recomenda usar esse modo apenas em ambientes isolados, como contêineres ou máquinas virtuais. Ou seja, é acesso demais apenas para economizar alguns cliques.
Como o auto mode funciona
Em agosto de 2026, o auto mode virou o modo padrão do Claude Code nos planos Pro, Max e Team. Ele fica no meio do caminho entre aprovar cada ação e não aprovar nada.
Nesse modo, um segundo modelo, chamado classificador, revisa ações como comandos de shell e requisições web antes da execução. Assim, ele funciona como uma segunda opinião sobre cada passo do agente.
Por outro lado, edições de arquivos dentro do projeto e comandos somente leitura rodam sem essa checagem. Já as ações mais arriscadas ficam bloqueadas.
Entre essas ações bloqueadas estão descartar alterações não commitadas, apagar arquivos que existiam antes da sessão e fazer deploy em produção. Portanto, o auto mode é bem mais seguro do que pular as permissões.
Ainda assim, ele transfere para uma IA a decisão sobre o que é seguro e o que é perigoso no seu projeto. É exatamente esse ponto que as permissões do Claude Code resolvem quando você escreve as regras.
Onde o auto mode falha em projetos .NET
O classificador procura ações perigosas. Contudo, os dois problemas relatados no artigo original não eram perigosos, e sim incômodos e disruptivos para o fluxo de trabalho.
Migration do EF Core escrita à mão
O autor pediu ao Claude Code para adicionar uma migration do EF Core. Em vez de usar a linha de comando, o agente escreveu o arquivo da migration manualmente.
Na revisão, o código parecia correto. No entanto, ao atualizar o banco de dados, surgiu um erro, e a solução foi apagar a migration e gerá-la de novo pelo comando.
Isso acontece porque o comando dotnet ef migrations add faz mais do que criar uma classe. Segundo a documentação do EF Core, ele compara o modelo atual com um snapshot do modelo anterior e atualiza esse snapshot junto com a migration.
Uma migration escrita à mão pula essa comparação. Dessa forma, o snapshot fica dessincronizado e os próximos comandos do EF Core podem falhar.
Aplicação rodando em segundo plano
No segundo caso, o Claude Code fazia ajustes de CSS em um site ASP.NET Core MVC. Enquanto editava os arquivos, o agente mantinha o site rodando em segundo plano.
Quando o autor tentou iniciar o site pelo Visual Studio, recebeu um erro dizendo que a aplicação já estava em execução. Nada quebrou, mas a situação gerou desconforto.
Afinal, um agente de IA estava executando o site sem que o desenvolvedor tivesse pedido isso. Além disso, não havia garantia de que ele encerraria o processo quando solicitado.
Como configurar as permissões do Claude Code em um projeto .NET
Para configurar as permissões do Claude Code no projeto, crie um arquivo settings.json dentro da pasta .claude na raiz do repositório. Esse arquivo pode ir para o controle de versão, então todo o time passa a seguir as mesmas regras.
O exemplo abaixo resolve os dois problemas descritos acima. Ele pede aprovação para comandos sensíveis e bloqueia o que nunca deve rodar sem um humano.
{
"permissions": {
"ask": [
"Bash(dotnet ef migrations add *)",
"Bash(dotnet run *)",
"Bash(dotnet watch *)",
"Bash(run_in_background:true)"
],
"deny": [
"Edit(**/Migrations/**)",
"Bash(dotnet ef database update *)"
]
}
}
Regras ask para comandos sensíveis
A lista ask reúne os comandos que o agente só executa depois da sua confirmação. Nesse caso, ela cobre a criação de migrations e a execução da aplicação com dotnet run e dotnet watch.
A regra Bash(run_in_background:true) merece atenção especial. Ela usa a correspondência por parâmetro, que verifica um campo da chamada da ferramenta em vez do texto do comando.
Com isso, qualquer comando que o Claude Code tente rodar em segundo plano passa a pedir aprovação. Na prática, essa regra elimina a surpresa do site rodando sem aviso.
Regras deny para o que nunca deve rodar
A lista deny define o que o agente não pode fazer de forma alguma. A regra Edit(**/Migrations/**) impede qualquer edição dentro de pastas Migrations, em qualquer profundidade.
Assim, o agente perde a opção de escrever a migration à mão e precisa usar o comando oficial. Como esse comando está na lista ask, você ainda revisa cada execução.
Já a regra Bash(dotnet ef database update *) bloqueia a atualização do banco pelo agente. Desse modo, a alteração de schema continua sendo uma decisão humana.
Vale um detalhe para quem usa o EF Core 11. A versão trouxe a opção --add, que cria e aplica uma migration em um só passo, e essa regra também a bloqueia, porque o comando começa com dotnet ef database update.
Sintaxe das regras de permissões no Claude Code
As regras de permissões do Claude Code seguem o formato Tool ou Tool(specifier). Um nome de ferramenta sozinho, como Bash, cobre todos os usos dessa ferramenta.
Nas regras Bash, o asterisco substitui qualquer trecho de texto, inclusive espaços. Por exemplo, Bash(dotnet run *) cobre dotnet run, dotnet run --project src/Api e variações parecidas.
A documentação oficial de permissões recomenda colocar o asterisco depois do subcomando. Afinal, Bash(dotnet *) liberaria ou bloquearia todos os comandos do .NET, e não só o que você pretendia.
O sufixo :* é uma forma equivalente de escrever o curinga final. Portanto, Bash(dotnet run:*) e Bash(dotnet run *) cobrem exatamente os mesmos comandos.
As regras Edit e Read usam a sintaxe de padrões do gitignore. Nesse formato, * casa com um único segmento do caminho, enquanto ** atravessa diretórios.
| Regra | O que faz |
|---|---|
Bash(dotnet test *) |
Cobre qualquer execução de dotnet test |
Edit(**/Migrations/**) |
Cobre edições em qualquer pasta Migrations |
Read(./.env) |
Cobre a leitura do arquivo .env na pasta atual |
Bash(run_in_background:true) |
Cobre comandos executados em segundo plano |
Testando as regras ask e deny
Com o arquivo pronto, o autor pediu de novo para o Claude Code adicionar uma migration. Dessa vez, o agente pediu permissão para rodar dotnet ef migrations add e avisou que a regra ask sobrepunha o auto mode para esse comando.
Em seguida, o CLAUDE.md do projeto mandava o agente rodar a aplicação após cada alteração. Quando ele tentou fazer isso, também pediu permissão primeiro.
Esse teste mostra que as permissões do Claude Code definidas no arquivo vêm antes do classificador. Ou seja, uma regra ask continua pedindo confirmação mesmo com o auto mode ativo.
Depois, o autor pediu para atualizar o banco de dados com a nova migration. Como o comando estava na lista deny, o agente recusou a tarefa e citou a regra exata do .claude/settings.json.
Além disso, o Claude Code sugeriu dois caminhos. O primeiro era rodar o comando manualmente, e o segundo era mover a regra da lista deny para a lista ask.
Hierarquia dos arquivos de configuração
O Claude Code lê as permissões de três arquivos de configuração no dia a dia do desenvolvedor. Cada um tem um escopo diferente.
| Arquivo | Escopo |
|---|---|
.claude/settings.local.json |
Pessoal, dentro do projeto e fora do controle de versão |
.claude/settings.json |
Compartilhado com o time pelo repositório |
~/.claude/settings.json |
Pessoal, vale para todos os projetos da máquina |
Na maioria das configurações, o arquivo local tem prioridade sobre o do projeto, que por sua vez tem prioridade sobre o do usuário. Acima de todos ficam as configurações gerenciadas, que as empresas distribuem e que nenhum outro nível consegue sobrescrever.
Também vale saber que, ao escolher a opção de não perguntar de novo em um prompt, o Claude Code grava a regra no settings.local.json. Por isso, esse arquivo costuma acumular regras que você nem lembra de ter criado.
Contudo, as permissões do Claude Code não seguem essa ordem de prioridade da forma que muita gente espera. É aqui que o relato original traz a lição mais valiosa.
Por que a regra deny sempre vence nas permissões do Claude Code
Enquanto escrevia o artigo, o autor percebeu que o Claude Code não conseguia mais rodar a aplicação. Na investigação, ele encontrou uma regra deny para dotnet run no arquivo ~/.claude/settings.json, esquecida de um teste anterior.
{
"permissions": {
"deny": [
"Bash(dotnet run *)"
]
}
}
O próprio agente sugeriu adicionar Bash(dotnet run:*) à lista allow do projeto. O autor seguiu a sugestão, mas o comando continuou bloqueado.
Ao pedir para o Claude Code revisar todos os arquivos, a explicação apareceu. As permissões do Claude Code combinam as regras de todos os arquivos, e a avaliação segue sempre a ordem deny, depois ask e por fim allow.
A primeira regra que casa nessa ordem decide o resultado, e a especificidade da regra não muda nada. Assim, um allow no projeto nunca derruba um deny no arquivo do usuário, e o contrário também vale.
O agente ainda apontou um segundo detalhe. O settings.local.json tinha dotnet run na lista ask, e quando ask e allow casam com o mesmo comando, o ask vence.
Então, mesmo após remover o deny do arquivo do usuário, o Claude Code continuaria pedindo confirmação. Para liberar de vez, seria preciso remover também a regra ask do arquivo local.
Na prática, isso muda a forma de depurar um bloqueio. Em vez de adicionar uma regra allow, procure primeiro a regra deny ou ask que está casando com o comando.
Como auditar as permissões do Claude Code com /permissions
Para enxergar todas as permissões do Claude Code de uma vez, rode o comando /permissions dentro de uma sessão. A tela lista as regras allow, ask e deny, junto com o arquivo de onde cada uma veio.
Dessa forma, aquela regra deny esquecida no diretório home aparece na hora. Além disso, você pode adicionar ou remover regras pela própria tela, sem editar JSON à mão.
Com o auto mode disponível, a mesma tela também mostra as regras do classificador em uma aba própria. Por isso, ela é o primeiro lugar para olhar quando um comando é recusado sem motivo aparente.
Limites das permissões do Claude Code
As regras Bash casam com o texto do comando que o Claude escreve. Portanto, essas permissões do Claude Code não formam uma barreira completa em volta de um programa.
Por exemplo, um deny para Bash(rm *) não bloqueia /bin/rm nem bash -c 'rm ...'. Para isolamento real de sistema de arquivos e rede, a documentação recomenda o sandbox do Claude Code.
As regras Read e Edit também têm alcance limitado. Elas valem para as ferramentas nativas e para comandos de arquivo reconhecidos, mas não para um script Python que abre arquivos por conta própria.
Outro detalhe envolve a confiança no workspace. As regras allow do .claude/settings.json de um repositório só valem depois que você aceita o diálogo de confiança daquela pasta, enquanto as regras deny e ask valem desde o início.
Em equipes maiores, as configurações gerenciadas permitem impor regras que nenhum desenvolvedor consegue sobrescrever. Também é possível desativar o modo bypassPermissions com a chave disableBypassPermissionsMode.
Se a sua dúvida é qual produto usar para cada tipo de tarefa, a comparação entre Claude, Claude Code e Cowork ajuda a decidir.
Conclusão
O auto mode resolveu o cansaço de aprovar cada ação, mas entregou a um classificador a decisão sobre o que é seguro. Em projetos .NET, isso deixa passar ações que não são perigosas, porém quebram o fluxo, como migrations escritas à mão e aplicações rodando escondidas.
As permissões do Claude Code devolvem essa decisão ao desenvolvedor. Com poucas linhas no .claude/settings.json, você exige aprovação para comandos sensíveis e bloqueia o que nunca deve rodar sem um humano.
Lembre também que deny sempre vence, depois vem ask e só então allow, seja qual for o arquivo. Assim, quando algo for bloqueado, comece pelo /permissions e procure a regra que está casando.
Por fim, as empresas ainda hesitam em adotar agentes porque não sabem quanto acesso estão concedendo. Configurar as próprias regras é a forma de traçar essa linha você mesmo, em vez de deixá-la para a IA.
FAQ
Uma regra ask funciona com o auto mode ativo?
Sim. As regras do arquivo de configuração vêm antes do classificador, então uma regra ask continua pedindo confirmação mesmo no auto mode.
Uma regra allow no projeto pode liberar algo bloqueado no arquivo do usuário?
Não. O Claude Code avalia deny primeiro em todos os arquivos, e nenhuma regra allow consegue abrir exceção em um deny.
Onde ficam as regras criadas pela opção de não perguntar de novo?
O Claude Code grava essas regras no .claude/settings.local.json, na raiz do repositório. Esse arquivo não vai para o controle de versão.
Escrever a regra no CLAUDE.md tem o mesmo efeito de uma regra deny?
Não. O CLAUDE.md orienta o comportamento do modelo, enquanto a regra deny é aplicada pelo próprio Claude Code e bloqueia a chamada.
Qual a diferença entre Bash(dotnet run ) e Bash(dotnet run:)?
Nenhuma. O sufixo :* é uma forma equivalente de escrever o curinga final.