Claude pedindo permissão o tempo todo? Dá pra resolver

Se você usa o Claude Code no dia a dia, provavelmente já passou por isso: você pede uma refatoração simples e, a cada arquivo, a cada comando no terminal, a cada busca no projeto, aparece aquela pergunta — posso fazer isso? 🤔

Não é falta de educação do modelo. É o sistema de permissões funcionando como deveria: por padrão, o Claude pede autorização antes de ler, escrever, editar ou rodar qualquer coisa fora do que já foi liberado.

O problema é quando isso vira ruído. Você sabe que está num projeto seu, num diretório que você controla, e mesmo assim o fluxo quebra a cada trinta segundos. A produtividade cai. A paciência também.

A boa notícia: você não precisa aceitar isso como “parte do jogo”. Dá para configurar uma vez e deixar o Claude trabalhar dentro dos limites que você define.

A solução: permissões no projeto

Crie na raiz do seu projeto (ou na pasta em que você costuma abrir o Claude) o arquivo:

.claude/settings.json

Nele, você declara o que o assistente pode fazer sem perguntar de novo. O escopo é por pasta — ou seja, você libera só o que importa para aquele trabalho, sem abrir o mundo inteiro do seu computador.

Exemplo prático

Suponha que você desenvolve tudo em ~/Developer/workspaces/. Um settings.json enxuto pode ficar assim:

{
  "permissions": {
    "allow": [
      "Read(~/Developer/workspaces/**)",
      "Write(~/Developer/workspaces/**)",
      "Edit(~/Developer/workspaces/**)",
      "MultiEdit(~/Developer/workspaces/**)",
      "Glob(~/Developer/workspaces/**)",
      "Grep(~/Developer/workspaces/**)",
      "LS(~/Developer/workspaces/**)",

      "Bash(*)",

      "WebFetch(*)",
      "WebSearch"
    ],
    "deny": [
      "Read(~/Developer/workspaces/**/.env)",
      "Read(~/Developer/workspaces/**/.env.*)",
      "Read(~/Developer/workspaces/**/secrets/**)",
      "Read(~/Developer/workspaces/**/*.pem)",
      "Read(~/Developer/workspaces/**/*.key)",
      "Bash(rm -rf *)",
      "Bash(sudo rm *)"
    ]
  }
}

Se você quiser algo mais controlado

Para a maioria das pessoas, o modelo acima já resolve o problema principal e deixa o fluxo rápido. Mas, se você prefere mais controle, dá para manter o mesmo padrão e restringir partes específicas.

Por exemplo, em vez de liberar qualquer URL com WebFetch(*), você pode permitir apenas alguns domínios:

{
  "permissions": {
    "allow": [
      "WebFetch(https://github.com/**)",
      "WebFetch(https://docs.anthropic.com/**)",
      "WebFetch(https://stackoverflow.com/**)"
    ]
  }
}

E também pode usar deny para bloquear leitura de arquivos sensíveis e comandos perigosos:

{
  "permissions": {
    "allow": [
      
    ],
    "deny": [
      "Read(~/Developer/workspaces/**/.env)",
      "Read(~/Developer/workspaces/**/.env.*)",
      "Read(~/Developer/workspaces/**/secrets/**)",
      "Bash(rm -rf *)",
      "Bash(sudo rm *)"
    ]
  }
}

Essa combinação é útil quando você quer autonomia para tarefas comuns, mas ainda deseja uma proteção explícita contra acesso a segredos e operações destrutivas.

⚠️ Ajuste o caminho ~/Developer/workspaces/** para a pasta real do seu projeto. O padrão ** inclui subpastas. Quanto mais estreito o caminho, mais seguro fica.

O que cada permissão faz

Cada entrada em allow é uma regra. O Claude só age sem pedir confirmação se a ação couber em alguma delas.

• Read(...) — ler arquivos dentro do caminho indicado.
• Write(...) — criar ou sobrescrever arquivos.
• Edit(...) — editar arquivos existentes (alterações pontuais).
• MultiEdit(...) — várias edições no mesmo arquivo em uma sequência.
• LS(...) — listar diretórios e ver o que existe na árvore.
• Glob(...) — buscar arquivos por padrão (por exemplo, **/*.py).
• Grep(...) — pesquisar texto dentro dos arquivos do projeto.
• Bash(...) — executar comandos no terminal. Bash(*) libera qualquer comando; se quiser mais controle, restrinja (por exemplo, só Bash(git *) ou Bash(npm *)).
• WebFetch(...) — acessar uma URL específica (documentação, API, etc.). WebFetch(*) libera qualquer URL — use com critério.
• WebSearch — pesquisar na web quando o modelo precisa de informação atualizada.

Na prática, Read, Grep, Glob e LS são o pacote mínimo para o Claude “entender” o repositório sem interromper você. Edit, MultiEdit e Write são o que destravam o fluxo de codar de verdade. Bash entra quando você quer que ele rode testes, build, git e afins sem ficar na fila de aprovação.

Como pensar no escopo (sem abrir demais)

Algumas dicas que uso no dia a dia:

• Prefira caminhos específicos em vez de ~/**. Seu usuário, sua pasta de trabalho — pronto.
• Projetos sensíveis (cliente, produção, secrets) merecem um settings.json mais restrito ou nenhum Bash(*) solto.
• Repita o padrão nos repositórios onde você passa horas. Pode versionar o arquivo no git (sem dados privados) e todo mundo do time ganha o mesmo fluxo.
• Se algo ainda pedir permissão, leia a mensagem: muitas vezes é uma ação fora do glob que você definiu — aí é só acrescentar a regra certa.

Antes e depois

Antes: “Posso editar este arquivo?” → você clica. “Posso rodar npm test?” → você clica. “Posso ler o README?” → você clica de novo. O contexto mental vai embora.

Depois: o Claude opera dentro do contrato do settings.json. Você acompanha o que importa; o resto flui.

Conclusão

O Claude não precisa ser um assistente que pergunta tudo — ele pode ser um parceiro que respeita limites claros que você desenhou. Um arquivo .claude/settings.json bem configurado devolve o ritmo da sessão e deixa você focar no problema, não na fila de cliques.

Experimente num projeto real, ajuste os caminhos, refine o Bash se precisar. Em poucos minutos você sente a diferença — e dificilmente volta atrás. 🚀