Configuração de Permissões: Quão solto, quão apertado, você decide

📚 Navegação da Série: O artigo anterior 19 Gestão de Contexto ensinou como gerenciar bem a "bancada de trabalho" do Claude, e evitar que ele estoure a memória. Este artigo vai para outra dimensão — o controle não é de "quanto ele lembra", mas "o quanto ele tem coragem de agir": desde perguntar para rodar uma única linha de comando, até a liberação total e automática. O quão apertada fica a rédea das permissões, é você quem decide.

"Como você tem coragem de ligar --dangerously-skip-permissions? O próprio nome já diz dangerous (perigoso)."

"Eu estou numa sandbox, medo de quê? Mesmo que ele dê rm -rf no diretório inteiro, o que foi apagado é um contêiner descartável, basta recriar um."

Eu mesmo já estive dos dois lados dessa conversa: rodando refatorações em lote em contêineres isolados na nuvem, eu mantinha o modo mais solto e perigoso ativado o tempo todo, sem peso na consciência de apagar e começar de novo; mas assim que voltava para minha máquina local com o código real da equipe, até o acceptEdits eu hesitava por dois segundos. Resumindo, não existe certo ou errado quando se trata de permissões, apenas "onde você está usando". O mesmo modo perigoso totalmente solto, no contêiner isolado é um "acelerador", mas na máquina com seu código de produção é uma "bomba-relógio".

No Artigo 07, tocamos levemente no assunto — o Claude para e lhe pergunta antes de modificar um arquivo. Aquilo é só a ponta do iceberg. Hoje vamos revelar o iceberg inteiro: quais são os modos de permissão do Claude Code, como trocar com um clique, e como usar arquivos de configuração para especificar precisamente "ele pode fazer isso, mas não pode fazer aquilo sob hipótese alguma".

Após ler este artigo, você terá:

• Compreensão clara sobre o que é cada um dos seis modos de permissão e onde cada um se encaixa melhor, através de uma tabela.
• A memória muscular do Shift+Tab para alternar entre modos e como especificar diretamente o modo ao iniciar.
• A sintaxe para escrever regras allow / ask / deny no settings.json, controlando permissões com precisão por ferramenta e por comando.
• Dois modelos prontos de configuração: "Projeto de Brinquedo Solto" e "Projeto de Produção Apertado", é só copiar e colar.
• A linha vermelha de quando você realmente tem coragem de abrir o --dangerously-skip-permissions e os limites da zona de segurança.

---

01 Entendendo primeiro: O que o sistema de permissões gerencia

Vou direto à conclusão: O Claude Code, por padrão, é um estagiário do tipo "pergunta primeiro, age depois", e a configuração de permissões é o "código de conduta" que você define para esse estagiário.

Ele divide todas as operações em três categorias, e o tratamento padrão é totalmente diferente. Esta tabela de classificação da documentação oficial é a base para entender o resto:

Tipo de Ferramenta	Exemplo	Precisa de aprovação por padrão?
Somente Leitura	Ler arquivos, pesquisa com Grep	Não, liberação direta
Comandos Bash	Executar comandos shell	Sim
Modificação de Arquivos	Modificar arquivos com Edit / Write	Sim

Analogia: O estagiário pergunta antes de agir? Um estagiário confiável, se você diz "dê uma olhada neste código", ele apenas lê (somente leitura, risco zero); mas se ele for "alterar a configuração de produção" ou "executar um comando de exclusão", normalmente levantará a cabeça e perguntará "Chefe, posso mexer nisso?". O Claude Code por padrão é assim — lê à vontade, mas relata antes de agir.

Há um insight chave aqui, e eu mesmo já caí nessa armadilha: As permissões são aplicadas à força pelo programa Claude Code, e não dependem da "consciência do modelo".

Certa vez, eu escrevi especificamente no CLAUDE.md: "Não execute git push", pensando que estava bloqueado. Contudo, ele executou o push tranquilamente — porque o CLAUDE.md é apenas um lembrete brando que "influencia o que ele quer fazer", as restrições reais e pesadas precisam ser escritas nas regras de permissão. Só quando mudei a regra para deny é que ele obedeceu. O oficial diz bem diretamente:

As regras de permissão são impostas pelo Claude Code, não pelo modelo. Suas instruções ou notas no CLAUDE.md afetam as ações que o Claude tenta executar, mas não alteram o que o Claude Code permite.

Lembre-se desta regra para saber onde construir a "defesa".

💡 Resumo em uma frase: Leitura livre e ação com aprovação são a regra padrão; para bloquear de fato uma operação, é preciso escrever a regra de permissão, não adianta só avisar no CLAUDE.md.

---

02 Seis modos de permissões: De "pergunta a cada passo" até "liberação total"

O modo de permissão (permission mode) controla uma única coisa: a "frequência" com que o Claude pausa para te perguntar antes de agir. Da "parada e pedido de confirmação a cada passo" até "fazer tudo direto sem perguntar", há um espectro contínuo.

Analogia: Ainda sobre o estagiário, o modo é o "nível de autonomia" que você lhe dá. No primeiro dia, ele pergunta sobre tudo (default); quando pega o jeito, edita o código sem perguntar, mas pra apagar a base de dados ainda tem que te chamar (acceptEdits); se você for viajar e confiar nele totalmente, deixa ele resolver tudo sozinho (bypassPermissions).

Oficialmente, existem seis modos. Organizei se "ele vai te perguntar antes" e "os cenários aplicáveis" em uma tabela — esta é a tabela que você mais precisa memorizar neste artigo:

Modo	O que pode fazer sem perguntar	Vai perguntar antes?	Cenário mais adequado
default	Somente leitura	Alterar arquivos e rodar comandos: pergunta sempre	Iniciantes, trabalho sensível
acceptEdits	Leitura + Edição de arquivos + Comandos comuns de sistema (ex: mkdir, mv, cp, etc.)	Edições de arquivo e comandos comuns: não pergunta; Outros comandos Bash: continua perguntando	Iterando código sob sua revisão
plan	Somente leitura (apenas pesquisa, apenas propõe, não toca no código fonte)	Segue as mesmas regras de prompt do default	Para explorar e propor um plano antes de mexer
auto	Todas as operações, com um classificador de segurança em segundo plano	Basicamente não pergunta, os abusos são bloqueados pelo classificador	Tarefas longas, minimizar interrupções (Edição de Pesquisa de preview)
dontAsk	Somente ferramentas pré-aprovadas	Não pergunta nem para, rejeita direto o que não for pré-aprovado	CI e scripts bloqueados
bypassPermissions	Todas as operações, ignora todas as verificações	Nunca pergunta	Exclusivamente em Contêiner Isolado / VM

Alguns pontos que os iniciantes frequentemente confundem e merecem esclarecimento:

plan (Modo Plano) não é "relaxado", pelo contrário, é o mais contido. Ele faz o Claude apenas ler arquivos e rodar comandos de leitura para entender o contexto, então escreve um "plano de como pretende alterar", mas não mudará uma única palavra no seu código. Ao assumir um projeto desconhecido, o primeiro passo recomendado é mudar para o modo plan para que ele leia tudo primeiro; é bem mais seguro do que deixar ele alterar às cegas.

acceptEdits é o ponto ideal para o desenvolvimento diário. Ele aprova automaticamente edições de arquivos e alguns comandos de sistema comuns no seu diretório (mkdir, touch, rm, rmdir, mv, cp, sed), mas quaisquer outros comandos shell e gravações fora do diretório de trabalho continuarão parando para te perguntar. É como dizer "não precisa clicar em concordo toda hora para alterar código, mas o freio de segurança para comandos perigosos continua puxado".

auto e bypassPermissions parecem "não perguntar", mas a segurança é incrivelmente diferente. auto é uma versão de prévia de pesquisa, com um classificador rodando por trás que audita cada ação; o que cruzar a linha (como curl | bash, dar push para main, excluir no cloud storage) será bloqueado. Já o bypassPermissions é andar totalmente nu, sem sequer proteção contra prompt injection (injeção de prompt). A documentação oficial é clara:

bypassPermissions não oferece proteção contra injeções de prompt ou ações inesperadas. Para ter verificações de segurança em segundo plano sem os prompts, use o modo auto em vez disso.

Então, se quer "paz de espírito com uma linha limite", prefira o auto, e não caia direto no bypassPermissions.

💡 Resumo em uma frase: default pergunta a cada passo, acceptEdits edita código sem perguntar, plan só olha e não toca, auto tem um classificador para garantir o básico, e bypassPermissions anda totalmente pelado — lembre-se deste espectro de rigor, e encaixe no cenário adequado.

Esta imagem organiza os seis modos em um espectro "do mais severo ao mais permissivo": no lado esquerdo verde estão plan / default (só lê, pergunta a cada passo, mais seguro), indo para a direita passa por acceptEdits (edita sem perguntar), auto (garantido por classificador), até chegar no lado vermelho à direita com o bypassPermissions (totalmente pelado) — quanto mais para a direita a cor fica mais vermelha, lembrando que "quanto mais folgado, mais cuidado com onde você está usando".

---

03 Alternando modos: Shift+Tab para alternância num clique

Agora que conhecemos os modos, como alternar? A forma mais usada é o atalho: Shift+Tab.

Dentro de uma sessão, pressionar livremente Shift+Tab irá alternar ciclicamente entre três modos:

default → acceptEdits → plan → (pressione novamente para retornar a default)

Para saber qual é o modo atual, basta olhar na barra de status. Por exemplo, ao mudar para acceptEdits, a barra de status mostrará ⏵⏵ accept edits on.

Preste atenção em um detalhe oficial para evitar procurar os modos em vão: O ciclo padrão contém apenas os três modos: default / acceptEdits / plan. Os outros três são acessados de formas diferentes: o auto aparecerá automaticamente no ciclo assim que sua conta atender aos requisitos; bypassPermissions necessita do uso de parâmetros como --permission-mode bypassPermissions ao inicializar para entrar no ciclo; e dontAsk nunca aparecerá no ciclo, e pode apenas ser configurado com o parâmetro de partida --permission-mode dontAsk (explico abaixo).

Analogia: É como o interruptor do celular "Toque / Vibrar / Silencioso". Pressionar o botãozinho lateral irá alternar nestes 3. O Shift+Tab é esse interruptor do Claude Code; dando a volta nas três configurações "pergunta a cada passo / edita sem perguntar / só olha e não age".

Se você não quer ter que alternar manualmente cada vez que entrar, há duas maneiras de "pregar" o modo:

Modo um: Defina por parâmetro na inicialização (vale apenas para esta sessão):

claude --permission-mode plan

Basta trocar plan por acceptEdits, dontAsk ou qualquer nome de modo. bypassPermissions é peculiar: as formas --permission-mode bypassPermissions e --dangerously-skip-permissions são equivalentes, mas na rotina diária usamos o último nome, que é "já vem com aviso"; explico com detalhes na Seção 05.

Modo dois: Escrever no settings.json como padrão (ativado a cada início). No settings.json dentro do seu diretório de projeto .claude/:

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

⚠️ Restrição oficial importante: Ao definir defaultMode como "auto", configurações de projeto e locais serão ignoradas (para evitar que um repositório qualquer se coloque em auto secretamente). Para usar auto como padrão, escreva no settings.json a nível de usuário em ~/.claude/settings.json.

Um hábito recomendado: Não trave o modo nos projetos, confie na alternância manual via Shift+Tab. Porque dentro de um projeto mesmo, às vezes você o deixa seguir (com o acceptEdits), mas às vezes deseja apenas receber propostas (usando plan); configurar como imutável atrapalha. defaultMode no geral só vale a pena quando o projeto de fato tiver que ser severamente restritivo com default para proteção máxima.

💡 Resumo em uma frase: Pela sessão Shift+Tab dá a volta na tríade "passo-a-passo / altera sem perguntar / só olha", acompanhe pelo status; quer definir algo, usa a startup flag --permission-mode ou a tag do settings defaultMode.

---

04 Controle de granulação precisa: O trio das regras allow / ask / deny

Os modos fornecem uma afinação "grossa" num grande ritmo geral. O verdadeiro ajuste fino de especificar "esse comando específico sim e o outro nunca" é feito no trio de opções no arquivo settings.json.

Cada comando culmina no veredito entre essas três categorias de ações:

Ação	Efeito	O Uso Típico
allow	Aprovação zero, liberação na via expressa	Operações diárias sem risco, p. ex.: git status, npm run build
ask	Exibe tela popup pra tu decidires na mão	Algum risco, então confirmar; Exemplo: git push
deny	Barra bloqueado por completo; não passa nem com aviso	Atitudes super arriscadas listadas; ex: rm -rf, ler .env

Hierarquia inquebrável: deny → ask → allow, o primeiro matching ganha! Se criares pro mesmo item um allow bem como um deny, o peso vai pra o deny. Isso tem sentido lógico: A "proibição" sempre tem o martelo final sobre a permissão.

As diretrizes são formatadas sob NomeDaFerramenta ou NomeDaFerramenta(identificador). Observe as nuances nestes exempilhos:

Regra	Pega no Que
Bash	Tudo o que for comando de Terminal
Bash(npm run build)	Retém rigorosamente apenas à digitação em si de npm run build
Bash(npm run *)	Pega todo e qualquer prefixo inicial (ex: build, test...)
Read(./.env)	Leitura exclusiva desse exato .env na pasta inicial
WebFetch(domain:github.com)	Todas requests disparadas rumo aos servidores de domínio do Github.com

No caso de wildcards (* curingas), há a pegadinha mortífera que oficiais martelam sobre o uso do espaço:

Bash(ls *) aceita e se alinha com ls -la não abarcando lsof. Enquanto Bash(ls*) abraça de fato as duas pontas!

Um espaço minúsculo muda o rumo! ls * (espaçado) pede com obrigatoriedade de que logo após de um ls venha uma quebra com a tecla barra-de-espaço; dessa maneira o termo isolado lsof se exime! O ls* sem espaços arrasta todos. A dica de precisão? Use o espaço a rigor.

Veja um quadro robusto e completo que dá autoridade aos rotineiros npm's e compromete a proibição absoluta de subir (push) no git:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

O último ponto de suma relevância: Repassar ao deny nas rotinas da Read / Edit tem buraco — Eles não estagnam a escrita ou a cópia escusa de arquivos criados a partir dos Sub-Processos do BASH!

O que isso indica? Que ao estipular um deny: Read(./.env) a via direta do uso do próprio Claude Tool (ferramenta) para o Read cai por terra, entretanto se o script disparar ao plano B rodando python -c "open('.env').read()"; as vossas regrinhas para "deny" ficaram inócuas! Os processos isolados do Node e Python se contorcem além dos trilhos do executável do Claude. O próprio Manual da Plataforma reitera:

Eles não contemplam nem intercedem de maneira paralela ou subjacente perante aos subprocessos abertos ou ativados arbitrariamente — como node scripts ou python invocados no interior a fim de carregar esses ditos arquivos. Se a prioridade for lacrar os vetores todos de vez com mãos de chumbo em via OS, ligue em imediato o Sandbox (Sistema Operacional Cautivo)!

Tão espantoso para quem achava que estava ileso com os denies; por isso a fórmula master de vedar arquivos perigosos é associar regra + atrelamento de uma Caixa de Areia (Sandboxing) — veremos na Parte seguinte sobre Seguranças os meios práticos!

💡 Resumo em uma frase: O topo de linha nas lutas de regra obedece o deny → ask → allow; O curinga de espaço diz ou tira tudo; Mas um deny simples só cega o Claude de espiar diretamente; contra vias alternadas de linguagem de script alheia a tranca derradeira recai sobre o Sandboxing!

---

05 Tensão do Brinquedo X Rigor de Produção: Dois Gabaritos e a "Linha Rubra do modo de Perigo"

Após desbravar engrenagens, tudo encerra aqui: Quanto mais rústico for um código experimental de bancada "Projeto Brinquedo" mais as restrições se derretem; já no ambiente "Forte e de Produção" elas ganham cimento blindado.

Leve dois padrões-esqueleto direto pra copiar e usar; avalie qual a natureza em pauta!

Padrão Alpha: Brinquedos / Códigos Singulares ou Particulares (Velocidade Expressa). Acabou o código da base experimental e cagou nela? Recria sem medos, de modo contínuo e expressivo. Ative em sua casa acceptEdits não te azucrinar a cabeça e crie redutos aos perigos mais notáveis:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push *)"
    ]
  }
}

Padrão Ômega: Chão de Fábrica / Trabalho ou Times de Produção (Guardas Rigorosos). Defalts (Padrão) de parar, pensar e autorizar em tudo! Somente visões gerais (status etc) fluirão livres na allow. Deleções críticas, Subidas no Github, Visualizações a arquivos .env confidenciais: Serão ceifadas!

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(npm run *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Precavendo a elaboração nestes arquivos deny — releia o episódio superior: Um deny no env tem lacuna sem Sandboxing! É preciso que o cerco possua isolamento além das fronteiras nativas do Claude em áreas abertas em máquina hospedeira de produção.

E finalmente, o Rubicão — a linha de fronteira que batizou o topo da nossa narrativa — --dangerously-skip-permissions (Que equipara-se fiel e plenamente ao modo de saltos completos de verificações: bypassPermissions).

Não há floreio e firulas nesse, trata-se de pular, sobrevoar e ignorar toda a cadeia e instâncias de paradas perante aprovação, incluindo as travas de verificações gerais — acionando tudo no susto, não restará pedra! O oficial põe nos trilhos sua via-crúcis restritiva de aplicação:

Somente execute nas trincheiras e bolhas insuladas (Tais como um Contêiner, Virtual Machines (VM's) de nuvens desprovidas da net global de conexão web ou Dev-Containers)! Lá eles escarram mas a máquina matriz permanece isenta de qualquer fumaça!

Tabela final a respeito deste comando, siga religiosamente a doutrina dela:

Situação Local	Eu Terei Ousadia para usar o --dangerously-skip-permissions?
Containers Segregados / Descartáveis VMS e de DEV	✅ Total! Exclusão lá vira lixo que é jogado e limpo a uma reincialização!
No Fluxo de CI das ações rotineiras	✅ Com folgas e aval. Associe a malhas do deny ao máximo do possível!
Minha Máquina caseira que codo e assisto Youtube no cotidiano	❌ Negativo! Mais lerdeza preservará todo seu patrimônio em vida ali dentro
Terminal conectado num sistema da empresa e na Produtividade corporativa!	❌ Intocável. Uma bomba tática para disparar o pesadelo!

Mas a empresa é boa e concebeu "duas amarras de segurança-nata (fuse)" pra evitar o choro absoluto e dar calço de respiração caso algo se solte (No meio de saltos arriscados, as tentativas extremadas em rm -rf / ou rm -rf ~ atiradas na raiz dos Macs e Linux vão dar esbarrão paralisante implorando cliques no OK manual; Um disjuntor natural às escorregadas brutas); Secundariamente aos usuários Unixes/Mac, a iniciação por debaixo do mantenedor global Root (sudo) de modo total escancarado desse bypass; A porta tranca não os admitindo na largada. — A grande recomendação se preserva intocável nas diretrizes: Execute em redomas isoladas, das quais, destruir com tudo não causará a mínima dor em sua alma!

💡 Resumo em uma frase: Códigos lúdicos ativam expressa fluidez acceptEdits, em Chão-de-Fábrica a corda apertada default; dois esqueletos de cópia listos; O perigosíssimo --dangerously-skip-permissions tem passe livre e restrito de existir nas enclausuradas prisões (VMs e contêiners isolados), para Produção ou sua vida doméstica - feche a discussão!

---

06 Mão na Massa: Erga teu próprio muro de controle em 5 minutos!

Nada de jargão oco; puxe seu ambiente de teste vazio! Vamos agora mesmo em um projetinho rápido fazer você atestar com sua visão como a tração de barreiras atua quando tu bates de frente com a linha: allow x deny. Nenhum ambiente penoso e demorado se requer aqui:

Ponto Um: Gere as pastas ocas de um ensaio (Sistemas Unix/MacOS/Win GitBash)

mkdir perm-demo
cd perm-demo
mkdir .claude

Espera-se ver: No ínfimo reduto do perm-demo, se ergue o vazio .claude enclausurado. Rode o seu ls -a e ele atestará presença!

Ponto Dois: Preencha com a caneta o seu settings base!

Adentre com o editor favorito de código o recém forjado arquivo da fundação: perm-demo/.claude/settings.json, e lhe abasteça com isso:

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(git status *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

A Alma desta escritura se diz assim: Ele nos perguntará por via de via, contudo nos casos que pedirmos os status isso cortará-caminho! Do outro lado os infames empurrões de git push, serão aniquilados a tiro certeiro!

Ponto Três: Entre no Bot e Examine as Fichas

claude

Ali nas premissas digite no campo:

/permissions

Espera-se ver: Aparecerão na tela preta todas as vias demarcadas; o git status * acomodado nas áreas doces do Allow, e na enjaulada do Deny habita a marcação git push * — além de apontarem ao cordão umbilical (da onde surgiram - o settings recém digitado). Telas populadas assim afirmam: Minhas rédeas já conectaram!

Ponto Quatro: Ponha pra bater de cabeça no Muro - A Eficácia do Deny!

Dite no próprio campo a solicitação que o incita na travessia barrada:

Execute agora meu bom claude, o envio de: git push origin main

Espera-se ver: Ele cessa e acusa a parede. Claude Code Recusará agir; nem mesmo erguerá telinhas charmosas pedindo seu botão de OK e anuência! Ele atirará sem dó no log textual o aviso do cerco em vermelho, sinalizando o desvio total das diretrizes! Este é o assombroso peso do deny: Sem ato, sem popups charmosos para os tolos passarem o dedo, um bloqueio hermético.

Ponto Cinco: Corra de forma suave na avenida plana e aliviada do Allow!

Induza num novo direcionamento que esbarra na brecha aliviada:

Faça o imenso favor de correr o meu git status, para ver minhas novidades!

Espera-se ver: Embasado no encaixe que demos da brecha em allow: Bash(git status *), a rodada não se trunca nem nos submete às perguntinhas repetidas de popup, rodando imediatamente. E para efeitos - ainda sem o ambiente oficializado no git (Não há um git init na etapa um de treino, portanto arrotará os erros característicos da linha do "não estou num Repositório git"); mas eis que o ponto central, e único objetivo dessa manobra não nos parou ou travou na aprovação, logo sua régua no sistema de permissões permitiu sem embargos!

Os cincos percursos percorridos são o diploma desta arquitetura: A fundação do settings, a invocação do carregamento e conferência via commandos slashs e a constatação da trava abrupta contra o tapete liso esticado às coisas lícitas! As próximas vivências no âmbito macro do sistema nada mais consistirão senão destilar esta essência bruta noutros locais que venham!

💡 Resumo em uma frase: Forje o diretório, abasteça os .claude/settings.json, tire uma casquinha com o /permissions nas tabelas visuais internas, e dê o comando de liberação e estolamento pra comprovar os efeitos na pele! Repita-se neste simples fluxograma rudimentar o laboratório, a assimilação se tornará enraizada sem ser esquecida por manuais vazios!

---

07 Resumo Final

Esmiuçamos os pilares, rédeas e controles que freiam as loucuras e arroubos da automação! — Se lhe confias liberdade e passagens curtas pra ganhar fluidez, ou sufocas lhe impondo algemas visando não explodir sua obra maior, a bola e configurações pesam sob seus ombros!

Sumarizamos o prato principal:

Ato Demandado	Recurso em Foco	Essência Prática
Ritmo e interrupções na liberação	6 Instâncias do Modo de Permissão (Permission mode)	As passagens num gradiente variam no espectro: Passo à aprovação de um em um no default -> Peladões com bypassPermissions
Troca Relâmpago nas Rodadas	Shift+Tab	Vai do engessamento contínuo às fluências em default / acceptEdits / plan
Padronização por padrão fixo no boot!	defaultMode	Concedido no interior do settings.json; Caso queira os auto em rotina imposta crie níveis na base ~/.claude/settings.json na home pra pegar na fonte geral global e contornar os impedimentos projetuais
Direção focada, a caneta pontuda contra ordens isoladas e não um sistema!	allow / ask / deny	Conflito frontal no triplo veredito hierárquico deny → ask → allow; e um deny é juiz sem apelação!
Bloqueio cego para Dados vitais, tokens soltos e Cofres (Arquivos chaves)	O Acúmulo de Sandboxing sobre o deny!	A Barreira frouxa e virtual num mero deny se evade através de roteamentos secundários no meio das sub-linguagens geradas ali na máquina. Tranca sem Sandbox é buraco aberto nas portas dos fundos!

Habilidades adquiridas da sessão e já prontas na memória muscular do usuário: Dizer quando usar quais dos Seis espectros conforme a ocasião demandada; o pressionar suave com a tecla e alavanca das alternâncias (Shift+Tab); Adicionar na própria base, e não somente copiar comandos de allow & deny e aplicá-los com regras minuciosas a partir da escrita na configuração de settings sem perigos do vazio dos curingas estraçalharem e abranger as áreas intocadas; o modo sábio e seguro do discernimento de classificar a aplicabilidade relaxada sem temores pros projetos recreativos versus a burocratização rigorosíssima nos projetos essenciais. E do modo de atalho letal e que ignora a proteção inteira! (--dangerously-skip-permissions na cova insulada de confinamento longe das mesas orgânicas da matriz local e produção da companhia, sem chance de rebatimento perante uma tragédia inevitável e infeliz!). Todo este arsenal de domínios garante a autoridade sob sua gestão que lhe dá, não unicamente de soltar suas asas, porém sobretudo e antes, atar-se firmemente em meio os penhascos de evitar os capotamentos irretornáveis.

---

Tópico Seguinte Adentra as muralhas mais profundas: 21 Segurança, Contornos e as Fronteiras de Exposição! — As chaves das permissões foram passadas nesta matéria, a mera gestão de autorizações não engloba os horizontes do Perigo! As barreiras configuracionais e travas nos scripts podem falhar. Como o lado obscuro funciona na indução (Injeção) de um "Comando Alienígena e Estranho" enganando os cérebros do AI na interpretação dos diálogos de inocentes passantes em repositórios da net (Prompt Injection); o pesadelo assombroso de escarificação de nossos recintos preciosos e token vazados! Abriremos o manual na distinção prática de uma coisa e outra, definindo assim o juízo humano antes da predefinição do código de máquinas. "Quando alargar os ares de permissões em face perigos reais, e o fechamento em quarentenas totais!"

---

Releituras Obrigatórias Associadas:

• Guia Oficial, Memorização Permanente - Escrita Regimental CLAUDE.MD nas gavetas-chave da Mente (Memória e Setup)!
• Bugs? Onde e Quando Quebra; FAQ Completo!
• Habilidade Exclusiva no Conjunto, Agents Skills no uso a qualquer invocação sem cerimônia!