Permissões do Claude Code: como configurar no .NET
As permissões do Claude Code definem o que o agente pode executar no seu projeto sem perguntar, o que exige a sua aprovação e o que fica bloqueado de vez. Em um projeto .NET, essa configuração evita que o agente escreva migrations do EF Core à mão, atualize o banco por conta própria ou deixe a aplicação rodando em segundo plano.
Por que as permissões do Claude Code importam em projetos .NET
Durante muito tempo, o Claude Code pedia aprovação para praticamente toda ação relevante. Quem deixava uma tarefa longa rodando muitas vezes voltava e encontrava o agente parado, esperando um clique.
Por isso, muitos desenvolvedores passaram a buscar formas de reduzir esses prompts. O problema é que cada atalho transfere uma parte do controle para o agente.
Em um projeto .NET, esse controle tem peso concreto. O agente pode rodar dotnet run, gerar migrations, aplicar alterações no banco e iniciar processos que continuam vivos depois da tarefa.
Este artigo parte de um caso real publicado pelo Round The Code. Nele, o autor configurou as permissões do Claude Code em um projeto ASP.NET Core com EF Core e descobriu como as regras se comportam quando entram em conflito.
Além disso, o texto complementa o caso com a documentação oficial de permissões do Claude Code. Assim, você entende não só o que fazer, mas também por que cada regra funciona daquele jeito.
O atalho perigoso do --dangerously-skip-permissions
A forma mais rápida de acabar com os prompts é iniciar a ferramenta com o parâmetro --dangerously-skip-permissions. Com ele, todos os pedidos de aprovação desaparecem.
# Inicia o Claude Code sem nenhum prompt de permissão
claude --dangerously-skip-permissions
No entanto, esse parâmetro entrega ao agente acesso quase total à máquina. Ele pode apagar arquivos, executar qualquer comando e até alterar pastas fora do projeto.
A documentação oficial chama esse comportamento de modo bypassPermissions. Mesmo nele, algumas proteções continuam ativas, como a confirmação antes de remover a raiz do sistema ou o diretório home.
Ainda assim, a recomendação oficial é clara: use esse modo apenas em ambientes isolados, como contêineres ou máquinas virtuais. Em outras palavras, ele não serve como solução para o dia a dia em uma máquina de desenvolvimento.
O autor do caso admite que usava esse parâmetro com frequência antes de o modo auto virar padrão. Depois de entender o risco, ele concluiu que economizar alguns cliques não justifica tanto acesso.
Como o modo auto decide o que é seguro
Em agosto de 2026, a Anthropic tornou o modo auto o padrão do Claude Code nos planos Pro, Max e Team. Ele ocupa o meio do caminho entre aprovar tudo manualmente 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. Na prática, ele funciona como uma segunda opinião sobre cada chamada de ferramenta.
Edições de arquivos dentro do projeto e comandos somente leitura seguem sem essa checagem. Por outro lado, ações arriscadas acabam bloqueadas, como descartar alterações não commitadas, apagar arquivos que já existiam antes da sessão ou publicar em produção.
Quando o classificador bloqueia algo, o agente normalmente tenta um caminho mais seguro ou pede a sua aprovação. Se os bloqueios se repetem muito, a ferramenta volta para as aprovações manuais.
Há um detalhe importante nessa relação: as permissões do Claude Code configuradas por você rodam antes do classificador. Portanto, uma regra explícita sempre tem a palavra final sobre o comando que ela cobre.
A exceção são regras allow amplas demais, como Bash(*), que equivalem a liberar a execução de qualquer código. No modo auto, a ferramenta ignora esse tipo de regra para não deixar comandos passarem direto pelo classificador.
Onde o modo auto não substitui as permissões do Claude Code
O classificador procura ações perigosas. Contudo, os dois problemas relatados no caso não eram perigosos, e sim incômodos e disruptivos.
Essa distinção é central. Uma ação pode ser segura do ponto de vista do sistema operacional e, mesmo assim, quebrar o fluxo de trabalho da equipe.
Migrations do EF Core escritas à mão
O autor pediu ao agente que adicionasse 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. Porém, a atualização do banco falhou, e o autor precisou apagar a migration e gerá-la de novo pelo comando oficial.
Esse erro tem uma explicação técnica. Segundo a documentação de migrations do EF Core, a ferramenta compara o modelo atual com um snapshot do modelo anterior e gera os arquivos a partir dessa diferença.
Ou seja, uma migration escrita à mão pode parecer válida e, ainda assim, ficar fora de sincronia com o snapshot. Por isso, o caminho seguro continua sendo o comando dotnet ef migrations add, e as permissões do Claude Code podem garantir esse caminho.
Aplicação rodando em segundo plano
No segundo caso, o agente alterava o CSS de um site ASP.NET Core MVC. Enquanto fazia as mudanças, ele manteve o site rodando em segundo plano.
Quando o autor tentou iniciar o projeto no Visual Studio, recebeu um erro informando que a aplicação já estava em execução. Nada quebrou, mas ficou a dúvida sobre se o agente encerraria o processo quando fosse solicitado.
Nenhum desses comportamentos é perigoso o bastante para o classificador barrar. Mesmo assim, ambos justificam uma regra explícita nas permissões do Claude Code.
Configurando as permissões do Claude Code no settings.json
Para definir regras no projeto, crie o arquivo settings.json dentro da pasta .claude, na raiz da solution. Esse arquivo vai para o controle de versão e vale para todos os desenvolvedores do repositório.
A configuração do caso usa duas listas. A lista ask reúne os comandos que exigem aprovação, enquanto a lista deny reúne o que o agente nunca pode fazer.
{
"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
As regras ask cobrem a criação de migrations pela CLI e a execução da aplicação com dotnet run ou dotnet watch. Assim, o agente pode usar esses comandos, mas só depois de um clique seu.
A regra Bash(run_in_background:true) merece atenção. Ela não olha o texto do comando, e sim o parâmetro que indica execução em segundo plano.
Dessa forma, qualquer processo que o agente tente deixar rodando em background passa a exigir confirmação. Isso resolve diretamente o problema do site que ficava ativo sem o desenvolvedor saber.
No teste do caso, o agente pediu permissão para rodar dotnet ef migrations add. A mensagem informava que a regra ask sobrescrevia o modo auto para aquele comando.
O mesmo aconteceu quando o CLAUDE.md do projeto pediu que o agente executasse a aplicação após cada mudança. Antes de rodar o app, ele parou e pediu aprovação.
Regras deny para o que nunca deve acontecer
A regra Edit(**/Migrations/**) impede edições em qualquer arquivo dentro de pastas chamadas Migrations. Com isso, o agente perde a opção de escrever uma migration à mão.
Já a regra Bash(dotnet ef database update *) bloqueia a atualização do banco pela CLI do EF Core. Assim, o desenvolvedor decide quando e como o esquema muda.
No teste, o autor pediu ao agente que atualizasse o banco. O agente recusou e citou a regra deny presente em .claude/settings.json.
Além disso, ele sugeriu duas saídas: rodar o comando manualmente ou mover a regra da lista deny para a lista ask. A segunda opção permite aprovar cada execução individualmente.
Sintaxe das regras nas permissões do Claude Code
As regras seguem o formato Ferramenta ou Ferramenta(especificador). Em regras Bash, o curinga * pode aparecer em qualquer posição do comando.
O espaço antes do curinga faz diferença. Por exemplo, Bash(dotnet run *) exige uma palavra completa, enquanto Bash(dotnet run*) também aceitaria um comando hipotético chamado dotnet runner.
O sufixo :* equivale ao curinga com espaço no fim. Portanto, Bash(dotnet run:*) e Bash(dotnet run *) cobrem exatamente os mesmos comandos.
As regras Edit seguem a especificação do gitignore. Nesse padrão, * cobre um único segmento de caminho, e ** atravessa diretórios.
Vale também lembrar que a ferramenta entende operadores de shell. Uma regra que libera um comando não libera automaticamente uma combinação como comando-seguro && outro-comando.
Ordem de avaliação das permissões do Claude Code
O ponto mais surpreendente do caso aparece quando regras de arquivos diferentes entram em conflito. Para entender o resultado, é preciso conhecer os arquivos de configuração e a ordem de avaliação.
Os três arquivos de configuração
A ferramenta lê três tipos de arquivo de configuração no dia a dia. O primeiro é .claude/settings.local.json, com preferências pessoais no projeto, que normalmente fica fora do Git.
O segundo é .claude/settings.json, compartilhado pelo time. Por fim, o terceiro é ~/.claude/settings.json, na pasta home, que vale para todos os seus projetos.
Para a maioria das configurações, o arquivo local tem prioridade sobre o do projeto, e o do projeto tem prioridade sobre o do usuário. Contudo, as permissões do Claude Code não seguem essa lógica de sobrescrita.
| Arquivo | Escopo | Uso recomendado |
|---|---|---|
.claude/settings.local.json |
Você, neste projeto | Ajustes pessoais que não vão para o Git |
.claude/settings.json |
Todo o time, neste projeto | Política compartilhada do repositório |
~/.claude/settings.json |
Você, em todos os projetos | Preferências globais |
Por que uma regra deny sempre vence
Durante a escrita do artigo original, o agente deixou de conseguir rodar a aplicação. A causa estava em uma regra Bash(dotnet run *) na lista deny do arquivo global, esquecida de um teste anterior.
{
"permissions": {
"deny": [
"Bash(dotnet run *)"
]
}
}
Curiosamente, o próprio agente sugeriu adicionar Bash(dotnet run:*) à lista allow do projeto. O autor seguiu a sugestão, mas a aplicação continuou bloqueada.
{
"permissions": {
"allow": [
"Bash(dotnet run *)"
],
"ask": [
"Bash(dotnet ef migrations add *)",
"Bash(dotnet watch *)",
"Bash(run_in_background:true)"
],
"deny": [
"Edit(**/Migrations/**)",
"Bash(dotnet ef database update *)"
]
}
}
A explicação veio quando o autor pediu ao agente que verificasse todos os arquivos. As permissões do Claude Code combinam as regras de todos os escopos em um único conjunto, e só depois decidem o resultado.
Nesse conjunto, a avaliação segue sempre a mesma ordem: primeiro deny, depois ask e por último allow. A primeira correspondência encerra a decisão, e a especificidade da regra não muda essa ordem.
Quando nenhuma regra corresponde, vale o modo de permissão ativo, como o classificador no modo auto.
Portanto, um deny no arquivo global bloqueia um allow no arquivo do projeto, e o inverso também vale. A documentação oficial confirma esse comportamento entre todos os escopos.
O agente ainda apontou um segundo detalhe. O arquivo settings.local.json tinha dotnet run na lista ask, e uma regra ask vence uma regra allow para o mesmo comando.
Em outras palavras, mesmo sem o deny global, a ferramenta continuaria pedindo aprovação antes de rodar o app. Para liberar a execução sem prompt, seria preciso remover as duas regras.
Auditando as permissões do Claude Code com /permissions
Investigar arquivos um por um consome tempo. Por isso, a forma mais rápida de entender o estado atual é rodar o comando /permissions dentro da sessão.
Essa interface lista todas as permissões do Claude Code ativas na sessão, separadas por allow, ask e deny. Além disso, ela mostra de qual arquivo settings.json cada regra veio.
Na prática, a seção deny funciona como a lista definitiva do que o agente não pode fazer naquele projeto. Se um comando aparece ali, nenhuma regra allow em outro arquivo vai liberá-lo.
Esse hábito teria economizado a investigação do caso. Com uma consulta, o autor veria a regra esquecida no arquivo global.
Boas práticas de permissões do Claude Code no time
O caso mostra que as permissões do Claude Code funcionam melhor como política de time do que como ajuste individual. A seguir, algumas práticas que derivam dele e da documentação oficial.
Primeiro, coloque as permissões do Claude Code compartilhadas em .claude/settings.json e faça commit desse arquivo. Assim, todo desenvolvedor que clonar o repositório recebe as mesmas regras.
Em seguida, use regras deny apenas para o que nunca deve acontecer naquele projeto. Como um deny não aceita exceções, uma regra ampla demais trava fluxos legítimos.
Também prefira regras ask para comandos que você quer usar, mas com supervisão. Esse é o caso de dotnet run, dotnet watch e da criação de migrations.
Além disso, revise o arquivo global com cuidado. Uma regra de teste esquecida ali afeta todos os seus projetos sem nenhum aviso visível no repositório.
Outra recomendação é tratar o CLAUDE.md como orientação, e não como barreira. A documentação deixa claro que as instruções moldam o que o agente tenta, mas quem aplica as regras é a própria ferramenta.
Por fim, lembre-se da confiança no workspace. Regras allow do arquivo do projeto só entram em vigor depois que você aceita o diálogo de confiança daquela pasta, enquanto regras deny e ask valem desde o início.
Se você ainda está começando com a ferramenta, o artigo Primeiros passos com Claude Code apresenta a instalação, o login e o primeiro contato com os prompts de aprovação.
Conclusão
O modo auto reduziu bastante a quantidade de prompts, mas ele procura perigo, e não as convenções do seu projeto. Por isso, comportamentos seguros e indesejados continuam passando.
As permissões do Claude Code preenchem essa lacuna. Com regras ask, você mantém a supervisão sobre comandos como dotnet run e dotnet ef migrations add, e com regras deny você impede migrations escritas à mão e atualizações de banco sem controle.
A lição mais importante do caso, porém, está na precedência. Uma regra deny vence em qualquer arquivo, e uma regra ask vence uma allow para o mesmo comando.
Dessa forma, quem define as regras decide onde fica o limite, em vez de deixar essa decisão para a IA. Para empresas ainda cautelosas com agentes, esse controle explícito é o que torna a adoção gradual possível.
FAQ
Onde fica o arquivo de permissões do Claude Code em um projeto .NET?
Fica em .claude/settings.json, na raiz da solution. Para preferências pessoais, use .claude/settings.local.json, e para regras globais, ~/.claude/settings.json.
Uma regra allow no projeto pode liberar um comando negado no arquivo global?
Não. A ferramenta combina as regras de todos os arquivos e avalia deny antes de ask e allow, então o deny bloqueia o comando em qualquer escopo.
As regras ask funcionam no modo auto?
Sim. As regras configuradas rodam antes do classificador, então uma regra ask continua pedindo aprovação mesmo com o modo auto ativo.
Como impedir que o agente escreva migrations do EF Core à mão?
Adicione Edit(**/Migrations/**) à lista deny e deixe Bash(dotnet ef migrations add *) na lista ask. Assim, a única forma de criar migrations passa pela CLI, com a sua aprovação.
Como ver todas as regras ativas na sessão?
Rode o comando /permissions. Ele lista as regras allow, ask e deny e mostra o arquivo de origem de cada uma.